Initializing Nasal early: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 29: Line 29:
** [[FlightGear Headless]]
** [[FlightGear Headless]]
** supporting stand-alone [[Nasal]]/[[Canvas]]-baased applications like a MapStructure-based moving map or a virtual [[Stand Alone ATC Control Development|ATC client]]
** supporting stand-alone [[Nasal]]/[[Canvas]]-baased applications like a MapStructure-based moving map or a virtual [[Stand Alone ATC Control Development|ATC client]]
{{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 ==
== Objective ==

Revision as of 01:58, 10 July 2014

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. 30}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Nasal Bootstrapping
Started in 07/2014
Description scripted startup, as per [1] and [2]
Contributor(s) Hooray, Philosopher (since 07/2014),
Status Under active development as of 07/2014
Topic branches:
$FG_SRC [3]
fgdata [4]



This is a summary of all discussions relating to:

  • initializing the Nasal scripting interpreter earlier 30}% completed
  • moving subsystem-specific initialization of Nasal APIs into each subsystem's bind methods, as per [5] 50}% completed
  • extending cppbind to keep track of added symbols, to easily remove them on demand Pending Pending
  • providing an integrated GUI front-end/launcher using Canvas and Nasal: Aircraft Center
  • moving $FG_ROOT/Nasal initialization out of C++ into scripting space (aka "bootstrapping") while introducing proper dependency resolution (inter- and intra-modular) 20}% completed
  • decoupling FlightGear initialization such that certain subsystems can be optionally disabled right at the beginning (e.g. FDM, sound, replay, scenery) 10}% completed
  • grouping related subsystems into SGSubsystemGroup instances to manage them holistically (e.g. xml-autopilot & route-manager) 20}% completed
  • making the initialization process/splash screen more responsive by using Nasal/Canvas instead of hard-coded GL code [6] (ticket #1456) Pending Pending
  • allowing custom startup profiles/modes to be implemented via Nasal helper scripts, for example: Not done Not done
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

Cquote1.png

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.[1]
— James Turner
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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)
Cquote2.png
  1. James Turner (2013-11-12 10:32:27). Aircraft positioning on the runway.


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);
}
Cquote1.png 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...)[1]
— James Turner
Cquote2.png
Cquote1.png 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.[2]
— Melchior FRANZ
Cquote2.png
Cquote1.png 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).[3]
— James Turner
Cquote2.png
Cquote1.png 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[4]
— James Turner
Cquote2.png
Cquote1.png 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.[5]
— James Turner
Cquote2.png
Cquote1.png 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.[6]
— James Turner
Cquote2.png


  1. James Turner (Mon, 17 Apr 2006 13:51:07 -0700). [Flightgear-devel] Subsystem run-levels.
  2. Melchior FRANZ (Tue, 18 Apr 2006 03:37:04 -0700). [Flightgear-devel] Re: Subsystem run-levels.
  3. James Turner (Mon, 17 Apr 2006 13:51:07 -0700). [Flightgear-devel] Subsystem run-levels.
  4. James Turner (Tue, 18 Apr 2006 08:23:01 -0700). Re: [Flightgear-devel] Subsystem run-levels.
  5. James Turner (Wed, 19 Apr 2006 06:43:14 -0700). [Flightgear-devel] Run-levels redux..
  6. James Turner (Mon, 17 Apr 2006 13:51:07 -0700). [Flightgear-devel] Subsystem run-levels.