scp-fs2open
Excessive Primary Fire On Standalones
Something seems to go wrong on some standalone servers where rollback will trigger many many extra primary shots for players.
Based on testing by @notimaginative, we believe this is caused by table mismatches on server and client. In order to fix this, we may have to more strictly ensure that both instances reference the same information. But that would not be an easy task.
To add some extra context... The mismatch theory is based on some testing whereby I tried different MVP versions connecting to a standalone running a known MVP version. When the versions matched the bug didn't appear to manifest. However there are two issues with this theory: 1) this has only been tested on standalone servers running release builds and only after the issue has been reported, and 2) there has been at least one instance where testing with an identical mod versions did not remedy the problem. A restart of the standalone has always fixed the problem.
Additionally, this issue has yet to be reproduced in a debug environment. No test so far (with debug builds), regardless of mod version mismatch, has replicated to problem. The issue also appears to be isolated to server-side code, but is not confirmed to be specific to standalones.
This bug has finally been tracked down to an issue with timestamp wrapping. The timestamps assigned are large enough to be usable for 12 days, but they are checked against a primary time that is usable for 24 days. So after 12 days the timestamp wraps and always passes the test that indicates whether it's time to fire. After 24 days the primary time wraps and the two are once again in sync. So it works for 12 days, is broken for 12 days, works again for 12 days, broken again ... etc.
That wrapping problem may be difficult to fix in code as timestamp/timer changes tend to affect things in unknown ways and it can take time for any new bugs caused by those changes to manifest.
For now the way best way to handle this problem is to simply restart standalone servers once a week. That can be done via systemd or a cron job. To be extra careful with PXO games, the PXO API can be queried to determine if the standalone is currently in use before shutting it down (you can query based on IP and port number to quickly get the entry for your standalone).
Also note that this bug was introduced in early 2022. So builds from 2021 and earlier, including retail, shouldn't have this problem.