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). And we cannot > expect all users to run the same FG version - or to even update their FG > setups (base packages) on the same day. A bunch of Linux distros still > haven't switched to FG 2.6.0...
But we can't guarantee backwards compatibility forever for future world scenery releases. The main problem I currently see is a different one however... > 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). Now, it's good to see these issues getting some attention, but that is not the only issue we are facing: Taxiway signs are distributed via terrasync as stg entries. apt.dat 850 contains the taxiway definitions along with the rest of the airport data. What we do now in genapts850 is to convert the sign format from apt.dat to stg and write the corresponding files. No problem so far (and we always get the correct hight for the signs along the way). If a user wants to edit the signs, he can do it in stg, but that is a one way road. Ideally the edits should go back to upstream so everyone can profit from them. But there is no (official) way back from stg to apt.dat. I was in this situation yesterday and hacked together a quick script to be able to convert the signs. Xplane's WorldEditor (WED), an opensource program, BTW, is perfectly able to create airport layouts, signs and taxiway routes. All of this is read and written back to apt.dat. So our general question should be how to handle this situation in the most optimal way. Should we continue implementing our own xml versions of the apt.dat entries or should we rather try to read as many properties as possible directly from an apt.dat file? And how do we secure the exchange of data between stg and apt.dat? This topic is very complex and I'm sure i forgot many other important aspects, but this is just what i'm currently thinking about. Chris ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
