Initializing Nasal early

This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3). You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: . This feature is scheduled for FlightGear 4.x. If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Warning: the information in this article is old and may be outdated. If you know about the internals of Nasal, please consider adding to Nasal Initialization

Towards FGCanvas: Screen shot showing the Nasal and Canvas subsystems initialized early, so that both subsystems can be used to implement GUI launchers or more dynamic splash screens etc.

Bootstrapping

Started in	07/2014
Description	scripted startup, as per [1] and [2]
Contributor(s)	Hooray, Philosopher (since 07/2014),
Merge Request(s)	MR #42 (fgdata) Pending
Status	Under active development as of 07/2014 [3]
Topic branches:
$FG_SRC	https://gitorious.org/fg/philosophers-flightgear?p=fg:philosophers-flightgear.git;a=shortlog;h=refs/heads/topics/fgcanvas
fgdata	https://gitorious.org/fg/canvas-hackers-fgdata?p=fg:canvas-hackers-fgdata.git;a=shortlog;h=refs/heads/topics/fgcanvas

I am delighted to have this cleaned up, and a way to incrementally init bits of Nasal — zakalawe (Oct 27th, 2013). Re: Modular Nasal bootstrapping (again). (powered by Instant-Cquotes)

I would prefer to init Nasal earlier in startup, because I would like use Canvas-based UI for pieces such as aircraft-selection - but right now we have to load Nasal in postInit, which is seconds and seconds into startup. Most Nasal things that need FDM state already wait on fdm-initialized, so in theory the only fix required is to skip <nasal> evaluation in 'animation' XML files (apparently there is a long-standing assumption that such elements are skipped when loading an aircraft as the main one, i.e they are only run for AI / MP aircraft - this is a bad situation but changing it now could be a serious compatibility problem) — zakalawe (Sun Oct 27). Re: Modular Nasal . (powered by Instant-Cquotes)

The old ‘reset’, which does *not* restart Nasal, is now stripped down to the bare minimum of systems needed for repositioning (tele-porting). Since many aircraft Nasal scripts rely on /sim/signals/reinit to do work on being teleported, that behaviour was also retained. In an ideal world, there would be a better API to inform aircraft and Nasal modules about a teleport, but for the meantime, the property you mentioned is the one. Eg, really we should have an API to distinguish on-ground vs in-air starts, and adjust the initial state of properties accordingly. BTW, for the new reset process, the subsystem, including Nasal, is actually destroyed and re-created. This is intentionally to make it almost certain the behaviour after a reset is the same as after the first launch of the sim. — James Turner (2014-12-10). Re: [Flightgear-devel] Expected behavior on "reinit". (powered by Instant-Cquotes)

The primary goals are: make startup more predictable and less hard-coded. allow running flightgear in a server/test mode with only some subsystems, and no rendering Obviously supporting a standalone 'fgcanvas' would be quite a small extension from those. I'm not worrying about dynamic dependencies or automatic subsystem creation for the moment - I expect the user / defaults to have defined a set of subsystems that work without crashing You're correct of course that Nasal has many assumptions about subsystems, but I think that can be improved incrementally on the Nasal side. For the test mode, I really want to start Nasal-the-langauge very early, without loading all the modules in Nasal/ immediately. (Or maybe load a 'safe' subset). That's going to take some thought and I didn't get that far yet! — James Turner

This is exactly what I added support for implementing new commands in Nasal, so that going forward we can correctly put custom dynamic things in commands. — zakalawe (Oct 14th, 2013). Re: Modular Nasal bootstrapping (again). (powered by Instant-Cquotes)

on the complexity of dependencies for Nasal scripts, I think again the answer is to have the running status of each subsystem stored somewhere, and exposed via the property tree. The trick will be picking good groups, so most things have one or two dependencies, and having some documentation somewhere stating what's in each group. — James Turner (Apr 18th, 2006). Re: [Flightgear-devel] Subsystem run-levels. (powered by Instant-Cquotes)

