Model Behaviour ASOBO_GT_Update LVar sign change fails sometimes

[MSFS 2024] Questions & Community Discussions Aircraft
1

Determined that this is not an MSFS bug. Preserving thread for reference.

Version: 1.2.8.0

Frequency: Consistently

Severity: Blocker

Similar MSFS 2024 issue:
Might be related to Model Behaviour ASOBO_GT_Update backlog on unpause

Bug description:
A weird one.
When using the ‘neg’ operation on an LVar within an Asobo_GT_Update, the operation sometimes fails. I have tried -1 * and a variety of other workarounds, but always seem to reach the same wall. It appears other calculations carried out on that execution work correctly but the sign change has been skipped.

I am using this sign change to control custom vibration animations in the CAS J3, which uses more custom code in GT_Update than is sensible, but it also appears with the most basic instance below.

Repro steps:

<UseTemplate Name="ASOBO_GT_Update">
	<UPDATE_ONCE>True</UPDATE_ONCE>
	<FREQUENCY>1</FREQUENCY>
	<UPDATE_CODE>
		1 (&gt;L:debugVariable)
	</UPDATE_CODE>
</UseTemplate>
<UseTemplate Name="ASOBO_GT_Update">
	<FREQUENCY>60</FREQUENCY>
	<UPDATE_CODE>
		(L:debugVariable) neg (&gt;L:debugVariable)
	</UPDATE_CODE>
</UseTemplate>

In the ‘Variables’ window of the ‘Behaviours’ window, observe that the sign change sometimes (in batches) fails, appearing as the sign change frequency reducing.

Please let me know if you have any trouble replicating this issue.

Thanks again for all your efforts and help, wishing you all a great holiday season.

Video shows the issue.

Blockquote

2

Your (L:VAR) neg (&gt;L:VAR) is flipping the sign on that L:VAR up to 60 times/sec so it might be random what you’re reading. Another minor technical detail that could become relevant is I’ve never checked in RPN whether +0 and -0 are the same value - sounds odd but it’s a common systems quirk that those can be different. I don’t think that matters with the code as-is though.

Minor additional point: I tend to keep the ASOBO_GT_Update simple with a single code block including the init and the update, as otherwise you’d need to look carefully at the Asobo templates source to work out what those simple-looking templates are actually doing. The underlying FSX/MSFS RPN capability is incredibly simple (and efficient) but that requires the templates to rely heavily on simple string substitution of your RPN code inside blocks of Asobo RPN code.

<UseTemplate Name="ASOBO_GT_Update">
	<FREQUENCY>15</FREQUENCY>
	<UPDATE_CODE>
      (O:init) 0 == if{
        1 (&gt;O:init)
        77 (&gt;L:debugVariable1)
      }
      (L:debugVariable1) neg (&gt;L:debugVariable2)
	</UPDATE_CODE>
</UseTemplate>

I changed the ‘neg’ code to update a different L:var given my first comment, but I may have misunderstood what you’re trying to achieve.

Note the ‘O’ variable is local to the component, so typically you can use the same “O:init” name for each component.

If I’ve somehow missed your issue entirely, apologies.

3

i use

(L:var) /-/ (>L:var)

4

Thanks for your reply, your comment about the 60hz refresh on that update prompted me to investigate a bit more regarding the frequency. What I now believe is happening is not random sampling but the GT_update occasionally synchronising with the framerate (which in my case is around 35 FPS) such that it appears in the same position every time. Strange that this logical bug wasn’t noticeable in MSFS2020.

Thanks all, I’ll move this thread out of bug reports and into discussion.