Flightgear /engines/engine[n]/n{1,2} not override-able

[ghost]

Hi, I'm not sure whether this should be reported FlightGear or JSBSim, but

There is no way to re-assign FlightGear's /engines/engine[n]/n{1,2} to point to other JSBSim vars than propulsion/engine[n]/n{1,2}, and those variables are sent over multiplayer.

But as far as I found out about turbine model, n1 and n2 are not mechanical RPM, instead they are RPM adjusted to temperatures and always stay the same -- so one would want to drive animations / sounds from something else.

One can use other MP float vars for that, but that would be waste of bandwidth, plus, personally, I have already used up most MP vars for other things.

Up to until the last JSBSim sync I've been able to override them by aliasing FG vars to poiny to my custom functions, but that only worked partially: I could see the overrides only over MP, and locally had to drive sounds from different vars, now it just overwrites all the jsbsim filters I had aliased to /engines/engine/n[1,2] with "internal" n1 and n2, breaking both local and MP sound. However I don't see any "could not tie property" errors in the log.

Relevant files (n2 reused for thrust because I have only 1-stage compressors there):
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Tu-144-jsbsim/propulsion/RD-36_0.xml#L391
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Tu-144D-set.xml#L110
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Sounds/Tu-144.xml#L33
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Sounds/Tu-144-mp.xml#L21
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Models/Tu-144D.xml#L2447
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/PRules/animations.xml#L671

[ghost]

Another, less "exotic" problem caused by n{1,2} interface is, FG's flight recorder would not play them back -- I guess because they are tied properties.

[bcoconni]

There is no way to re-assign FlightGear's /engines/engine[n]/n{1,2} to point to other JSBSim vars than propulsion/engine[n]/n{1,2}, and those variables are sent over multiplayer.

That is not surprising since /engines/engine[n]/n{1,2} is overwritten by the JSBSim interface each frame.

Up to until the last JSBSim sync I've been able to override them by aliasing FG vars to poiny to my custom functions, but that only worked partially: I could see the overrides only over MP, and locally had to drive sounds from different vars, now it just overwrites all the jsbsim filters I had aliased to /engines/engine/n[1,2] with "internal" n1 and n2, breaking both local and MP sound.

That is unexpected as the code committed in FlightGear does not modify the interface between JSBSim and FlightGear.

Relevant files (n2 reused for thrust because I have only 1-stage compressors there): [...]

May be I overlooked something in the code extracts that you linked but I did not find a place where you are trying to overwrite the FlightGear properties /engines/engine[n]/n{1,2}

In the following files

• https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Models/Tu-144D.xml#L2447 and
• https://gitlab.com/mdanil/Tu-144/blob/0.10.2/PRules/animations.xml#L671,

the names are appended by an underscore _. For example, I saw references to properties such /engines/engine[0]/n1_ (with an underscore) but nothing such as /engines/engine[0]/n1 (without an underscore).

Once again I may have overlooked something but I did not find code which tries to alter /engines/engine[n]/n{1,2}

[ghost]

Hi,

the underscored n's are created by property rules, they are only a copy of the values I calculate within jsbsim -- I used them in singleplayer for sounds and animations.

I could only "overrwrite" /engines/engine[n]/n{1,2} by defining a JSBSim filter with name="" on them (but I had not defined it with name="/engines/engine[n]/n{1,2}", instead I had defined it along with the rest of engine stuff within the engine system's subtree and used <engines><engine[n]><n{1,2} alias="/fdm/jsbsim/blabla" in -set.xml to put it in place. But last time I tried, directly doing name="/engines/engine[n]/n{1,2}" would have exactly the same effect -- I did that just for clean separation of FG and JSBSim:
https://gitlab.com/mdanil/Tu-144/blob/0.10.2/Tu-144D-set.xml#L112

That behaved very fragile and I expected it to break at some point: the values set by the filter didn't show up locally, only over MP. So I had to make property rules that copy the filters' output elsewhere to drive local animations and sounds -- the aforementioned underscored n{1,2}_ -- sorry about confusing you, the underscored values are not part of the problem.

What may have changed is something to do with name="" vs. <output> or something around that, because I think I heard you say that <output> now does the same as name="" -- but then it's name="" that broke, not <output>.

[ghost]

On FG'S ML a guy mentioned he successfully "abuses" n1 and n2 in a yasim model, so it's indeed specific to JSBSim interface.

[ghost]

I got an idea. It seems that there are properties MaxN{1,2} in the engine's folder. Is it possible to expose the idle RPM like IdleN{1,2} as well? Then the user could adjust the current RPM indirectly by modifying the idle and max RPM.

[bcoconni]

Is it possible to expose the idle RPM like IdleN{1,2} as well? Then the user could adjust the current RPM indirectly by modifying the idle and max RPM.

Given that the engine thrust is computed from 'N2' (see the line of code below), I would advise not to proceed like that or you might alter the thrust in the process.

jsbsim/src/models/propulsion/FGTurbine.cpp

Line 232 in 2f2398c

thrust = idlethrust + (milthrust * N2norm * N2norm);

[bcoconni]

This issue has been moved to "Discussions". Now that this new feature is available in GitHub, it has been decided to move issues related to support requests and questions to "Discussions" and restrict "Issues" to bugs and feature requests.
This change is only motivated by project organization and will not affect the support provided. We'll gladly continue to answer your questions 😄.

[ghost]

So... if it's not possible/recommended to overwrite those values -- would it at least be possible to stop FG from sending them over MP? Or to make the properties in FG's /engines/ tree connected to the properties which would be actually useful for animation/sounds, unlike those purely-theoretical "adjusted RPM" (yes, JSBSim uses adjusted RPM, which stays constant versus temperature -- mechnical RPM increases with that) values?

[bcoconni]

So... if it's not possible/recommended to overwrite those values -- would it at least be possible to stop FG from sending them over MP? Or to make the properties in FG's /engines/ tree connected to the properties which would be actually useful for animation/sounds, unlike those purely-theoretical "adjusted RPM" (yes, JSBSim uses adjusted RPM, which stays constant versus temperature -- mechnical RPM increases with that) values?

I guess this discussion should take place in the FlightGear ML as the "glue" code between JSBSim and FlightGear is not maintained by the JSBSim project.

[ghost]

Thanks, will try to ask FG