On Friday 31 August 2007 09:43, Melchior FRANZ wrote: > * Melchior FRANZ -- 8/31/2007 9:59 AM: > > Listeners are not involved, unless you have very badly written ones on > > your > > harddisk (only). When you brought that up last time I added some logging > > capabilities for listeners and disproved this claim. > > See this mail for how to log listener calls: > > http://marc.info/?l=flightgear-devel&m=117777601627835&w=2 > > > I apologize if my response was too harsh. But I'm touchy when it comes to > (IMHO) unjustified criticism of Nasal listeners. They have become a central > part of FlightGear<=>Nasal-core interaction, and I don't like it if > there are > (IMHO) unfounded doubts about their correct working. I fixed all problems > with them ever reported and I'll keep doing that. So, if you run into > anything > where you think listeners cause problems, please report that along with > logging information, example code, and command line. Are there any > listeners triggered at the same time when such an interval freezing occurs? > If so, which? > > m.
Hi Melchior, 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. There were two main areas where I was using listeners that were being called every frame and this was intentional because it seemed appropriate to me. 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. 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. Tied in with this, I also had to use a number of A/P filters to provide properties that I could actually set some of the listeners against, as some of these properties wouldn't work directly with listeners. All this meant that the listeners would be called each frame but that was exactly what I thought I needed. 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. The result was that instead of spotting a deviation as soon as it occurred it wouldn't be spotted until the next sample, which may have been as long as the sample period and this meant that the deviation would have grown and been greater than it needed to be before it could be corrected. This in turn required a greater correction than it would have done if the deviation could have been corrected when it was smaller. Perhaps I had taken the wrong approach for this or perhaps I was just trying to do too much with insufficient hardware, but anyway, that's what I was trying to do and for the most part it seemed to be working, at least in principle. In the end though, what with some of the A/P PID controllers refusing to start without first resetting the A/P and then finding that the PID controller sampling rates were not working at the <Ts> sample rate but were tied to the frame rate, which made it impossible to tune them for consistant operation, I gave it up. LeeE ------------------------------------------------------------------------- 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
