[PATCH] Freeze the game using cheats

[elexis]

Reproduce:

1. Start a game with cheats enabled
2. Select a building
3. Type "salad bowl 99999999999"

It will attempt to spawn that many units with unintended consequences (for example rebooting windows).

This has been used by at least one troll to crash games.

[Stan]

This patch limits the number of batch cheat spawnable units to 500 add a comment, and document a bit the cheat function.

[Stan]

While we are at it some things could be improved:

• We could batch create units 5 by 5 to save some function calls if that helps (If number is high enough ofc)
• We could replace the for lopp by a for in to clean it up.
• We could check for MaxPop to prevent it from going over 1000

I'm leaving this patch as is, waiting for feedback by the person who will commit it.

[elexis]

• Notice this patch does the check in the right place. If a cheat is typed, it will be sent as a simulation command and that one will call the cheat-function. Thus a script kidde can't just remove the check and repeat the exploit. (Thus we don't have the problem of trusting the client).

• Use something like input.parameter = Math.max(<LIMIT>, input.parameter)

• Reducing the number doesn't seem sufficient. To many units can still be created by repeating the command.

Proposal: How about only spawning as many units as the population limit allows? This is the only way I can imagine to completely solve the problem.

[Stan]

This patch limits the max number of spawnable units to the maxpop, preventing lag and abuse. It's no longer needed to replace the for loop too.

[elexis]

No reason to wait, patch looks sufficient to be commited.

• one space missing after input.parameter
• Comment could be changed a bit
  • it's obvious that a function uses its argument
  • you could mention that the function executes a simulation command

[Stan]

Updated.

[mimo]

Why is the limit (maxPop-currentPop) ? I fully agree about limiting the number of spawned units, but the limitation at maxPop seems too strict to me ? we may imagine some new SP player having a hard time against the AI with already a pop near the max and needing to spawn more units with the cheat. Would seem more reasonnable to me to put the limit at n*maxPop (with n=2 a sensible value).

[Josh]

How about we limit it to 100 over the maximum population? That should be plenty of room. (more than that would probably be too slow anyway)

We should also display a message to the user if there isn't any population room.

[elexis]

Replying to Josh:

How about we limit it to 100

Then you can repeat it to crash the game. (Two keystrokes needed with the javascript console to repeat)

We should also display a message to the user if there isn't any population room.

Might be an idea, but it will be visible to all players since it's in the simulation.

[Josh]

Replying to elexis:

Replying to Josh:

How about we limit it to 100

Then you can repeat it to crash the game. (Two keystrokes needed with the javascript console to repeat)

We should also display a message to the user if there isn't any population room.

Might be an idea, but it will be visible to all players since it's in the simulation.

Please don't take my comment out of context. I said, "How about we limit it to 100 over the maximum population?" (emphasis added).

It also looks to me like Cheat is not a network-synchronized command, but triggers a set of network-synchronized commands. Without a full architecture review, I cannot be sure if user-triggered cheat commands go through the GuiInterface. If they do, you can just return a failure status to the caller through that without much work.

[Stan]

I will update the patch thank you Josh for looking into it.

[Stan]

Raise the limit to 600 if Tardis cheat is enabled, MaxPop + 100 otherwise.

[elexis]

Replying to Josh:

Please don't take my comment out of context. I said, "How about we limit it to 100 over the maximum population?" (emphasis added).

Ah, sorry, didn't understand that. You are right, that could be done.

It also looks to me like Cheat is not a network-synchronized command, but triggers a set of network-synchronized commands.

Cheats can only be sent as simulation commands:

• Cheats are parsed locally and sent as simulation commands: see submitChatInput() calling executeCheat() calling Engine.PostNetworkCommand() with type="cheat" queueing the network simulation command, which will call Cheat() in Cheat.js identically for all clients.

• Clients don't look for cheats in other players chat: see handleNetMessage() in messages.js calling addChatMessage() calling parseChatCommands(), but no Cheat-code.

If any player has some custom cheat, he will just become OOS, crash him/herself and doesn't affect the other clients.

[elexis]

I made some brief tests spawning units (which actually don't have a space to spawn):

• 5k units -> 10 seconds
• 10k units -> 15 seconds
• 20k units -> 30 seconds

So spawning at most 500 units should be fine.

---

Second Proposal: I remember the sunken ship lag (r16636) also crashed games. A ship with 20 or more units inside often took more than 30 seconds of simulation time and thus disconnected the host, crashing the game.

This bus seems identical, maybe we can even adopt the fix in r16636 so that it would stop trying to spawn immediately after one unit doesn't find space to be spawned?? This would be the ideal fix.

We should still use the limitation as spawning an infinte amount of units will still result in lag-of-death.

[elexis]

Since we have #3546 now, this can wait.

[elexis]

In 17474:

Limit the number of units spawned when using cheats to prevent freezing the game. Based on patch by Stan, fixes #3545.

[elexis]

Thanks for the patch.

Notice though that it's Math.min, not Math.Min. Please make sure to use the correct function names.

I don't see the point in adding magic values, hence I didn't add the +100. If you want to spawn more units using cheats, use the max-population cheat or play with the "unlimited pop" setting.