Thorsten wrote in Mon Feb 15, 2021 1:40 pm:Can't we make use of OOP magic to run two JSBsim instances in different threads, one for the shuttle and the other for the orbital target?
Who is 'we'? I can't make that, so the question is, can you?
FWIW, at some point, FlightGear did have support for an external FDM mechanism that would allow JSBSim PROCESSES to drive FlightGear, and people were also using multiple instances to do so.
Aside from that, there have been talks on the jsbsim mailing list about using some sort of embedded FDM/sub-FDMs (simulation in the loop) - some of that was discussed in the context of calculating VNAV profiles by running the FDM in "look-ahead" mode.
Speaking in general, with modern CPUs there's no need for threading here - even back in the early 2000s David Megginson actually suggested to support multiple /fdm entries in the main property tree, in the form of fdm[0] ... fdm[x] entries, which would get their own custom time-slices/update rates. by multi-plexing between different /position, /orientation nodes for each aircraft.
At the time, the rationale was that coding/using and maintaining pseudo FDMs for AI traffic would quickly become more complicated than running a "real" FDM with reduced fidelity (lower simulation rate/resolution).
At the time, FlightGear internally used the so called "FDMShell" mechanism to abstract away the differences between different FDMs - but that mechanism should still work today, and should not require any threading, but it would certainly require C++ changes. Back in the early days of the project, the "external FDM" mechanism was the only way to get the FDM off onto its own core (because it would run in a dedicated process)
For details about the parent/child FDM functionality, see Jon's comments quoted here: https://wiki.flightgear.org/Implementin ... Child_FDMs
Again, it might be best to check back with the JSBSim folks for details - either way, I doubt that this would involve any significant OOP or threading.
I cannot currently find David's proposal about multiple /fdm nodes in the main property tree, but he discussed the idea with Jon - and the context was indeed AI traffic driven by actual JSBSim instances, rather than using the pseudo FDM approach we're today still using.
More recently, Erik implemented DDS support and also provided FDM integration - besides, he's been around long enough, so he might remember a few more details, given that he's also been involved in JSBSim. But running multiple instances of JSBSim should not be such an issue, other projects have been doing that for years unless I am missing something ?
EDIT: Here's some of the context surrounding FDM driven AI traffic using FDM multiplexing or multiple FDM instances: https://wiki.flightgear.org/An_Integrat ... AI_Traffic