IS USER SIM is not returning correct values for Multiplayer Aircraft

[MSFS 2024] Bug Reports Aircraft
1

This issue is affecting several of our aircraft (C17 Premium Deluxe, MH60, CH47)

We’re trying to control visibility of objects across Multiplayer (for example: Ground Power Units and ground equipment, external loads, interior/exterior components tied to camera state). To do so, we are using IS USER SIM to determine if the aircraft rendered is the user’s aircraft (Render object normally) or a Multiplayer Aircraft (do not render object).

However, the results we are getting are as follows:

  • IS USER SIM always returns 1 on user aircraft, correct behavior.
  • IS USER SIM returns 1 on Multiplayer Aircraft of the same type (eg. if user is a C17, and MP is a C17, returns 1), incorrect behavior
  • IS USER SIM returns 0 on AI aircraft, correct behavior.

This therefore not only is preventing us from implementing a solution that excludes certain elements from rendering on Multiplayer aircraft, but additionally is contradictory to the SDK description “Is this the user loaded aircraft - BOOL”

@FlyingRaccoon @Boris

2

(A:EMPTY WEIGHT, Bool) ! :face_blowing_a_kiss:

2 Likes
3

Nice workaround - thanks!

4

is a workaround but the variables needs fixing.. lots of my products have code checking if the user is SIM to avoid logic, and code that is unnecessary for AI / Multiplayer users..

So, we need a fix for this regardless.. otherwise we have to patch an entire product line to fix this.

R.

1 Like
5

Hello,

This will be reviewed.
I will let you know when I have some news to share.

Regards,
Boris

1 Like
6

Asking just to confirm:

using the EMPTY WEIGHT simvar works to discriminate the user aircraft because in a multiplayer injected aircraft the core aircraft simulation is NOT running (so those planes sees EMPTY WEIGHT = 0) but the model XML for the same matched aircraft IS running & eg. controlling its animations, albeit with most simvars reading zero?

So that has at least two use cases?:

  • simply disabling some animations on your aircraft if it’s only being used in the sim to match a multiplayer aircraft as in (IF USER SIM) => do animations
  • if you’re in a situation where BOTH the multiplayer and the local pilot are flying the same plane (or one from the same developer) you can
    • (IF USER SIM) => set L VARS
    • use those L vars to control an animation in every matched multiuser aircraft which are nominally running the same XML but will fail the (USER SIM) check so won’t try and SET the LVars.

? that look right?

7

Correct

		<UseTemplate Name = "ASOBO_GT_Anim_Code">
			<ANIM_CODE>
			(A:EMPTY WEIGHT, Bool) 
			if{ 
				(L:ELEVATOR_ANIM) 
			}
			els{ 
				(A:ELEVATOR DEFLECTION PCT, Percent) 2 / 50 + 
			} 
			</ANIM_CODE>
			<ANIM_NAME>Elevator_PCT</ANIM_NAME>
        </UseTemplate>
1 Like
8

Hello @here,

Could you test this in SU4 flighting and let me know if IS USER SIM for the other aircraft still returns 1 when you’re in a multiplayer session with other players flying the same aircraft (and same test with AI please) ?

Edit :
IS USER SIM is working when checking it in SimvarWatcher but indeed the behavior seems to have an issue with this.
I logged a bug about this

Regards,
Boris

1 Like
9

Hello @vantech

Are you sure this is an issue with the IS USER SIM simvar?
The simvar seems correct from what we can see.

However, we suspect you are driving your animations using classic L variables (non scoped ones).
These are shared across all instances of the SimObject

image
image1084×479 54.8 KB

In fact, using the SimObject spawner, I could also replicate the issue with AI aircraft with the front left door animation being driven by a non scoped L variable.
What happens is, even if your different instances have a different IS USER SIM value, whoever writes that animation or visibility L var last wins.

Instead, you want to use L:1 scoped variables, which will be independent for each instances of your SimObject.

Let us know if this is the correct explanation and switching to L:1 vars solves your problem.

Regards,
Sylvain

10

Didn’t know about L:1 vars used in this context, but indeed it may be related. I’ll take a look.

1 Like
11

Hello @vantech
I’m tagging this topic as by design.

Feel free to ping us is there is an issue with L:1 vars method.

Regards,
Boris

12

This topic has been automatically closed after 60 days of inactivity since it was marked as by-design.

If there is important new information about this same report, you can use the “Request reopen” button below to ask the moderation team to review it again.
For other issues or broader discussion, please open a new topic in the appropriate category.