[Flightgear-devel] RFC: Aircraft *-set.xml files reorg
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 pathAircraft/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
re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
David Megginson writes: 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. Hmm. On further reflection, this might cause trouble for properties that are tied, like /position/altitude, so it would have to be limited to things like the 3D model and input bindings. Perhaps a cleaner solution would be to extend FlightGear to use multiple root paths. For example, if I had FG_ROOT=/usr/local/lib/FlightGear:$HOME/.fgfs/ then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could contain properties overriding some or all default values from /usr/local/lib/FlightGear/Aircraft/dc3-yasim-set.xml. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
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 pathAircraft/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
Re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
Curtis L. Olson writes: 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. Yes, but then where do you put the *-set.xml file? Not every user will have write access to the base package, even on their home system, and it's easy to blow away customizations there anyway during updates. This is where my second suggestion -- multiple paths -- might come in handy. 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. I wasn't trying to avoid multiple -set files; instead, I'm trying to think of a user-level solution. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] RFC: Aircraft *-set.xml files reorg
David Megginson [EMAIL PROTECTED] said: David Megginson writes: 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. Hmm. On further reflection, this might cause trouble for properties that are tied, like /position/altitude, so it would have to be limited to things like the 3D model and input bindings. Perhaps a cleaner solution would be to extend FlightGear to use multiple root paths. For example, if I had FG_ROOT=/usr/local/lib/FlightGear:$HOME/.fgfs/ then $HOME/.fgfsrc/Aircraft/dc3-yasim-set.xml could contain properties overriding some or all default values from /usr/local/lib/FlightGear/Aircraft/dc3-yasim-set.xml. This same question occured to me when working on the panel stuff. It seems as though the -set.xml files are used to select fdm and aircraft type. On the other hand panels and skin models are similar by aircraft type but not across fdm's. So why not have a -model.xml file that defined the panel and skins parameters and locate it in the Aircraft/(aircraft model) directory? (e.g. $FGROOT/Aircraft/dc3/dc3-model.xml) By modularizing a little bit, the multi-root concept work quite nicely. The only potential idea this would not address is the possibility of having multiple skin models and panels in the distribution that we want to be able to choose from the PUI menu or by key binding. It would be nice to be able to change the skins on the fly, and I'm thinking that a list of available skins could be stored and then copied in to the model/path property. If these were listed in the -model.xml file, the first one in the list could be considered the default. Then the question would be should the secondary root (eg $HOME/.fgfs) be considered a complete override, insert in front or add on to the back of the list. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
