Hi, * Durk Talsma -- 5/25/2007 7:04 PM: > On Friday 25 May 2007 10:37, Melchior FRANZ wrote: > > * Durk Talsma -- 5/25/2007 9:20 AM: > > > Log Message: > > > Don't fix what ain't broke. > > > I explained why I reset that counter. Could you explain why you changed > > it back? >
> [...] So, sorry I didn't have time for a more elaborate explanation. ;-) > No problem. :-) I didn't really mean to criticize the code. It's just that this looked like a bug to me, so I "fixed" it. If you change it back without understandable explanation (cvs log or comment), then it will still look like a bug next time I look at it, and I'll be tempted to fix it again. ;-) > I added the counter to skip the first number of frames (more of less > arbitrarily set to 1000) after initialization, because the AI system needs > some time until all the right weather is loaded. > I see. 1000 makes 100 seconds on a system with 10 FPS, and 10 seconds on a system with 100 FPS, which, indeed, is rather arbitrary. (BTW: I was aware that this isn't "dead code" when I changed it -- I just remembered it wrongly when I replied to the cvs log message. Sorry for that -- I'm still not at my computer ...) > [...] otherwise it's > going to take much too long between the processing of two successive > aircraft. > OK. I looked into that code for two reasons: (1) I had backported your traffic changes back from HEAD to the plib branch, and wasn't sure if it worked correctly. (And I'm still not. ;-) (2) several people (including me) had the "hesitation" problem. For me and someone else AI definitely played a role in it, while for others it reportedly doesn't. I wanted to know how much of the loop runs when the traffic manager is even turned off, and I seem to remember that there was more than necessary, and it looked as if it was more often than necessary, too, and the loop counter looked very much as if it was intended to throttle the traffic manager updates, but didn't due to a missing line. (I didn't really look into the scheduler and have no idea how many flights it checks every time, but departure times with tenths of seconds precision didn't seem necessary, nor realistic to me. :-) I'll also look again into the Nasal subsystem for the hesitation problem. (I guess we shouldn't really run all Nasal loops with whole seconds intervals. I started to use odd intervals in the Fly-By view code already.) > [...] should probably be replaced by checking a metar related property, Would using the ::postinit() method be early enough? It's called after the weather (and every other) subsystem has called its ::init(). m. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
