wkitty42 wrote in Tue Apr 14, 2020 1:34 am:is there no chance for the creation of, say, a truman2 scenario file that --carrier=truman2 would load?
i don't know if the load processing of --carrier is done by C code or nasal on startup... if done by nasal, adding more scenarios should be fairly easy...
Like Stuart said, this is implemented in C++ - I believe it was originally implemented by FredB in the early 2000s, i.e. it's all pre-dating Nasal by ~3-5 years.
For reference, options processing takes place in $FG_SRC/Main/options.cxx:
https://sourceforge.net/p/flightgear/fl ... ptions.cxxSpecifically, you will want to look at the following array/table of hard-coded options (make sure to pay attention to the comments at the top):
https://sourceforge.net/p/flightgear/fl ... .cxx#l1597You will find the "ai-scenario" option being set up here:
https://sourceforge.net/p/flightgear/fl ... .cxx#l1847The final argument in that line said that a function is called for further processing, it's called fgOptScenario - which is to be found here:
https://sourceforge.net/p/flightgear/fl ... .cxx#l1420It would actually be relatively useful/easy to support Nasal for options processing purposes - and it was also discussed in the context of addons potentially coming with their own addon specific startup arguments. There is however the long-standing issue that Nasal initialization is taking place much later in the process, i.e. the Nasal interpreter is not yet available when options processing takes place. This is relatively easy to change, and we do have working patches for this, which were prototyped at the encouragement of James Turner who repeatedly expressed interest in being able to initialize Nasal earlier:
http://wiki.flightgear.org/Initializing_Nasal_earlyHowever, more recently this has no longer been a priority apparently - that being said, for this particular use-case (options processing in scripting space), a temporary Nasal instance would suffice, and would be really easy to set up - bugman (Edward) and James are already using this approach for unit testing purpose, i.e. they set up a standalone interpreter instance to test certain Nasal functionality outside of fgfs.