The SyncLoadout packet is restricted to the same conditions as player-initiated loadout switches, causing potential desync

[drunderscore]

Is there an existing issue for this?

• I have searched this repository for an existing issue matching this description, and none exists. I understand this issue will be closed as a duplicate if this is not the case.

Tested platforms

• Windows
• OSX
• Linux

Reproduction steps (if known)

• Send a SyncLoadout to a player, designated for themselves.
  • It is noteworthy that this will not occur normally within the game, however server modifications can very much do so, and it becomes a necessary part of the SSC ecosystem to sync a player's own loadout index.
• Potential de-sync can occur.

Additional information

The preconditions for switching loadout indexes normally within the game are:

• You are not using an item (Player.itemTime and Player.itemAnimation are less than or equal to 0)
• The player is not crowd controlled (Player.CCed is false)
• The player is not dead (Player.dead is false)

(The following three conditions are part of the normal checks, however they are not needed to be changed)

• The switching loadout index is not equal to the currently selected index
• The switching loadout index is greater than or equal to 0
• The switching loadout index is less than the number of all loadouts (which is 3 since 1.4.4)

Issues arise when a server wishes to send a SyncLoadout to a player, switching their own loadout index. In transit of the packet, is is possible that the player's state changes (they use an item, they die, or become CC'd). In this scenario, the loadout sync would be rejected, leaving the server with no way to enforce a loadout index, which will cause desync.

This is important, as the loadout index should be treated a part of the SSC ecosystem -- and with the potential for the loadout sync to be rejected, the encapsulation of SSC, and control of the server of the player's character, is not upheld.

The solution would seem to be to not restrict the packet based on the initial three checks shown above, and allow it regardless -- only restricting player-initiated loadout switches to those.