I apologize for not raising this discussion *before* I filed that request, as I should have.
From the comments on http://gitorious.org/merge_requests/91: > In the past we've been struggling for more than one and a half release > cycles in order to separate Scenery-specific stuff from the Base > Package and to draw a clear line. Now you’re doing almost exactly the > contrary: Introducing new dependencies between Scenery and Base > Package by putting airport specific stuff into the FlightGear > ‘Airports/’– as well as into the shared models directory. > This stuff belongs into the Scenery directory structure. I can see why introducing a dependency could cause some problems. However, due to the technical details of the new jetways, it is not possible to integrate them with Terrasync/Shared models as it was previously. This is because the jetways are specified in an XML file for each airport that a Nasal script parses and loads models for via fgcommand("add-model", ...). That's how each jetway knows its independent position and its relative location to the aircraft door, unlike a static model in scenery where this is not possible. Additionally, the 3d models have to be stored somewhere. By my logic, that should be in Models/Aiport, hence the new directory. I intended this to not be synced with Terrasync (syncing won't have an effect anyway, since ATM the script always loads models from the main models directory). It would be possible to revert back to specifying jetway models in an STG file. However, that would cause a loss of features including the ability for the jetway to 'know' the position of the aircraft, and gate numbers and airline signs specific to each jetway- all of which are very well-received by end-users and I spent hours programming. Only the former can be worked around (and not very well, at that). Perhaps the directory structure needs reorganization. I would consider making a new directory under $FG_ROOT, perhaps Jetways/, but that just seems like a waste to me. Again, sorry for not raising this issue earlier. Ryan ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel