ThorstenB wrote: > But to be honest, it neither works with central terrasync scenery. We > could never push any updates (such as introducing terrasync scenery with > the new EDDF runway) without immediately breaking consistency with all > previously released FG versions (= their base packages).
We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. The xml files are small, can be distributed easily and are very fine- grained, meaning that FG only has to parse the data it really needs for the current scenery path, instead of parsing a close-to 100 MB file on every startup (only for the apt data). We could completely decouple the scenery from the base package and finally make it possible again to distribute updated scenery via terrasync, even in smaller chunks (continent-wise or whatever makes sense). I already looked into the code and James has signalled support, so I'd like to hear some opinions. > Terrasync already syncs a global "/Models" directory, so terrasync > scenery can use newer or updated models. We could do the same for nav > data. I'd be happy to extend terrasync to sync another global directory, > i.e. "/Nav" (or "/Nav810", "/Nav850") and then extend FG to consider > these directories first, before defaulting to (old) nav/airport/airway > data from the base package - which then would only need to match the > (old) base package scenery (i.e. before the users pulls terrasync data > for the first time). You mean to put small apt.dat/nav.dat parts into these directories? Chris ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
