From: Heiko S. <aei...@ya...> - 2007-08-28 08:37:47
|
Hello, With the build from 08/15/2007 and some former ones until april I noticed stutters and pauses with 1-2 sec lenght. I write this, because it wasn't note here yet. With help from the IRC chat I did some testing. When I have enabled the dynamic view, everytime the view is changing, the fps decrease to 1-6 fps, very often it's pauses. The longer I fly, this behaviour seems to disappear. If the dynamic view is disabled, there are no stutters- even I disable the dynamic view at runtime. Sweeping the view 180 degrees around change anything. If I have disabled dynamic view, and I change the view manually with the mouse I can't reproduce the stutters. AMD Athlon XP 2400+ Windows XP NVidea GF 5200 with 128 RAM traffic manager and AI traffic disabled Build from Reagon Thomas from 08/15/2007 Thanks HHS ________ Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever |
From: Syd&Sandy <syd...@te...> - 2007-08-28 14:44:21
|
On Tue, 28 Aug 2007 10:37:42 +0200 (CEST) Heiko Schulz <aei...@ya...> wrote: > Hello, > > With the build from 08/15/2007 and some former ones > until april I noticed stutters and pauses with 1-2 sec > lenght. > I write this, because it wasn't note here yet. > > With help from the IRC chat I did some testing. > > When I have enabled the dynamic view, everytime the > view is changing, the fps decrease to 1-6 fps, very > often it's pauses. The longer I fly, this behaviour > seems to disappear. > > If the dynamic view is disabled, there are no > stutters- even I disable the dynamic view at runtime. > > Sweeping the view 180 degrees around change anything. > If I have disabled dynamic view, and I change the view > manually with the mouse I can't reproduce the > stutters. > > AMD Athlon XP 2400+ > Windows XP > NVidea GF 5200 with 128 RAM > > traffic manager and AI traffic disabled > > Build from Reagon Thomas from 08/15/2007 > > Thanks > HHS > I have the same problem , has nothing to do with dynamic view here , but with changing view... I generally have to pan 360 degrees a few times before takeoff to smooth things out .... used to be worse with PLIB , now about the same with both versions.... AMD Athalon 1100 Linux Geforce 6200 Cheers Syd&Sandy <syd...@te...> |
From: Laurence V. <lv...@ch...> - 2007-08-28 23:44:38
|
Syd&Sandy wrote: > On Tue, 28 Aug 2007 10:37:42 +0200 (CEST) > Heiko Schulz <aei...@ya...> wrote: > > >> Hello, >> >> With the build from 08/15/2007 and some former ones >> until april I noticed stutters and pauses with 1-2 sec >> lenght. >> I write this, because it wasn't note here yet. >> >> With help from the IRC chat I did some testing. >> >> When I have enabled the dynamic view, everytime the >> view is changing, the fps decrease to 1-6 fps, very >> often it's pauses. The longer I fly, this behaviour >> seems to disappear. >> >> If the dynamic view is disabled, there are no >> stutters- even I disable the dynamic view at runtime. >> >> Sweeping the view 180 degrees around change anything. >> If I have disabled dynamic view, and I change the view >> manually with the mouse I can't reproduce the >> stutters. >> >> AMD Athlon XP 2400+ >> Windows XP >> NVidea GF 5200 with 128 RAM >> >> traffic manager and AI traffic disabled >> >> Build from Reagon Thomas from 08/15/2007 >> >> Thanks >> HHS >> >> > > I have the same problem , has nothing to do with dynamic view here , but with changing view... I generally have to pan 360 degrees a few times before takeoff to smooth things out .... used to be worse with PLIB , now about the same with both versions.... > AMD Athalon 1100 > Linux > Geforce 6200 > > Cheers > Syd&Sandy <syd...@te...> > > > also had this problem in general (not with dynamic view). only thing that helped was adding the following to my .fgfsrc file: --prop:/sim/frame-rate-throttle-hz=75 as far I know no one has solved this problem. apparently only a few of us seem to have the issue. |
From: Robert B. <sim...@gm...> - 2007-08-29 02:41:07
|
On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: > also had this problem in general (not with dynamic view). only thing > that helped was adding the following to my .fgfsrc file: > > --prop:/sim/frame-rate-throttle-hz=75 > > as far I know no one has solved this problem. apparently only a few of > us seem to have the issue. I thought everyone had this behavior. Most videos I have seen of FG have the stutter and pause. Robert |
From: Laurence V. <lv...@ch...> - 2007-08-29 03:54:00
|
Robert Black wrote: > On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: > > >> also had this problem in general (not with dynamic view). only thing >> that helped was adding the following to my .fgfsrc file: >> >> --prop:/sim/frame-rate-throttle-hz=75 >> >> as far I know no one has solved this problem. apparently only a few of >> us seem to have the issue. >> > > I thought everyone had this behavior. Most videos I have seen of FG have the > stutter and pause. > Robert > I have learned to live with it. A point of interest is that x-plane does not exhibit this behavior using the same hardware and operating system. |
From: Vivian M. <viv...@li...> - 2007-08-29 07:42:30
|
Robert Black > Sent: 29 August 2007 03:41 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] [Bug-Report] Stutterer and=20 > pauses withdynamic-view >=20 >=20 > On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: >=20 > > also had this problem in general (not with dynamic view).=20 > only thing=20 > > that helped was adding the following to my .fgfsrc file: > > > > --prop:/sim/frame-rate-throttle-hz=3D75 > > > > as far I know no one has solved this problem. apparently=20 > only a few of=20 > > us seem to have the issue. >=20 > I thought everyone had this behavior. Most videos I have=20 > seen of FG have the=20 > stutter and pause. =20 > Robert >=20 I certainly do. I suspect that people have given up complaining about it = and have come to regard it as normal. At its worst it makes FG almost = impossible to use. Vivian=20 |
From: Frederic B. <fre...@fr...> - 2007-08-29 10:12:20
|
Quoting Vivian Meazza : > Robert Black > > > Sent: 29 August 2007 03:41 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] [Bug-Report] Stutterer and > > pauses withdynamic-view > > > > > > On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: > > > > > also had this problem in general (not with dynamic view). > > only thing > > > that helped was adding the following to my .fgfsrc file: > > > > > > --prop:/sim/frame-rate-throttle-hz=75 > > > > > > as far I know no one has solved this problem. apparently > > only a few of > > > us seem to have the issue. > > > > I thought everyone had this behavior. Most videos I have > > seen of FG have the > > stutter and pause. > > Robert > > > > I certainly do. I suspect that people have given up complaining about it and > have come to regard it as normal. At its worst it makes FG almost impossible > to use. I think stutter comes from the threaded scenery tile loader. When you change view direction, you ask the loader to load more tiles, and when all required tiles are loaded for a given position, the stutter stops. Also, when there is an insane frame rate, there should be no CPU time allocated to the tile loader, and thus, the stutter, so limiting the frame rate, either by using the throttling feature, or activating vsync, should lessen the problem. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer |
From: Andy R. <an...@pl...> - 2007-08-29 14:43:59
|
Frederic Bouvier wrote: > I think stutter comes from the threaded scenery tile > loader. When you change view direction, you ask the loader to > load more tiles, and when all required tiles are loaded for a > given position, the stutter stops. That seems unlikely. The tile loader is very old code, and this is a new symptom. It's also, as you point out, threaded precicely for the purpose of *not* blocking the main rendering thread. Andy |
From: Tim M. <ti...@re...> - 2007-08-29 15:06:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frederic Bouvier wrote: > Quoting Vivian Meazza : > >> Robert Black >> >>> Sent: 29 August 2007 03:41 >>> To: FlightGear developers discussions >>> Subject: Re: [Flightgear-devel] [Bug-Report] Stutterer and >>> pauses withdynamic-view >>> >>> >>> On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: >>> >>>> also had this problem in general (not with dynamic view). >>> only thing >>>> that helped was adding the following to my .fgfsrc file: >>>> >>>> --prop:/sim/frame-rate-throttle-hz=75 > I think stutter comes from the threaded scenery tile loader. When you change > view direction, you ask the loader to load more tiles, and when all required > tiles are loaded for a given position, the stutter stops. Also, when there is an > insane frame rate, there should be no CPU time allocated to the tile loader, and > thus, the stutter, so limiting the frame rate, either by using the throttling > feature, or activating vsync, should lessen the problem. > > -Fred You can blame some stuttering on the incomplete integration of the tile loader with OSG, something that I'm working on. In particular, display lists are now compiled and textures are now loaded when a tile first becomes visible; the OSG database pager schedules this work over several frames to avoid affecting the frame rate. Also, it's true that activating vsync will leave some predictable time for the pager thread to run when it won't interrupt the main rendering thread. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1YtreDhWHdXrDRURArtXAJ9iZaxcutfB33/geBAr8jjXn+7AygCfZq4G nY9J867TOdCadCHKVMCrZH8= =KsQG -----END PGP SIGNATURE----- |
From: Frederic B. <fre...@fr...> - 2007-08-29 15:19:33
|
Quoting Tim Moore <ti...@re...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Frederic Bouvier wrote: > > Quoting Vivian Meazza : > > > >> Robert Black > >> > >>> Sent: 29 August 2007 03:41 > >>> To: FlightGear developers discussions > >>> Subject: Re: [Flightgear-devel] [Bug-Report] Stutterer and > >>> pauses withdynamic-view > >>> > >>> > >>> On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: > >>> > >>>> also had this problem in general (not with dynamic view). > >>> only thing > >>>> that helped was adding the following to my .fgfsrc file: > >>>> > >>>> --prop:/sim/frame-rate-throttle-hz=75 > > > I think stutter comes from the threaded scenery tile loader. When you > change > > view direction, you ask the loader to load more tiles, and when all > required > > tiles are loaded for a given position, the stutter stops. Also, when there > is an > > insane frame rate, there should be no CPU time allocated to the tile > loader, and > > thus, the stutter, so limiting the frame rate, either by using the > throttling > > feature, or activating vsync, should lessen the problem. > > > > -Fred > > You can blame some stuttering on the incomplete integration of the tile > loader with > OSG, something that I'm working on. In particular, display lists are now > compiled and > textures are now loaded when a tile first becomes visible; the OSG database > pager > schedules this work over several frames to avoid affecting the frame rate. > Also, it's > true that activating vsync will leave some predictable time for the pager > thread to run > when it won't interrupt the main rendering thread. Did someone experiment changing the number of loader threads ? This is possible by changing line 120 of Scenery/FGTileLoader.hxx In CVS, the line is now : enum { MAX_THREADS = 1 }; It won't cure the fact that OGL resources needs to be allocated in the rendering thread, but would enable multiple cores to load more than one tile at a time. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer |
From: leee <le...@sp...> - 2007-08-29 15:53:40
|
On Wednesday 29 August 2007 15:43, Andy Ross wrote: > Frederic Bouvier wrote: > > I think stutter comes from the threaded scenery tile > > loader. When you change view direction, you ask the loader to > > load more tiles, and when all required tiles are loaded for a > > given position, the stutter stops. > > That seems unlikely. The tile loader is very old code, and this > is a new symptom. It's also, as you point out, threaded > precicely for the purpose of *not* blocking the main rendering > thread. > > Andy I'm not so sure I'd regard this as a new problem. I first reported it on the 8th Dec 2006 and Melchior responded that he'd been experiencing it for some time before then. At that time, Melchior thought it was related to the AI sub-system. The thread subject was "Periodic 'stutter' in FG" LeeE |
From: Durk T. <d.t...@xs...> - 2007-08-30 05:30:20
|
On Wednesday 29 August 2007 17:53, leee wrote: > > I'm not so sure I'd regard this as a new problem. I first reported it on > the 8th Dec 2006 and Melchior responded that he'd been experiencing it for > some time before then. At that time, Melchior thought it was related to > the AI sub-system. > > The thread subject was "Periodic 'stutter' in FG" > Speaking of which; there is one part of the AI system that causes some (currently unavoidable) stutter. Models are loaded on demand, and this causes some stutter. Mathias has indicated trying to move the loading process out of the main render thread, or something like that. I'm not sure how much that relates to the issues Tim mentioned in this thread. In addition, there are a few other candidates for causing stutter in the AI system, in particular the route finding algorithm and the traffic separation detection code, because these are requiring peaks in CPU activity. In particular when two aircraft request these functions in succession, there can be peaks of activity. However, having said that, these AI related issues are quite unlikely to cause the observed stutter, for two reasons 1). Heiko's original report in this thread explicitly mentions that he has turned off traffic manager and AI, and 2) I'm also seeing these stutters occur even before the AI traffic system starts loading. Cheers, Durk |
From: leee <le...@sp...> - 2007-08-31 01:09:57
|
On Thursday 30 August 2007 06:30, Durk Talsma wrote: > On Wednesday 29 August 2007 17:53, leee wrote: > > I'm not so sure I'd regard this as a new problem. I first reported it on > > the 8th Dec 2006 and Melchior responded that he'd been experiencing it > > for some time before then. At that time, Melchior thought it was related > > to the AI sub-system. > > > > The thread subject was "Periodic 'stutter' in FG" > > Speaking of which; there is one part of the AI system that causes some > (currently unavoidable) stutter. Models are loaded on demand, and this > causes some stutter. Mathias has indicated trying to move the loading > process out of the main render thread, or something like that. I'm not sure > how much that relates to the issues Tim mentioned in this thread. In > addition, there are a few other candidates for causing stutter in the AI > system, in particular the route finding algorithm and the traffic > separation detection code, because these are requiring peaks in CPU > activity. In particular when two aircraft request these functions in > succession, there can be peaks of activity. > > However, having said that, these AI related issues are quite unlikely to > cause the observed stutter, for two reasons 1). Heiko's original report in > this thread explicitly mentions that he has turned off traffic manager and > AI, and 2) I'm also seeing these stutters occur even before the AI traffic > system starts loading. > > Cheers, > Durk I wasn't so sure that the stutter I observed was related to the AI subsystem either - once the stutter started, usually within one minute, the period seemed to be very regular, however, it varied between different sessions or after a menu reset within a single session. It could be anything between 1 and 8 seconds between pauses (frame rates between 25-50 fps). I couldn't establish anything consistant about it but re-writing some of the nasal I was using, to use less listeners, which were being called every frame, ameliorated the situation somewhat, iirc, but wasn't an answer. LeeE |
From: Melchior F. <mf...@ao...> - 2007-08-31 11:23:54
|
This thread started as bug report about a recent problem with dynamic view, but people used it as opportunity to throw in their favorite bugs, although those are apparently unrelated. Let's keep things separated: Bug #1: "stutters and pauses with 1-2 sec lenght" when dynamic view is enabled (observed by Heiko in a recent build by Thomas). We don't know much about this bug, not even if it's fg/osg or fg/plib and when it started. It didn't happen when I ran fgfs last time (about two weeks ago). Bug #2: Syd added a complaint about the fg/osg *feature* that causes stutters until all scenery objects in 360 degree were loaded. This is annoying, but AFAIK not a bug. Should be resolved nevertheless, and I'm sure Mathias and Tim are aware of it and will change that at some point. (Someone on IRC has a local Nasal script that makes a 360 degree lookaround at the very beginning so that this won't disrupt the flight in the following minutes.) Bug #3: Lee threw in an old bug and repeated the long disproved myth that listeners are the cause. They are not! This bug causes fgfs to freeze for a tenth of a second in 8 seconds intervals beginning a few minutes after startup (but not always). The intervals stay the same, but the freezing time becomes longer and longer over time. This happens now since years and on my machine it can reliably be "fixed" by turning off AI traffic (the c172/pa28 aircraft). I tried to track it down but didn't invest enough time. The fact that this AI part was full of bugs just didn't make it worthwhile. (I just say "tower.cxx". :-) * leee -- 8/31/2007 3:09 AM: > I couldn't establish anything consistant about it but re-writing some of the > nasal I was using, to use less listeners, which were being called every > frame, ameliorated the situation somewhat, iirc, but wasn't an answer. > 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. I monitored all triggered listener code and there were none run regularly. (OK, some were, and they got fixed after that, for example those that listened to /gear/gear/wow, which is set in every frame by YASim.) Of course, if you write bad Nasal code, you can create all sorts of problems, and listeners will reliably run that buggy code. But the problem then is the bad Nasal code, and not the listeners by themselves or the number of active listeners. If you bring this up next time, please add some facts: show us the command line and the listeners that you had to comment out to "fix" the problem. m. |
From: Melchior F. <mf...@ao...> - 2007-08-31 08:43:17
|
* 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. |
From: Syd&Sandy <syd...@te...> - 2007-08-31 19:11:00
|
> Bug #2: Syd added a complaint about the fg/osg *feature* that causes > stutters > until all scenery objects in 360 degree were loaded. This is annoying, > but AFAIK > not a bug. Should be resolved nevertheless, and I'm sure Mathias and Tim are > aware of it and will change that at some point. (Someone on IRC has a local > Nasal script that makes a 360 degree lookaround at the very beginning so > that > this won't disrupt the flight in the following minutes.) > My apologies , from the description I thought it was the scenery loading stutter.I never encountered the dynamic view problem... -- Syd&Sandy <syd...@te...> |
From: Laurence V. <lv...@ch...> - 2007-09-01 14:21:19
|
Melchior FRANZ wrote: > > Bug #3: Lee threw in an old bug and repeated the long disproved myth that > listeners are the cause. They are not! This bug causes fgfs to freeze for > a tenth of a second in 8 seconds intervals beginning a few minutes after > startup > (but not always). The intervals stay the same, but the freezing time becomes > longer and longer over time. This happens now since years and on my machine > it can reliably be "fixed" by turning off AI traffic (the c172/pa28 > aircraft). I tried > to track it down but didn't invest enough time. The fact that this AI > part was > full of bugs just didn't make it worthwhile. (I just say "tower.cxx". :-) > > > sorry to break your state of bliss on bug #3 but I have , & had for some time, this bug without AI enabled. as far as I am concerned this is a long standing, semi-serious bug that remains unresolved. No, its not my hardware (popular explanation in months past). |
From: gh.robin <gh....@la...> - 2007-08-30 17:30:28
|
On mer 29 ao=FBt 2007, leee wrote: > On Wednesday 29 August 2007 15:43, Andy Ross wrote: > > Frederic Bouvier wrote: > > > I think stutter comes from the threaded scenery tile > > > loader. When you change view direction, you ask the loader to > > > load more tiles, and when all required tiles are loaded for a > > > given position, the stutter stops. > > > > That seems unlikely. The tile loader is very old code, and this > > is a new symptom. It's also, as you point out, threaded > > precicely for the purpose of *not* blocking the main rendering > > thread. > > > > Andy > > I'm not so sure I'd regard this as a new problem. I first reported it on > the 8th Dec 2006 and Melchior responded that he'd been experiencing it for > some time before then. At that time, Melchior thought it was related to > the AI sub-system. > > The thread subject was "Periodic 'stutter' in FG" > > LeeE > > Yes , to me, too, it is coming mainly from MP, and with my system, if i open "pigeon mpserver" on the same computer, i get an= =20 other "layer" of 'stutter' :( =2D-=20 G=E9rard |
From: leee <le...@sp...> - 2007-08-31 14:48:49
|
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 |
From: Melchior F. <mf...@ao...> - 2007-08-31 18:05:57
|
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. |