RPN Code stops working on drone cameras

Bug Reports Aircraft
,
1

Version: All versions

Frequency: Consistently

Severity: High

Context: Mounted in community folder, devmode or marketplace

Bug description:

When we put custom code in RPN that is incredible important and necessary to override certain base sim vars due to MSFS limitations or due to the requirement to implement custom solutions such as, custom ITT, NG, and other simulations behaviours. The code stops to work as soon as the camera drone is active and moves away from the airplane.

I understand this is for performance purposes, and makes sense for multiplayer objects. But for the user airplane is just causes incredible bad bugs and behaviours, even sounds can go wrong.

Below is an example, when the FSR500 is on full reverse due to TurboProp limitations we have currently in the MSFS Turbos simulations the engine spins out of control even beyond to what we have set in .cfg files (I reported this issues 6+ months ago), to overcome the limitation I wrote custom simulations that overrides, fuel flow, NG, Prop RPMs, etc. to keep it as per the real aircraft behaviours.

Now when the user switches to drone camera and moves away from it, some code that I placed in .XML to save performance from WASM → SimConnect due to how heavy I have to overwrite MSFS SimVars fails to work… making the PROP RPM:1 spins 4433,7753 even when the governor should keep it at a max of 2000 RPMs, however during reverse FSR500 can only get to a max of 1800RPMs and my custom code takes care of that, but with drone camera away from the airplane this is the result:

image
image881×416 35.1 KB

This breaks the sounds since now the RPMs are too high:

Ideally we need a tag on the GT_UPDATE code that says execute this always, and it gets executed despite of the distance at least for the user aircraft.

Repro steps:
Load FSR500, put the engine in full reverse, move the drone camera like in the video above

Thanks to the team for investigating this, and let me know if there is anything I can implement to mitigate the behaviour or implement in the future to avoid the issue. I have advised customers in the meantime to avoid drone cameras with engine on full reverse, lucky enough I have the rest of my custom simulation inside WASM so normal engine operations are not affected, however MANY OTHER products out there are suffering from this problem and they don’t use WASM to be able to prevent the issue.

All the best,
Raul

2 Likes
2

That also affects our aircraft. The Kodiak uses RPN to simulate damage modelling and if the user drones away from the plane the aircraft will break all the time. The sound glitch is also present here.

1 Like
3

Hello @SimbolFSReborn @SWS-AlexVletsas

I assume your code is in your interior XML files?
You have to keep in mind those are ModelBehaviors and are necessarily related to how your models are loaded/unloaded.
It is very convenient to have an update component that runs a particular logic but it can’t be separated from the model it is supposed to drive.

In this case, switching to an external camera and rotating it away from the aircraft culls the cockpit LODs.
You can see it with the Statistics Profiler that shows your interior LOD1 is no longer active.

You can move that specific logic to your LOD0 external model that is always active.
You also have the possibility to execute RPN code from a WASM gauge with execute_calculator_code.

Regards,
Sylvain

3 Likes
4

Hi Sylvain,

So you saying to move the code to the LOD0 of the external model will keep it running?

I am aware of WASM and the execute_calculator_code ., but being single threaded certain process such as the ones described on my post are better to be left outside of it…

Thanks for your advises, do you think we should move the .XML to external model instead? will it keep the update frequency speed we need?

Best,
Raul

1 Like
5

I couldn’t check it as I was testing an encrypted version of your aircraft but I think it will solve your issue yes.
Regarding update frequencies, that’s something you can adjust as far as I can tell.
https://docs.flightsimulator.com/flighting/html/Content_Configuration/Models/ModelBehaviors/Update_Frequency_Preset_Definitions.htm

1 Like
6

ok this is very helpful many thanks, I will try this after the xbox release is completed, we focusing now on it.

Thanks again for all your help Sylvain.

Best,
Raul

7

Sylvain (@FlyingRaccoon )

So, because the cockpit LODs disappear in the 3D scene, is it possible that whatever UPDATE callback I have in the cockpit XML model behavior do not get executed when the drone camera is farther from the user aircraft? If so, I’ll try then the solution proposed by Raul (@SimbolFSReborn ).

Thank you.
Regards,
Carlos Gonzalez
CEO & Lead Developer - NextGen Simulations

8

@FlyingRaccoon

Is there an example on how to use them? E.g. which is the correct syntax of the two?

<Component ID="MyForcedUpdatesComponent">
   <UpdateFrequencyPreset="Asobo_FrequentWhenSmall"/>
   <UseTemplate Name="ASOBO_GT_Update">
      <FREQUENCY>10</FREQUENCY>
      <UPDATE_CODE>Whatever</UPDATE_CODE>
   </UseTemplate>
</Component>

Or is this correct?

<Component ID="MyForcedUpdatesComponent">
   <UpdateFrequencyPreset="Asobo_FrequentWhenSmall">
      <UseTemplate Name="ASOBO_GT_Update">
         <FREQUENCY>10</FREQUENCY>
         <UPDATE_CODE>Whatever</UPDATE_CODE>
      </UseTemplate>
   </UpdateFrequencyPreset>
</Component>
9

@cdgonzalezgo Yes. Use the Statistics Profiler to make sure your model is active when you have the issue.

@SWS-AlexVletsas It would rather be:

<Component ID="MyForcedUpdatesComponent">
   <UpdateFrequencyPreset>Asobo_FrequentWhenSmall</UpdateFrequencyPreset>
   <UseTemplate Name="ASOBO_GT_Update">
      <FREQUENCY>10</FREQUENCY>
      <UPDATE_CODE>Whatever</UPDATE_CODE>
   </UseTemplate>
</Component>

or

<Component ID="MyForcedUpdatesComponent">
   <UpdateFrequencyPreset Name="Asobo_FrequentWhenSmall" />
   <UseTemplate Name="ASOBO_GT_Update">
      <FREQUENCY>10</FREQUENCY>
      <UPDATE_CODE>Whatever</UPDATE_CODE>
   </UseTemplate>
</Component>
2 Likes
10

Okay, I can try it this way. Thank you Sylvain (@FlyingRaccoon)!

Regards,
Carlos Gonzalez
NextGen Simulations