Playing sounds exclusively for "Local Player" can mismatch the game

[AdrianeYves]

Area(s) with this issue?

This bug is a graphical glitch or error

Describe the issue

local player is quite useful because it allows defining the player without needing to reference their specific index (e.g., "player-0 to player-7"). This means that using local player, an action can be triggered for all players without having to write separate scripts for each one—saving a lot of effort compared to manually creating eight scripts.

Unfortunately, local player tends to cause mismatches in multiplayer matches. While there are some scripts where local player works without issues, making it function correctly often requires using unconventional or "quirky" methods to avoid desync problems.

Steps to reproduce

1. Select a script that using a player as its default value in worldbuilder...
2. Select Local Player ...thats pretty much it

Attachments

No response

[helmutbuhler]

While there are some scripts where local player works without issues, making it function correctly often requires using unconventional or "quirky" methods to avoid desync problems.

Can you explain this in more detail? In what situation does localplayer work, in what not?

[kABUSE1]

Don't touch this.

Local Player works perfectly as intended and the use-case you have provided is not correct. You are using it wrong if it mismatches your map. It is not supposed to be a summarizer for player0-player7.

Bad example:
Transfering a unit to Local Player will transfer it to human player in a mission map / skirmish map against AI.
But if you watch the replay, it will transfer the unit to the replay observer, breaking replay functionality.
If you play with multiple human players, each one will see the same unit belong to himself, desyncing the game.

Good example:
If Local Player start position is "1" -> move camera to "Player_1_Start".
If Local Player start position is "2" -> move camera to "Player_2_Start".

Works perfectly fine and is the only way to move camera back to correct start position, depending on spot.

The only weird case where one would expect the scripts to work, but they still desync the game is playing sounds depending on Local Player.

If Local Player start position is "2" -> Play sound effect X

This will cause a mismtach even though all it does is to play a sound effect if your start position is 2. It is weird that localized sound effects have this effect.

[helmutbuhler]

Yeah, that's my understanding as well. Just wanted to know if AdrianeYves knows this as well or there is an actual issue here.

[AdrianeYves]

Oh shit is that how it works lol ? i guess we gonna need to warn people on how to use it then ... my bad you usually use it for conditions is that correct?

[kABUSE1]

Not all conditions work with "Local Player" but yes, I can't think of any use-case where it would make sense to use "Local Player" in a script action.

Yeah, that's my understanding as well. Just wanted to know if AdrianeYves knows this as well or there is an actual issue here.
The only actual issue is the sound thing I've mentioned.

Playing sound localized mismatches the game, which is super weird. So you have to do something like this to make localized sounds mismatch-free:

*** IF ***
     Unit 'player1' is owned by Player '<Local Player>'
*** THEN ***
  Play Sound 'RedGuardVoiceCreate' at Waypoint 'spawn_p1'.
*** ELSE ***
  Play Sound 'RedGuardVoiceCreate' at Waypoint 'far_off'.
  Disable Script 'spawn_01_sound_p1'.

Additionally, the mismatch only happens if the player you exclusively play the sound for is somebody WHO IS NOT THE HOST, lol. So player0 would be safe, player1 wouldn't.

It might be worth investigating, if this is the cause of other mismatch issues.

[Skyaero42]

If sounds are part of the CRC game state check, we should consider removing them from this check.

[augustresende]

Related: #369