David,
It seems to me like it would be *much* simpler to just make a copy of
the dc3-yasim-set.xml file. Say I wanted an "American Airlines" DC-3:
http://dfw.citysearch.com/E/V/DALTX/0213/06/66/cs1.html
I could make a dc3-aa-yasim-set.xml and repaint your model.
This means one -set.xml file for each permutation but it seems simpler
and more intuitive than having a different property name for each
model.
Let's say I wanted several different dc3's around with the ability to
easily select between them. I'm not sure if your proposed scheme
would handle that without creating new -set.xml files anyway.
One -set.xml file per aircraft also makes it easier to distribute my
new version to others.
Regards,
Curt.
David Megginson writes:
> Currently, there's a problem with our *-set.xml system for aircraft
> selection. If I want to fly the YASim DC-3, say (I love that plane),
> then I invoke FlightGear like this:
>
> fgfs --aircraft=dc3-yasim
>
> So far, so good. Now, let's say that someone prefers another 3D model
> to my modest effort, or simply hates Canadians and doesn't want to fly
> a plane with Trans Canada Airlines livery. She can start FlightGear
> like this to get the different model:
>
> fgfs --aircraft=dc3-yasim --prop:/sim/model/path=Aircraft/Models/dc3-usa.ac
>
> That works, but it's annoying. She'll be tempted, then, to put the
> second argument into her .fgfsrc so that she gets the right DC-3 model
> automatically. Unfortunately, that means that she'll also get that
> DC-3 model for the C-172, C-182, C-310, Harrier, and so on, since it
> overrides the value in any of the *-set.xml files.
>
> My proposed solution is to add a layer of abstraction to every
> *-set.xml file. It will be annoying for John and me, but will make
> things simpler for everyone else. What we do is add a new root level,
> something like
>
> /config/aircraft
>
> and then put all the configuration properties under that, so that we
> have
>
> /config/aircraft/dc3-dpm/
> /config/aircraft/c172-vfr/
>
> and so on. This all happens in the *-set.xml file. Then we include
> the top-level properties as aliases:
>
> <config>
> <aircraft>
> <dc3-dpm>
> <sim>
> <model>
> <path>Aircraft/dc3/Models/dc3-dpm.ac</path>
> </model>
> </sim>
> </dc3-dpm>
> </aircraft>
> </config>
>
> <sim>
> <model>
> <path alias="/config/aircraft/dc3-dpm/sim/model/path"/>
> </model>
> </sim>
>
> This is a little ugly, but ordinary users should never have to see
> it. Now, the user can put
>
> -prop:/config/aircraft/dc3-dpm/sim/model/path=Models/dc3-usa.ac
>
> in her .fgfsrc and get a different 3D model for the DC-3 without
> screwing up the default configurations for any other aircraft. No C++
> code changes are required, and I cannot think of any
> backward-incompatibilities. This will work for *any* property
> specified in the *-set.xml files, including default control positions,
> starting altitudes, etc.
>
> Comments?
>
>
> All the best,
>
>
> David
>
> --
> David Megginson
> [EMAIL PROTECTED]
>
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
