hi Melchior,
On Sunday 27 May 2007 10:01, Melchior FRANZ wrote: > 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 realized after committing my "fix" that the purpose isn't very clear, so this would be an ideal place to add a comment. :-). > > 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. :-) Lot's of thanks for porting this BTW. My travel schedule's been a bit crazy, and I'm still trying to catch up as we speak. I just did a quick test, and your port works nicely. I'm going to add one additional line of code, so that we can start removing the Traffic directory altogether. Will submit that shortly. Each call to update() processes one aircraft. Currently we don't have that many AI schedules in CVS yet, but I've tested this with 26000+ aircraft, which would mean that even at a reasonable rate of 30 Hz, it would take approximately 14 minutes between two schedule updates for each aircraft. That being the case, you could probably imagine my shock when I found out that that value would be decimated by a factor of one 1000. :-) Cheers, Durk ------------------------------------------------------------------------- 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
