We can start with the landing gear retracted

[GinGin]

Perhaps you don't remember, but the problem was fixed around October 6, 2019:

Yes," I don't remember" , that's why I posted a link to that thread in my answer above, do you even read the others answers completely ?

For the rest, please see my question at the end of that topic :


https://forum.flightgear.org/viewtopic.php?f=5&t=36288

[abassign]

Just this evening another FIAT G91R1B user told me about the problem with the cart reported in this post (I never modified the GIT after the beginning of this post on the forum so the user used a version of the previous plane). The user had not updated his version of FGFS for several months, but he updated it this morning ... and the G91R1B was with the landing gear closed if the simulation starts on the landing strip. For some weeks now I had solved the problem by entering a code that checks the status of the landing gear.
This modification also allows to solve another problem, when the plane is in flight the landing gear must stay closed ...
Unfortunately it does not solve the problem in the case of repositioning because the code is a file that is followed only once.

However, the incident confirms that the problem arose from a revision of FGFS 2019.2 which took place around mid-November 2019. I am convinced that JSBSim does not see all the information necessary for its initialization, it could be a binding problem with the property tree of FGFS, I think, but it is only a suspicion, that missing JSBSim of a synchronization system with the calling application (it is a problem that will arise tomorrow if JSBSim is run on a different CPU). In fact, on my system, if I query the "/sim/presets/onground" ... this property for JSBSim, it does not exist in the first few moments of execution and therefore the plane crashes.

However, this change, even if it looks like a patch, solves the problem and has the advantage of placing the landing gear closed when the simulation starts with the flying plane, which was actually what I wanted. Unfortunately it does not solve the problem when the plane is again positioned during the simulation ... as this script is not executed in that context.



File: G91-R1B-Common.xml

Code: Select all

<nasal>
....
      <set-gear-down-script>
            <script>
                if(getprop("/sim/presets/onground")) {
                    setprop("controls/gear/gear-down", "true");
                } else {
                    setprop("controls/gear/gear-down", "false");
                }
                print("#### initialize > controls/gear/gear-down set to true");
                print("#### initialize > /sim/presets/onground:",getprop("/sim/presets/onground"),":");
            </script>
        </set-gear-down-script>
</nasal>

[Thorsten]

However, this change, even if it looks like a patch, solves the problem

No, it's a hack that hides the underlying problem on the C++ side - it doesn't 'solve' anything.

[abassign]

... the phrase "it must be done through a hack" means someone has to write programming code to solve the problem because there is no pre-written software that does the job.

From: https://www.pcmag.com/encyclopedia/term/44046/hack

The XML is a programming language as reported in this link: https://www.britannica.com/technology/XML

However the problem is present and I think it is necessary in the future to redefine the way JSBSim is run. Personally, I would like to take it to a separate thread /However the problem is present and I think it is necessary in the future to redefine the way JSBSim is run. Personally, I would like to take it to a separate thread/CPU and then manage synchronization mechanisms with FGFS. This way can solve problems like descripted in this post and improve the simulator's performance.

[Thorsten]

However the problem is present and I think it is necessary in the future to redefine the way JSBSim is run

No, it is what I said - a bug on the C++ side that was fixed two weeks ago after it was properly reported with the relevant details.

I would like to take it to a separate thread/CPU and then manage synchronization mechanisms with FGFS. This way can solve problems like descripted in this post and improve the simulator's performance.

I'm fairly sure doing that would create plenty of new synchronization issues rather than solving the one which was already solved.

You seem to have a singular knack for selecting the absolutely most unsuitable tool for any issue

[Hooray]

You'll want to do a fair amount of benchmarking before you consider moving stuff to a separate thread/core - running the FDM is unlikely to actually become a bottleneck, I believe it typically runs at 120hz or something like that (?)
I don't know what aircraft has the most complex FDM, but I suppose the shuttle must have dozens of jsbsim-based "systems", and if the FDM doesn't show up there, it's probably fine to leave it "as is".
On the other hand, jsbsim fdms can be run in standalone fashion using the jsbsim executable, so you could use that to see if it makes any sense to even just consider running the fdm on a separate core - somehow, I highly doubt you'll be able to bother a modern CPU much.

The one thing where it might eventually make sense to consider such a move is FDM-driven AI traffic, because that could be trivially made to run on other cores without having to worry about synchronization issues, and it would mean that we could drive AI traffic using the existing route manager, autopilot/FDM infrastructure - which would simplify our existing AI code, while also making it more realistic - i.e. we could have airliners that actually use RNAV flight plans/procedures