BZFlag-Dev
new issue with flags (which map to World Weapons) between versions 2.4.26 & 2.4.30
BACKGROUND:
The GunGame plugin is centered around intercepting normal flag activity so that players work through a server-defined progression of flags.
This means controlling what flag a player may (and must) have. Assigning them, re-assigning them on "drop" events.
THE ISSUE:
With the latest 2.4.31 branch an issue came up in the plugin where it would sometimes not be able to issue certain flags. In these cases, it was consistently never able to issue specific flags on specific maps. The maps did have the flags included in them.
DETAILS:
This only happens when a map has World Weapons. When the server tries to give the player one of the flags which matches a World Weapon (in this case SW) it would fail. If SW was removed from the flag procession, the next World Weapon flag (IB) would have the same issue. And the following one (SB) as well. Maps without world weapons had no issues. Removing the world weapons from the maps resolved the issue. Restoring 2.4.26 version of bzfs (which I had been running prior - the system installed binary) - also resolved the issue.
Tracing the bz_givePlayerFlag() function I'm calling in bzfsAPI.cxx to give the flag, it's the "bogus flag" branch around line 2791.
If I comment out the contents of the FlagType destructor in common/Flag.cxx also resolves the issue.
I tried a vanilla bzflag game with the same map (no GunGame plugin) and players can indeed pick up flags which correspond to World Weapons without issue (such as SW).
I bisected the issue down to 4d89ea9623474cf0a4cecd1cfc3a17fd995181f7. The FlagType destructor was added, which removes a flag type from the flag map. This ends up getting called in WorldWeapons::fire() because we create a non-const copy of a flag type, and when we leave the scope that defined it, it ends up being destroyed.
This should be resolved in the 2.4 branch as of aff1d65237575d498f285490af519f93588f0e4d and will be included in the 2.4.32 release.