scp-fs2open
proposal: decentralized checksum verification for multiplayer.
As I understand it the current system for multiplayer file verification requires a file-mod association database to be maintained on pxo, requiring action from both admin and modder to keep up to date. This is not really practical for in-development mods, especially with revitalized multiplayer interest leading to people outside of primary mod teams working to get things into multi. The effects of this can be seen recently where chronic issues with multi stability were eventually traced to one player having the screencam script in their data path, not having found it because none of their games had been with mods set up for file verification.
Most heavily moddable multiplaer games I am aware of handle things very differently. I don't know the guys but to the best of my knowledge they do a checksum of either all the gameplay-effecting resource files or the resultant game state and compare checksums between all the clients. A short, generally around five character alphanumeric string is displayed clearly on the game menus so users can immediately compare states without even entering a game, and joins with the wrong checksum will be rejected or at the least loudly announced.
This isn't strictly speaking an effective anti-cheat, as a cheater with much ingenuity at all would be able to make an fso build that just lies about the checksum. But it is a very effective stability tool for friendly games, and I think that is a much higher priority.
The checksum process seems conceptually simple, but making sure all relevant data/state is included is definitely no small task. But even limited coverage could likely be effective in avoiding many user headaches.
PXO does file verification as part of the anti-cheat process so that it knows if it's safe to store that player's stats. But the primary purpose is identification, the ability to tell FreeSpace Port apart from Warmachine or The Babylon Project. This lets PXO know how to store stats, what list of servers to send back, etc.. And it only needs enough unique data to figure that out, so it doesn't generally have to be kept fully up to date. The point being that the issue you described isn't something that the PXO validation system was ever intended to address.
A new verification system is on the roadmap though, specifically for the purpose you describe. The game server and clients would create a checksum of relevant files and connecting clients would send their checksum to the server during the join process. The server could then reject clients that don't have a matching checksum. Missions are already covered, so we just have to check a subset tables, and other state doesn't really matter. Build versions could also be included, though that has its own set of problems.
The issue there is usability/diagnostic related. Knowing that there is a data mismatch is great, but that setup doesn't say why there is a mismatch. You'd know that screencam guy had different data but not that screencam was the reason. That's the part of it we haven't figured out a good solution for yet.
Regarding screencam specifically, it's not multi friendly and should never be used with a multi game. We probably need to put that in giant bold text somewhere.