Melchior FRANZ writes: > First off, I want to say that I don't want to put David's work down. This > *is* a complicated matter, and *much* work went into it, and the feature > works very well (when it works) and I enjoy it a lot. It's really only the > crashes that are annoying, and the fact that we are living with them a really > long time now. Reworking the critical and obviously buggy list handling > would probably be a good idea. >
Hi Melchior, and Fred, First off, thanks for the above! It's good to know that it's not just an annoying source of crash reports. I was quite OK about your rant about the messy code BTW - mainly since I wrote it quite a long time ago and I realise that it's true. > > > * Frederic Bouvier -- Wednesday 19 April 2006 10:44: > > So why not using a single list and a state variable in the plane record ? > > I would say that tracking the state in the plane record is a must. There's > really no other place where this belongs. Using just one list is an option. > We don't have *that* many aircraft around. The highest number that I ever > saw were ~75 aircraft, but most of the time it's around 30. Going through > one list with 70 items and checking one state variable is hardly a performance > factor. > > But I wouldn't even object to separate containers. I would just use queues > and always pop an item for inspection, then either drop it and remove the > plane record, or push it onto a queue again -- the same queue, or a different > (changing the ac state in the plane record accordingly). Currently some > places erase(), others pop(), many many times iterators are set to the list > begin() (75 times :-), and it's a bit hard to follow what's going on. No > wonder one and the same aircraft ends up on 5 state lists at the same time. > Yes, as I've dug into it again I've started to realise just how bad parts of it are. My intention at the time of writing was to attempt to mimic the thought process of the tower controller him/herself. So I started off by subdividing the aircraft into the groupings that I thought I might mentally group them into if I had to control and schedule them. However, as we've found out, this is clearly either a poor design or a poor implementation of it by myself, or a bit of both, in terms of code stability. In theory there should be one master list containing a pointer to all the planes. This pointer can then be duplicated in one other sub-list (departing, circuit etc) at a time. It is fragile though - I'm trying to come up with either something better, or a completely reworked implementation. I *am* working on fixing it, although I realise there could be ground for doubt on the signs of progress so far. It's not something I can fix in a day though, as you two have probably both discovered. I want to get it a lot more right this time round, so I'm still trying to figure the design at the moment, before I start banging out code. I've never lost interest in any of the code I've written for FG, although I suspect Jon has given up hoping for engine model updates by now! One day :-) However, I do realise that I've had a tendency to start too many things, all of which now require attention, and all of a sudden I've changed jobs and time is more scarce :-( But tower.cxx is the only thing I'm working on at the moment - I want it fixed and stable before 1.0 as much as you guys, because otherwise in retropect there wouldn't have been much point in writing it to start with. > > > > BTW: I don't think using a smart memory management technique should be > > ignored > > just because this particular problem is fixed ( in a near future I hope ). > > Sure. But they shouldn't be used to hide bugs that needed to be fixed in > the first place. > Absolutely. Cheers - Dave ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
