Talk:Nasal Initialization

FGNasalSys init

Referring to your addition at [1], the FlightGear portion of the patch you can find at Initializing Nasal early is trivial, but it can be used to expose FlightGear's initialization to the property tree by using a so called Property Object. That is exactly how the init sequence of fgfs has been documented on the article's talk page: Talk:Initializing_Nasal_early#Subsystem_Creation. To look at some of the original work, see the commits at [2]. In particular, you may want to take a look at the mechanism used to automatically dump the init sequence to a hash for inspection purposes [3]. In other words, if you'd like to understand parts of the current init sequence (nasal or not), this is a really straightforward approach - i.e. expose things via properties sg::PropertyObject<std::string> and then use a Nasal space listener to track all updates - at that point, you can automatically populate your wiki article, and don't need to manually do any reverse engineering, all you need to do is register a callback to track all loading of Nasal sources in sequential order, you can then use the CPP macros __FILE__, __FUNCTION__ and __LINE__ respectively to add useful information/pointers. That way, you end up with a self-documenting init sequence, which should also come in handy for stuff that bugman has been working on (regression testing and Python support). --Hooray (talk) 13:34, 8 January 2020 (EST)

Custom modules

JSB, these aren't currently discussed in your article, but you may want to check out Creating_new_Nasal_scripts#Creating_new_Scripts (yes, that's in fact one of those evil articles mainly consisting of quotes collected from the devel list archives, containing pointers and information that isn't made available elsewhere, i.e. putting modules under $FG_HOME/Nasal). HTH --Hooray (talk) 14:46, 9 January 2020 (EST)