the run-level concept is just one property, and nicely encapsulates the hierarchy of subsystems (if you're switching to level 8, all lower levels must already be initialied). But having names and separate flags makes the actual dependency clearer: 'this script depends on the aircraft subsystems' or 'this script depends on the environmental subsystems'. I guess it partly depends how complex the dependencies for any given script are in practice - hopefully they're actually quite simple. — James Turner (Apr 18th, 2006). Re: [Flightgear-devel] Re: Subsystem run-levels. (powered by Instant-Cquotes)

This is a summary of all discussions relating to:

• initializing the Nasal scripting interpreter earlier
• moving $FG_ROOT/Nasal initialization out of C++ into scripting space (aka "bootstrapping") while introducing proper dependency resolution (inter- and intra-modular)
• auditing $FG_ROOT for any other cases of embedded Nasal code that may have implicit assumptions regarding other subsystems (e.g. dialog files) Not done
• moving subsystem-specific initialization of Nasal APIs into each subsystem's bind methods, as per [5]
• extending cppbind to keep track of added symbols, to easily remove them on demand Pending
• moving subsystem-specific argument processing and fgcommand initialization into each subsystem Not done
• providing an integrated GUI front-end/launcher using Canvas and Nasal: Aircraft Center
• decoupling FlightGear initialization such that certain subsystems can be optionally disabled right at the beginning (e.g. FDM, sound, replay, scenery)
• simplifying the fg_init.cxx/main.cxx initialization logic (fgCreateSubsystems) and exposing it to scripting space
• allowing argument processing to be delegated to scripting space (e.g. options, startup position handling, presets etc.) Not done
• grouping related subsystems into SGSubsystemGroup instances to manage them holistically - analogous to run-levels, e.g.:
  • AUDIO: sound, voice (TTS), fgcom
  • AIRCRAFT: aircraft-model, controls, flight (FDM), xml-autopilot, route-manager
  • VIDEO: gui, canvas, canvasGUI
• making the initialization process/splash screen more responsive by using Nasal/Canvas instead of hard-coded GL code [6] [7] (ticket #1456) Pending
• allowing custom startup profiles/modes to be implemented via Nasal helper scripts (which also touches the area of 'modding'), for example: Not done
  • FGCanvas
  • running stand-alone Canvas applications, e.g. the Interactive Nasal REPL or a MapStructure map
  • FlightGear Benchmark
  • FlightGear Headless
  • FGViewer
  • supporting stand-alone Nasal/Canvas-baased applications like a MapStructure-based moving map or a virtual ATC client
  • supporting a safe subset of subsystems for mobile devices

Making Nasal/Canvas available as early as possible, also means that we can show Canvas-based splash screens, or even run Canvas dialogs until the scenery has finished loading. This screen shot shows two fully-responsive Canvas dialogs while FlightGear is still scenery loading.

Note  The FlightGear initialization sequence is generally handled by $FG_SRC/Main/main.cxx, which is where subsystem initialization is delegated to fgCreateSubsystems() in $FG_SRC/Main/fg_init.cxx

Objective

The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all). This would avoid people accidentally starting on the runway in MP events, which would be a big usability win. When no parking positions are defined, AI traffic defaults to the 'airport centre' location. Selection a taxiway parallel to the active runway is possible, but for complex airport layouts I can imagine many ways this logic could fail. Personally I think it would be more robust to stick to picking parking positions, and otherwise using the airport centre, because it would encourage people to add the parking position data :) I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible. — James Turner

I am delighted to have this cleaned up, and a way to incrementally init bits of Nasal, but I would be much happier to see a patch of the C++ difs, the sooner the better, just in case you're doing something that is not going to work safely. — zakalawe (Sun Oct 27). Re: Modular Nasal . (powered by Instant-Cquotes)

I really don't believe there should be an option to disable bootstrapping, it should just be an issue of matching FGData. Basically, if we have new-style scripts (i.e. using require() and deprecating "nasal-dir-initialized"), then we need a bootstrap script (because otherwise... we would have to reimplement the corresponding code in C++ space); else, we have old FGData (as I sometimes like to switch back to, to pursue other projects like the Nasal Browser) and we use the old C++ loading code. — Philosopher (Mon Nov 04). Re: Modular Nasal bootstrapping (again). (powered by Instant-Cquotes)

it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas) — Hooray (Sun Jul 06). FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). — Philosopher (Sun Jul 06). Re: FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

