Radio operator cannot switch weapons properly

[Colin Basnett]

PFC Tyson [29th ID]: Radio operator can't switch weapons except whatever he uses as a main.

Log: DH_GerRadioItem no timer running with clientstate 3

[Colin Basnett]

This bug only exist in multiplayer.

[Colin Basnett]

Chasing this down and want to write this down so I don't forget. It seems that the check in DHPawn.SwitchWeapon on bRecievedInitialLoadout is returning false, so this will always fail.

[Colin Basnett]

Figured it out. VerifyGivenItems is failing, which in turn doesn't set bRecievedInitialLoadout to true. It is likely failing because the item is actually deleted as soon as it's given.

[Colin Basnett]

Fixed in commit 128a4b8.

The solution I chose was to have radios no longer be destroyed immediately, and instead, enforce a rule that the weapon can never be switched to.

[Matt Hands]

Ah, I'd forgotten this. I worked on it a couple of years ago when I did a swapping mutator, that replaced inventory items and vehicles with modded versions. Every swapped inventory item failed the verify inventory checks and so hit the same bug, so I had the mutator set bRecievedInitialLoadout to true on every DHPawn that spawned.

The radio definitely is caused by that unique item being destroyed after creating its radio trigger (which also caused a radio resuppply bug in 5.1, where multiple radio triggers got created because the resupply detected the radio was a missing inventory item).

But the problem is wider than the radio, although that is its most common effect. If a mapper types the package.class name incorrectly in the RoleInfo's GivenItems array (which is text and not a class pick list), the pawn never receives that non-existent item and so never passes the verify inventory checks. A common occurrence I saw was a mapper copying a GivenItems DH_Weapons.class string and changing the class to one in DH_ATWeapons or DH_Inventory, so the item never spawned and the player couldn't switch weapons. It also occurs if the mapper selects an abstract class from the primary/secondary/grenades pick list. The abstract can't be spawned so you get the bug. Examples in 5.1 official maps were Cambes (abstract PistolWeapon for Brit corporal) and Gran (abstract GrenadeItem for US squad MG).

So I think we need a wider solution than radios. When I first did the swapping mutator, I built in a 1 second Timer() delay before setting bRecievedInitialLoadout on a newly spawned DHPawn. This was because, although I couldn't see a compelling reason why players shouldn't switch weapons before they had received them all, I was being cautious. A second was always going to be enough to receive anything through replication that you're going to receive. But later I removed the delay and just set bRecievedInitialLoadout on a new DHPawn as soon as the mutator was able to. That ran for a long time without apparent problems on the GG server and probably still does.

So two options, I think: 1) Set bRecievedInitialLoadout on DHPawn after a short time to allow for replication of inventory. 2) Deprecate bRecievedInitialLoadout and verify item checks, removing bRecievedInitialLoadout from switch weapon functions.