Paul Surgeon wrote:
Hence the need for FlightGear to have a way of adjusting all these things
(preferably from inside FG).
shouldn't be a problem to start using specific nodes within the property
tree for that case, it would probably not even be involved to first add
_support_ (only) for it - one could still adapt the corresponding
functions/methods laters to actually support more than what's currently
possible.
We cannot expect one size to fit all which is more or less what we do at the
moment. Yes, there are a couple of things we can tweak at the moment such as
the model density in the scenery based on distance.
About 6 weeks ago I did also make some very similar suggestions - mainly
about enabling the user to dynamically modify the complexity level of
the scenery, possibly even rule based - so that the complexity level is
(optionally) decreased at cruise altitude and increased at lower flight
levels or during an approach.
Basically, by implemeting such a mechanism one could also support to
allow users to create and use _profiles_ - something which is also
supported by FlightGear's commercial counterparts, like MS FS or
X-Plane, which both also allow dynamic modification of such parameters.
As much as everyone loves using the command line for setting parameters what
happens when we can't pass enough parameters via command line because we hit
the limit on how much the shell can handle?
On my Linux box it's not much of a problem but whats the limit in Windows?
Windows is indeed a bit picky about the length of command lines, however
there's still the fgfsrc.system file that could be used to theoretically
pass an abitrary amount of parameters to FG - but I still second what
you said: it would definitely be nice to be able to modify such
parameters at runtime/ "on the fly" :-)
----------
Boris
_______________________________________________
Flightgear-users mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d
