Thorsten wrote in Sun Jan 20, 2019 5:00 pm:You can't run the Shuttle in an external FDM because it requires integration between the various systems (JSBSim, Nasal,...).
I guess there's a misconception here - JSBSim merely runs the FDM out of process, but that's totally transparent to FlightGear,the external FDM mechanism I mentioned previously takes care of synchronizing the relevant properties in a transparent fashion using the aforementioned "FDMShell" mechanism - with your Linux background, you can imagine the whole thing to work analogous to "mounting", i.e. /fdm is mounted inside flightgear, but actually lives out of process.
Again, you are in a much better position to judge if this is a red herring or not - but conceptually, that is how this was originally supposed to work: there is the equivalent of a remotely managed property tree that is mounted inside flightgear, but created/populated and updated using a different process, which is also how "tied properties" came to be, and why they're used everywhere in jsbsim.
This isn't to suggest that this should actually "just work as is", but that the limitations you mentioned would be more relevant in the context of getting scripting/Nasal off the main loop, which is next to impossible unless the code in question is structured in a corresponding fashion (e.g. using a simple form of message passing akin to Emesary).
Conceptually, an external FDM (i.e. jsbsim) running out-of-process can still affect properties in fgfs and vice versa, via the so called "FDMShell" mechanism.
I don't know if this is anywhere documented other than in the archives, but it has been used by a number of people/efforts to hook up proprietary flight dynamics engines to FlightGear, that also had a nees to access fgfs properties and update fdm state in an encapsulated fashion
I do agree however that it is unlikely to work "out of the box", given that this is obviously a legacy fashion that most people are not longer familiar with, but also because the shuttle project has been sailing in uncharted waters since its very inception ...
Anyway, in the context of the infamous HLA discussion, the FDMShell mechanism is still regularly being brought up as one example of a well-encapsulated subsystem that could be easily moved onto another core/process (or even machine), because the FDMShell "subsystem" formalizes and encapsulates I/O dataflow dependencies.
I believe that some of the "old-timers" like Curt, Erik or Jon (sorry ...) might be able to provide additional background information here, unless the JSBSim manual documents the whole interfacing mechanism already.