AI : MCV deployment gets picked up as an exploit. AI MCV's dont deploy.

[zybiski]

Not tested if it works with cheats enabled yet..

[Mailaender]

Can you elaborate? Which version did you use? Who hosted the game?

[zybiski]

Hi Mailander,

well, i used 1104 but i think the same happens in 1019. The game is played
on unksi dedicated with another player. I think unksi himself.

basically what happens (or doesnt happen, rather) is that as soon as the
game starts with AI present, the AI will attempt to deploy, but because it
calls the function of deploy instead of just rightlicking the mcv, all
players get the message 'exploit detected ' -
and the MCV does not deploy. You can win the game by killing stationary
MCV's that did nothing. So, basically, AI does not work in 1104 an 1019
because the AI's attempt at deploying MCV gets picked up as an exploit.

What i have not attempted is to host the game with 'cheats enabled' to see
if it would let them deploy then.

Greetings,

Rocito

On Thu, Jan 3, 2013 at 1:03 PM, Matthias Mailänder <notifications@github.com

wrote:

Can you elaborate? Which version did you use? Who hosted the game?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2540#issuecomment-11841605.

[chrisforbes]

This is buggy on dedicated because the bot host isn't always client 0.

On Tue, Jan 8, 2013 at 9:29 AM, zybiski notifications@github.com wrote:

Hi Mailander,

well, i used 1104 but i think the same happens in 1019. The game is played
on unksi dedicated with another player. I think unksi himself.

basically what happens (or doesnt happen, rather) is that as soon as the
game starts with AI present, the AI will attempt to deploy, but because it
calls the function of deploy instead of just rightlicking the mcv, all
players get the message 'exploit detected ' -
and the MCV does not deploy. You can win the game by killing stationary
MCV's that did nothing. So, basically, AI does not work in 1104 an 1019
because the AI's attempt at deploying MCV gets picked up as an exploit.

What i have not attempted is to host the game with 'cheats enabled' to see
if it would let them deploy then.

Greetings,

Rocito

On Thu, Jan 3, 2013 at 1:03 PM, Matthias Mailänder <
notifications@github.com

wrote:

Can you elaborate? Which version did you use? Who hosted the game?

—
Reply to this email directly or view it on GitHub<
https://github.com/OpenRA/OpenRA/issues/2540#issuecomment-11841605>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2540#issuecomment-11970127.

[ihptru]

working on fixing it

[Mailaender]

Ugh, I tried to fix this, but I don't find it that easy to solve as @pchote promised without changing the network protocol which consists mostly of non-descriptive one-letter-abbrevation variables.

[Mailaender]

Well at least here is how to reproduce:

1. start a dedicated server
2. connect to the dedicated server with another instance
3. disconnect
4. connect again
5. add bots, hit start

[ihptru]

Client_id=0 as a control for bots is hardcoded. Once first client leaves dedicated, client_id=0 is gone and there is nothing to control bots

[Mailaender]

// Hack: Assumes bots always run on clientId 0.
var isBotOrder = subjectClient.Bot != null && clientId == 0;

Can we simply remove the who owns the bots check without breaking stuff?

var isBotOrder = subjectClient.Bot != null;

This does not seem to be easily exploitable on the user side. Remote control the bots to attack someone else with a hacked cheater client to troll the other players? I don't think it is that much of a serious issue. The legitimate bot controlling client could also be the hacker troll.

[ihptru]

it breaks everything, dunno why.

[Mailaender]

Okay, then this does not only validate the order, but also direct it accordingly.

[ihptru]

when I tried to fix it I had to change code in 3 different places but this did not help at all

[Mailaender]

I tried to change clientId == 0 to client.isAdmin but failed to deliver the Session.Client through the overloaded methods which seem to rely on sending bytes through the network in the end.

[pchote]

Maybe i've forgotten a subtle detail that makes this harder than it seems?

Bots are added by sending a slot_bot command to the server. This command is parsed by the LobbyCommands server trait to create a bot client. You want to add an int field to Client, let's call it BotControllerClient, and initialize it in the slot_bot handler to client.Index (client is the person who sent the order, and so presumably the person who wants to be running it locally). The list of Clients is serialized as yaml, so this new field will be synchronized between clients automatically. You may also want to modify the client drop logic to cleanup any bots owned by the dropping client.

In ValidateOrder, clientId == 0 then becomes clientId == subjectClient.BotControllerClient.

[pchote]

And of course, if you wanted the bots to always run on the admin's client, or evenly distribute them over all clients to reduce the CPU load on any one machine, you could initialize BotControllerClient with whatever client you'd like.

[ihptru]

just a notice for those who try to fix it: in Started game, once admin leaves, there is no admin left

[Mailaender]

Fixed it thanks to the instructions provided by @pchote in #2957.