David Megginson wrote:
A while ago, Curt suggested moving from
...
and so on, to something more sane: /controls/engine[0]/ /controls/engine[1]/ /controls/engine[2]/ /controls/engine[3]/
Yes, lovely. Excellent.
No - we have that in some places, but I was thinking recently that it's not the right way to go. I think the only practical purpose is to reduce clutter in the browser; but the property browser could and should do this for us if we want it to. For example, it could displayWe could even go to /controls/engines/engine[0/ and so on to simplify the /controls/ top level further.
controls/
elevator
engine[*]
flaps
...
and then, when the user clicks on it, expand it to
controls/
elevator
engine[0]
engine[1]
engine[2]
engine[3]
flaps
...
or to
controls/engine
[0]
[1]
[2]
[3]
From an abstract point of view, "engines/engine[n]/" could more succinctly be arranged as "engines/n/" or "engine[n]/" and this last seems to be the way the property manager was designed to handle it. Note that "engines/engine[n]/" is identical to "engines[0]/engine[n]/" which starts to look a bit silly again.
Just my opinion.
Also, could a similar thing be done with the engine output properties (mainly to drive the guages - RPM, temperature, etc.)? I can't think right now where they are at the moment. I have this vision of enabling the JSBSim piston engine and the Yasim piston engine models to be plug-in-compatible with one another.
- Julian
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
