okay, it seems as if what I've written above is a little outdated - apparently, the "nasal via telnet" option has been explicitly added a while ago - seemingly, it just never got documented anywhere (?):
https://sourceforge.net/p/flightgear/ma ... /36227216/James Turner wrote:Well the good news is since a few days ago, Nasal can be done over Telnet, if you start FG with —allow-nasal-from-sockets
Send (over telnet)
>nasal
controls.raise_gear();
##EOF##
For example (the end-of_nasal marker can be customised if needed but ##EOF## is the default)
If in doubt, I'd suggest to check the
full thread for context (possibly while reviewing the corresponding commits) and then raise any remaining questions on the developers mailing list, offering to document the new feature on the wiki in the process.
Even though, speaking in general, the more proper answer to the questions posed in that thread (having a front-end agnostic abstraction wrapper to send notifications to the sim) would have been "Emesary", as Richard alluded to here:
https://sourceforge.net/p/flightgear/ma ... /36213611/Richard Harrison wrote:Of course now I'm going to mention that we really should look at a
directly bridging Emesary notifications via a socket and straight into
Nasal space - as that's a clean way of interfacing from the external
world. Probably I should add the C++ version of Emesary with a Nasal
bridge to the core at some point..
In other words, the I/O mechanism (keyboard, joystick/mouse) could greatly benefit from dedicated Emesary bindings/support, i.e. at the fgcommand/XML layer - so that aircraft, and certain aircraft functionality could "auto-magically" support RPC for key functionality, via Emesary notifications.
https://sourceforge.net/p/flightgear/ma ... /36213137/James Turner wrote:What we can't currently solve, is custom aircraft controls, or which
bypass controls.nas in non-standard ways - those will always need
something on the Telent (or whatever) client to know that aircraft's
peculiarities and be modified, I think
[...]
the simulator supplies some core
actions and some place-holder ones for 'AP disengage' but aircraft can
either replace existing ones or define completely new ones. This would
also allow easier customizing of input configs (joystick etc) per
aircraft since we can bind a button to action 'engine swivel' and if
there's no such action, do something else.
Part of the motivation here was also to fix the fact our mapping of
'ASCII' control codes to key shortcuts is very unreliable (number one
bug reports on Mac), but that's also where I got stuck since I'm trying
to ensure existing global and aircraft key shortcuts all work as before,
but also that different keyboard mappings (eg, which key combo generates
[ or ] for the flaps) are handled consistently. It's ... complicated.
[...]
Now if I continue with the action idea at some point in the future, then the ‘action’ element of the pick animation would become a ‘efis-waypoint-button’ action, and you’d be able to send a command like:
invoke_action(‘efis-waypoint-button’)
…. from Nasal or telnet or whatever. But this won’t work until I complete the action concept, and of course that aircraft are updated to use this concept.
As an side, it doesn't seem James is fully aware of what Emesary could bring to the table here ?
In case you're hoping to do higher throughput I/O via telnet, see James' comments here, where he talks about a dedicated mechanism to collection property subscriptions into "lists" that are marked "dirty" to allow lazy updates:
https://sourceforge.net/p/flightgear/ma ... /36213280/