If you remove and re-add the same uniform/vest/backpack in the same frame (non-scheduled SQF execution) the gear system corrupts and doesn't register the container with clients or the server, and any subsequent calls to addItemToUniform/Vest/Backpack are corrupted and do not register on anyone but the local machine in which it was called.
Introducing a delay fixes the issue, but this is a hacky workaround.
Execute the following code in the debug console on a dedicated server:
_uniform = uniform player;
removeUniform player;
player addUniform _uniform;
Items on the local players vest will be gone according to the items command.
If you look at the items of that player on a remote machine or on the dedicated server you will see that the items that were in the uniform are still there.
Executing addItemToUniform will show item added locally but it will fail to appear on any other client or the server.
You can exchange any of these commands for their vest of backpack equivalent and experience the same issue.
Only happens when removing and re-adding the same uniform/vest/backpack and when there is no delay.
This is a serious bug that can cause unexpected behavior down the line as it branches the inventories from player to player and from player to server causing inconsistencies.
Can this please get a good look into? It is a game breaking bug, especially in ACRE which relies on clients and the server knowing about the same gear load outs
Executing repro on dedicated server does not mess up the inventory. Seems client execution messes up server and not vice versa
Also, when changing uniform to another uniform and not the same class, new uniform can get corrupt in such way that when putting an item in it via inventory GUI, the item disappears on client too and of course never gets added on the server as well.
Fun!
Yes, when you corrupt the gear via the client, the server cant add items at all. If you do the repro above on the client, then execute something like this on the server: (playableUnits select 0) addItem "FirstAidKit" (assuming there is only one player in the test) you'll not see it on the server or the client.
This issue still appears to be present, or there is another issue that is causing gear desynchronization.
I was unable to reproduce this issue. Can anybody provide some additional info please? Thank you.
I recorded a video of an ACRE desync during a mission:
https://youtu.be/-ZCNCZZCWHw
7 players (one as MCC GM). The player (Abuk) died and respawned at base. From our POV he looked as if he wasn't wearing proper gear. He got into the humvee with us but his icon on the FTL hud did not change to indicate this. As shown in the video, we reached a spot about 1km away from the respawn point and the error popped up.
Yea people seem to still be experiencing this issue, especially with Arsenal. It seems like if you go into Arsenal in multiplayer with ACRE, switch through a few random sets of gear or change weapons or do anything that replicates the original scenario in this bug report it will trip the bug and the clients and server will begin to desync gear.
Still on-going issue in 1.62, @Killzone_Kid are you able to help @Adam reproduce this to get it resolved?