Whilst on the subject of initialisation order, currently the tile manager gets initialised before an initial position is set. This means that it loads a set of tiles centered on lat/lon of 0,0, and then loads a set of tiles at the correct location. In conditions of limited visibility, this can result in forced tile deletion messages and a stutter during forced deletion at some point in the flight since the tilemanager thinks it can't keep up with deletion, but is in fact due to having twice as many tiles as necessary (exacerbated by the fact that visibility doesn't get picked up properly for several iterations). Moving the tile manager init to occur after the view manager init would be a good thing IMHO, to prevent the loading of bogus tiles. (I've been testing this for a while, and it doesn't seem to break anything).
Hmmm, the tile manager *needs* to be initialized before the FDM because the FDM *needs* to know ground elevation for ground trimming, and we can't determine that until the local tile is loaded. We never used to load a set of tiles around (0,0) so I'm not sure why that is. The view manager code is very complex and to be honest I've never quite tracked with the latest changes in it. There may be some odd dependency there. I have also seen some wierdness in the tile scheduling/caching lately too. I'm not sure what's going on there. I started to investigate, but ran out of time the day I was looking at it. It seems like at times we get into a situation where the tile cache isn't big enough for the set of local tiles and it thrashes. That shouldn't happen, but there are some wierd view manager dependencies in there that I'm not even close to understanding.
Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
