Flaws in AutoDeployManager

[dnqbob]

1. It still use bot tick, but it seems that openra only enable bot tick when there is AI player
2. May cause Desync (maybe also due to bot tick)

[dnqbob]

Desync see
Inq8/CAmod@1ab01ef

[GraionDilach]

The second point does not apply to upstream - 042e497#diff-48b15fbfc69332c2659b4b0249b8734299bcc7b71c99570b5d8ad150b69afeb7R53 already used LocalRandom - and downstream fixed that properly.

BotTicks only run on the host, using SharedRandom there causes desyncs.

The first point seems to be valid. Hmmm.

[dnqbob]

so if we want to make it functional on human player, I guess we still have to use ITick instead of bot tick, meanwhile if we apply this change, the LocalRandom will have to become the SharedRandom

[GraionDilach]

It's not that simple. If you do that, you end up with multiple deploy orders in the order queue during a multiplayer game because each player will generate the automatic deploy orders for everyone (and having duplicate orders in the queue why I revamped this to a notifier-based centralized system in 042e497). Only the host should generate the deploy orders.

A hack would be to add a Game.IsHost check to https://github.com/AttacqueSuperior/Engine/blob/master/OpenRA.Mods.AS/Traits/AutoDeployer.cs#L102 and keep LocalRandom in the BotTick-turned-ITick (which can also receive the Game.IsHost check for client perf).

I have not tested this though and atm I don't have an interest at dealing with OpenRA. https://ppmforums.com/post-599950/openra-dev-blog/#599950 is disgusting and I have zero interest in dealing with multiple times.

[dnqbob]

Reasonable. multiple orders takes more system resources.

[dnqbob]

As for OpenRA, maybe we should get used to it, maybe not.