On 2/27/04 at 11:56 AM David Megginson wrote: >The way to fix all this is to decouple the subsystems using properties so >that there is no init-order dependency (and no need for unrelated >subsystems >to know about other subsystems' internals), but I see at least 4-8 hours' >work sorting out the mess, so it won't be this week. >
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). Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
