First of all: I apologize for the horribly formatted message. That was caused by a badly configured Mozilla Thunderbird on this machine (which isn't mine). Should be fixed now. And it was hard work! :-)
* leee -- 8/31/2007 4:48 PM: > It wasn't my intention to criticise listeners in any way - I was just > reporting what was happing, what I tried doing about it and what the results > were after I tried a couple of different things, including re-writing some of > the nasal to use less listeners. Yes, I know. I just wanted to make sure that people don't shy away from listeners because of this experience. It's important to know that Nasal (or c++) listeners don't do *anything* on their own. They consume exactly zero CPU cycles when they are idle, and only execute their callback function if their property is written to. You can fill your memory with listeners and shouldn't see the least effect. Well, apart from out-of-memory, of course. :-) If a property made problems in your case, then because of what the callback function did. It's quite strange that the 8s stutter problem was influenced by listeners in /your/ case, and by the ai-setting in /mine/. Now that (most of?) the other ai problems are fixed, it's really time to nail that down. At times I had the impression that our (almost) exclusive use of integer settimer() intervals could be a cause. Maybe too many SG events happen in the same frames that way. (I've started to use odd intervals in the flyby loop because of that.) Still need to check that. > First of all, I needed to intercept stick control inputs so that I could use > the stick in different 'modes' i.e. use the stick input to set pitch angles, > roll angles or climb rates and alternatively provide proportional surface > deflections instead of direct control surface deflection. Listeners shouldn't cause problems here. The input subsystem isn't in a separate thread -- the axis evaluation happens only once per frame, just like a Nasal loop run. So I assume that a listener doesn't buy you much here. > To do this it also meant that I had to monitor the aircraft orientation, > accelerations and speed. [...] Like I say, using listeners for these > functions seemed appropriate because they would/could be constantly changing. Shouldn't be a problem either, but loops are really better for stuff that changes that often. AFAIK orientation/acceleration/speed, just like joystick axes etc. are updated exactly once per frame (in the property tree), so a listener wouldn't buy you much here, either. It won't be triggered in each FDM iteration. Only tied properties will, but in a way that doesn't trigger listeners, anyway. > The re-writes I did were to use timers for many of these functions instead of > the listeners and while this worked it was less than ideal because it set a > limit to the resolution of the things I needed to monitor. In that case it would be an option to consider the Nasal-run interval time, like the lowpass filter in $FG_ROOT/Nasal/aircraft.nas does. m. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
