by Hooray » Sun Feb 16, 2020 2:25 pm
That's a bit too low-level for my taste, i.e. not really scalable - I would definitely recommend looking at fgcommands and/or Emesary to encapsulate aircraft-specific Nasal code.
In fact, the lazy way would be to use Nasal to load a panel/aircraft bindings and procedurally wrap all bindings by registering them as fgcommands, that way you end up with a mechanism that also works over TCP/IP (props/telnet) or from C++ (SGCommandMgr).
Once you got the hang of fgcommands, you will probably appreciate the power of using Emesary notifications, which can also be registered as fgcommands.
Ideally, in a perfect world, aircraft bindings would not contain any Nasal "blobs" at all but would work via fgcommands only - embedding Nasal blobs all over the place comes with the same flexibility and power that Nasal embedded inside GUI dialogs brings with it, but also suffers from the same long-term issues.
Again, using ~50 lines of Nasal it should be fairly easy to write a helper function that opens a panel/cockpit to read out all Nasal blobs and wrap them as dedicated fgcommands that would then be aircraft specific.
This kind of setup would also work well for anything involving Phi/FGQCanvas or multi-instance setups (FSWeekend/LinuxTag)
Using Nasal "as is" is problematic for a variety of reasons, as you'll figure out once you try to support more complex aircraft/startup routines
Besides, there is a "checklists" subsystem which supports execution of checklists, in conjunction with the fgcommand/Emesary approach, you could literally execute checklists remotely - no matter if "remote" is in some piece of Nasal code, C++ or inside another thread/process