Given my recent "FGCanvas" experiments (making ~60% of the subsystems optional), and successes there, I'd probably consider handing off control to a hard-coded Nasal script in FGNasalSys, even though we could make the file-name property-configurable, whereas it would default to something like "default.boot". That would allow us to easily use --prop= (or a dedicated --mode=) parameter to override the bootstrapping script. Once that is place, we could also move certain fg_init.cxx logic to Nasal space by using Zakalawe's add-subsystem/remove-subsystem fgcommands, which I already started extending to allow subsystems to be registered as SGSubsystemGroup instead of "just" SGSubsystem - which allows us to use groups as "containers" for specific subsystems, like "aircraft" (fdm, autopilot, route manager etc) or "audio" (fgcom, sound, voice). Making these entirely optional and runtime-configurable is becoming much more straightforward that way - also, because all the reset/re-init logic can be moved to each groups postinit/reinit methods. Conceptually, that's straightforward to do, and apart from supporting different startup modes, we could even support "applications", i.e. stuff like running just the REPL, or just a canvas-map, or even just the Aircraft Center eventually. So, I'd prefer to load a single property-defined Nasal script and delegate control to it in FGNasalSys:init(), so that we can handle both there, nasal bootstrapping, but also subsystems at some point. — Hooray (Wed Jul 09). Re: Modular Nasal bootstrapping (again). (powered by Instant-Cquotes)

for FGCanvas-testing, I just used a slightly-extended version of this: diff --git a/src/Main/options.cxx b/src/Main/options.cxx index 0389faa..26eac9c 100644 --- a/src/Main/options.cxx +++ b/src/Main/options.cxx @@ -1434,8 +1434,9 @@ struct OptionDesc { int (*func)( const char * ); } fgOptionArray[] = { + {"mode", true, OPTION_STRING, "/sim/startup/boot-script", false, "default", 0 }, {"language", true, OPTION_IGNORE, "", false, "", 0 }, - {"console", false, OPTION_IGNORE, "", false, "", 0 }, + {"console", false, OPTION_IGNORE, "", false, "", 0 }, {"disable-rembrandt", false, OPTION_BOOL, "/sim/rendering/rembrandt/enabled", false, "", 0 }, {"enable-rembrandt", false, OPTION_BOOL, "/sim/rendering/rembrandt/enabled", true, "", 0 }, {"renderer", true, OPTION_STRING, "/sim/rendering/rembrandt/renderer", false, "", 0 }, diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx index fde6319..b8c2114 100644 --- a/src/Scripting/NasalSys.cxx +++ b/src/Scripting/NasalSys.cxx @@ -833,6 +833,7 @@ void FGNasalSys::init() .member("singleShot", &TimerObj::isSingleShot, &TimerObj::setSingleShot) .member("isRunning", &TimerObj::isRunning); +#if 0 // Now load the various source files in the Nasal directory simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal")); loadScriptDirectory(nasalDir); @@ -845,6 +846,20 @@ void FGNasalSys::init() simgear::PathList scripts = dir.children(simgear::Dir::TYPE_FILE, ".nas"); addModule(directories[i].file(), scripts); } +#endif + + const char* boot_script = fgGetString("/sim/startup/boot-script", "default"); + SGPath fullpath(globals->get_fg_root(), "Boot"); + fullpath.append(boot_script); + fullpath.concat(".boot"); + + + SG_LOG(SG_NASAL, SG_INFO, "Using boot script:" << fullpath); + SGPath file = fullpath.file(); + if(!loadModule(fullpath, "boot")) { + SG_LOG(SG_NASAL, SG_ALERT, "Error could not load boot script:" << fullpath); + exit(-1); + } // set signal and remove node to avoid restoring at reinit const char *s = "nasal-dir-initialized"; As you can see, the file name of the "boot script" defaults to $FG_ROOT/Boot/default.boot but can be easily overridden to add custom modes. Which is kinda where we could now add your bootstrap.nas logic and review the necessary C++ changes to make it work. For testing purposes, I used io.nas as the template for my own boot script, i.e. to load globals.nas, props.nas etc Once the hard-coded functionality is re-implemented, we can explore making things better configurable, i.e. more optional, over time. — Hooray (Wed Jul 09). Re: Modular Nasal bootstrapping (again). (powered by Instant-Cquotes)

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