The current anti-cheating protection, where the server keeps track of which application tries to access commands for which player, is ineffective at its goal and leads to issues. It is ineffective because it doesn't stop players from controlling other players' units or getting their information, the underlying scripting system already allows for such exploits (we just recently had such a case in the scripters tournament). The protection mechanism is however giving issues in the following use-cases:
When the user plays a game with one AI and then wants to play a game with another AI then the second AI doesn't work because it gets locked out by the server which is still looking for the first AI. I ran into this when trying to test both a debug and a release build of my AI.
A casting bot doesn't work. Specifically I was thinking of a bot which reads the game state of all players and controls the camera for casting. So it doesn't actually play the game, it doesn't make any changes to the game state, it just reads the game state for all players for camera control. This would also fail against the server's anti-cheating protection.
It makes the user interface for AI's clunky and error-prone. Specifically the user has to manually start and stop the AI's in their own user interface each game and make sure to do this correctly. A better way to do this would be to just have the AI listen to all 8 players (getting their goal/sn values), for the AI to set a particular goal/sn to a specific identifier value inside its .per file, and then take & release control of a player depending on whether the identifier is set or not.
I think it would be best to just remove the current anti-cheating protection since it's ineffective anyway. If an anti-cheating system is created it must be implemented at the command level (for example up-add-object-by-id should fail to add a non-player unit to the local - ie controlled - unit list, there are plenty more examples of this).
The current anti-cheating protection, where the server keeps track of which application tries to access commands for which player, is ineffective at its goal and leads to issues. It is ineffective because it doesn't stop players from controlling other players' units or getting their information, the underlying scripting system already allows for such exploits (we just recently had such a case in the scripters tournament). The protection mechanism is however giving issues in the following use-cases:
When the user plays a game with one AI and then wants to play a game with another AI then the second AI doesn't work because it gets locked out by the server which is still looking for the first AI. I ran into this when trying to test both a debug and a release build of my AI.
A casting bot doesn't work. Specifically I was thinking of a bot which reads the game state of all players and controls the camera for casting. So it doesn't actually play the game, it doesn't make any changes to the game state, it just reads the game state for all players for camera control. This would also fail against the server's anti-cheating protection.
It makes the user interface for AI's clunky and error-prone. Specifically the user has to manually start and stop the AI's in their own user interface each game and make sure to do this correctly. A better way to do this would be to just have the AI listen to all 8 players (getting their goal/sn values), for the AI to set a particular goal/sn to a specific identifier value inside its .per file, and then take & release control of a player depending on whether the identifier is set or not.
I think it would be best to just remove the current anti-cheating protection since it's ineffective anyway. If an anti-cheating system is created it must be implemented at the command level (for example
up-add-object-by-idshould fail to add a non-player unit to the local - ie controlled - unit list, there are plenty more examples of this).