Initializing Nasal early

For the sake of simplicity, we could refactor the ::init() method such that the common init code could be shared, between the initial startup Nasal interpreter, and the final runtime interpreter - so that we could load init code from a separate $FG_ROOT directory to do such things, without parsing all the stuff in $FG_ROOT/Nasal.

Referring to the GLSL segfault fix and my earlier comment about defaulting to a NON-SHADER environment by adjusting shader quality level to 0 if shaders are unsupported: For now, this is obviously easy to simply hard-code by showing an ALERT message and overriding the shader settings from there on.

However, in the long run, we'd probably want to simply delegate such stuff to Nasal space. While Nasal is currently not available that early, we could use a bare (or just temporary) Nasal instance during initialization to hand-off such stuff to scripting space. This seems to be an old idea actually (see the comments below from 2008) - and peopel were actually working on having Nasal + GUI code up really early back in 2008.

Given the state of the current init code in fg_init.cxx, the idea of factoring stuff out into Nasal space is very appealing - which means having less unmaintained C++ spaghetti code, and things like processing startup arguments can be really easily done from Nasal space, what's needed is "only" the props code - or rather just setprop/getprop, which would allow simple logic to be moved to scripting space - and it would not even be performance-critical.

In other words, it would be sensible to pick up the old idea and make a minimal Nasal interpreter available early on, and pass control to it - so that things like thís can be easily run, without hard-coding any logic:

if (getprop("/sim/rendering/gl-shading-language-version")=="UNSUPPORTED") {
print("Warning: Shaders unavailable, defaulting to quality level 0!\n")
setprop("/sim/rendering/shaders/quality-level", 0);
}

The only catch is, subsystems are initialised late, but I need a handful to be up before I can use the GUI dialogs; obviously the GUI subsystem itself, but also Nasal and a few others. (There are some issues with initialising nasal early, it is currently deliberately being done very late, but more on that later...) — James Turner

I would appreciate if Nasal were around the first subsystems to be initialized. But this would require some Nasal dependency resolution. Almost all Nasal code needs globals.nas, and most need props.nas, too (which needs globals.nas). gui.nas needs globals.nas and props.nas, and screen.nas needs all three etc. This needs to be taken care of if Nasal is to be initialized early. — Melchior FRANZ

starting up the interpreter (the first part of  FGNasalSys::init) can be done very early (and quickly), and the subsytem would then wait for a relatively high-valued 'init' call before running scripts (the part that needs all other properties to be defined). — James Turner

I'm sure other people can propose potential groups, but I'd imagine: early (nasal itself, GUI) time based subsystems (ephemeris, datetime, warp, properties, interpolator) environmental (weather fetch) aircraft systems (FDM, electrical, cockpit?, instruments, failures, GPS) scenery (tile manager, views, panels) input  IO subsystems - ATC, traffic, multiplayer sound — James Turner

I will start the systems I need (Nasal, GUI and input) early. This might also help make the startup progress a bit more fine-grained. — James Turner

In the even longer run, we'd actually want to associate the Nasal scripts with run-levels (/etc/rc.d, anyone?), since the frontend GUI might want a few scripts loaded, while I assume most are only relevant when actually flying. Such a change also makes postinit() unnecessary, I think - since the effect can always be achieved by having init() watch for a higher run-level. — James Turner