RE: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Geoff Air writes: > > Those who 'regularly' use system.fgfsrc, like I do, > to control each run of FG, and use 'panel-less' > aircraft, like ufo, have probably been 'adding' this > patch to fg_init for 'years' ;=)) Oooh it is not just me then who doesn't just 'use' all the eye candy :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Martin Spott: > Frederic Bouvier wrote: > > > But... The fact that Geoff tells that the file is read twice ring a little > bell > > in my mind. I think the issue was raised sometimes ago and could have > unwanted > > side effects I can't recollect for the moment. > > It makes sense - especially in the context of the claim, that > $HOME/.fgfsrc on Unix a read more than once as well. > See, as nice as the XML configuration system is, it _must_ bring such > a 'feature' to the developer. In order to figure which command line > paramters you are allowed to use you have first to determine $FG_ROOT. > If $FG_ROOT is defined by the $HOME/.fgfsrc alias 'system.fgfsrc', then > you have to red that file first, look for $FG_ROOT, read the necessary > details and then reread the config file in order to figure which of the > details is being triggered in the config. > > There's nothing abnormal with such a procedure. Well, it might be > cleaner to create an array to store the parameters that you read from > the config file and later do multiple reads on this array but the basic > approach is the same, I was not clear. Reading the file twice is not a problem. Loading an aircraft twice might be. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Frederic Bouvier wrote: > But... The fact that Geoff tells that the file is read twice ring a little > bell > in my mind. I think the issue was raised sometimes ago and could have unwanted > side effects I can't recollect for the moment. It makes sense - especially in the context of the claim, that $HOME/.fgfsrc on Unix a read more than once as well. See, as nice as the XML configuration system is, it _must_ bring such a 'feature' to the developer. In order to figure which command line paramters you are allowed to use you have first to determine $FG_ROOT. If $FG_ROOT is defined by the $HOME/.fgfsrc alias 'system.fgfsrc', then you have to red that file first, look for $FG_ROOT, read the necessary details and then reread the config file in order to figure which of the details is being triggered in the config. There's nothing abnormal with such a procedure. Well, it might be cleaner to create an array to store the parameters that you read from the config file and later do multiple reads on this array but the basic approach is the same, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Martin Spott wrote: > Frederic Bouvier wrote: > > Quoting Geoff Air: > > >> It certainly paves the way for fgrun to simply write the > >> system.fgfsrc, and run the binary with a minimum of command > >> line parameters ... and leaves a persistent file 'trace' > >> of what fgrun 'requested' of FG ... more info benefit ... > > > > Because some argued, and I mostly agree, that fgrun shouldn't overwrite > user's > > preferences, command line options are now used. > > Nevertheless the proposed make much sense for those who don't use > FGrun but configure FlightGear using the system.fgfsrc instead. I was not arguing against the patch but reacting to the idea that fgrun should overwrite system.fgfsrc or any user file. But... The fact that Geoff tells that the file is read twice ring a little bell in my mind. I think the issue was raised sometimes ago and could have unwanted side effects I can't recollect for the moment. A search in the mailing list archives maybe will enlight us more. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Frederic Bouvier wrote: > Quoting Geoff Air: >> It certainly paves the way for fgrun to simply write the >> system.fgfsrc, and run the binary with a minimum of command >> line parameters ... and leaves a persistent file 'trace' >> of what fgrun 'requested' of FG ... more info benefit ... > > Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's > preferences, command line options are now used. Nevertheless the proposed make much sense for those who don't use FGrun but configure FlightGear using the system.fgfsrc instead. Thanks, Geoff, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Geoff Air: > It certainly paves the way for fgrun to simply write the > system.fgfsrc, and run the binary with a minimum of command > line parameters ... and leaves a persistent file 'trace' > of what fgrun 'requested' of FG ... more info benefit ... Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's preferences, command line options are now used. This is why I want to keep the command line textbox : people can see what's going on and can provide these informations when asking for support. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
