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

Reply via email to