UPDATE_ONCE never updated

Version: 1.4.7.X

Frequency: Consistently

Severity: High**

Similar MSFS 2020 issue: : nope, in 2020 works ok!

Bug description: it looks like UPDATE_ONCE never runs, sample code, in 2020 works,
code assign a random value to the Zvar,
driving the visibility of the node,
in 2024 Zvar is always zero
(forcing the var to other values shows expected result, see screenshot

Repro steps: code for a simboject

	<Behaviors>

	<Include ModelBehaviorFile="Asobo\Generic.xml"/>

<Component ID="updateonce">
				<UseTemplate Name="ASOBO_GT_Update">
					<UPDATE_ONCE>TRUE</UPDATE_ONCE>
					<UPDATE_CODE>
						rand (&gt;Z:XMLVARElga, number)
					</UPDATE_CODE>
				</UseTemplate>
</Component>




	<Component ID="elga" node="Armature">
	 <Visibility> 
        <Parameter> 
            <Code>
                (Z:XMLVARElga, number) 0.7 &gt; if{ 1 } els{ 0 }
            </Code>
        </Parameter> 
    </Visibility> 
	</Component>
	</Behaviors>
1 Like

Hello @mamuDesign

This happens with a human SimObject placed in a scenery, correct?
Can you share the SimObject in question with us?

I tried replicating the issue by modifying the windsock SimObject but I’m struggling so far.

Regards,
Sylvain

you’re right :smiley:

sample project attached
(actually the main goal is to randomly display people with modelAttachements, so I setup the object like so)
six points around each table, people should have 70% probability to show, in 2020 they are ok (ish, a bit shy, I would expect more crowded table with 70%)
but in 2024 restaurant is out of business


sixNations.zip (311.2 KB)

btw also looking for a way to randomly swap them in their seats (without having to merge all the models in a single one with multiple nodes if possible)

2 Likes

The problem doesn’t seem to be related to UPDATE_ONCE, it’s just happening if the object is attached to another one using ModelAttachements.

I can confirm this is a regression from SU1.

I exited the SU2 Beta, restarted the sim, no change to the objects, and Visibilities in ModelAttachements are working again.

Our theory at the moment is that it’s an issue with the rand seed initialization.
It would be identical for every objects and therefore the first rand would always return the same value.
We have a fix candidate and we need to do some more testing. This would be fixed in SU3 at best, though.

Regards,
Sylvain

1 Like

This is very unfortunate, is there anything you can do ? It’s a clear regression from SU1 and it will affect a lot of released products.

While this is not an issue as long SU2 is in Beta (we can always tell users to exit the Beta), it will be a big problem with SU2 will came out and everybody will be forced to update.

Forcing us to change completely the whole structure of released products that worked perfectly fine until SU1, and forcing us to do it again with SU3.

Please spare us and all end users from this.

1 Like

Doesn’t this break your GSX too?
According to this statement you are using ModelAttachements

It would be a real pain to have to wait for several months

Yes, it surely breaks GSX, we use ModelAttachements in many objects.

What’s weird is that not all of them seem to be affected, but it’s not clear why, and it’s a long process even testing each one to see which ones are affected, considering we have hundreds of them.

Fixed in latest SU2 beta build.
Both the ModelAttachment regression and random number generation were a problem in this context.

Regards,
Sylvain

2 Likes