Some people saying it's due to certain player(s) spamming structure queues

I have investigated and found the cause of the lag in this game. spaceT issued an llt spam build in the lower right corner at ~07:54 in response to a resign vote or something. This was very clearly deliberately done and a report has been filed.

You would have to give us some reason to believe that queueing up massive amounts of buildings, across multiple games, multiple times per game, was not a deliberate act to cause lag.

Does queuing up a lot of buildings cause lag? I feel like I see big wind farms and never have lag problems with those. (Not trying to take sides or anything, just curious.)

The problem isn't the amount of lotuses being queued. The problem is that this gigantic block gets thrown out all at once which causes major problems. We're talking about 500 commands + being issued in the same frame. There's some limits in place which is why this big block of lotuses take so long to appear. I can't go into technical depth but I can tell you issuing lots of commands at once makes the engine make sad windows noises. Normal users will never encounter this problem in normal usage but this game did not have normal usage.

I am in full support of this ban. If we didn't ban exploiters who willingly ruin 8 games in a row then we send a message that it is acceptable to ruin games. I would personally prefer that to not be the case here.

I will reiterate this: the queue itself isn't what caused the lag its issuing all those orders at the same time that causes it and that is a lot harder to kill off, if not impossible. Even if you could enforce this, the perf hit would be not insignificant as issuing orders is extremely common and would open another venue of attack.

TL;DR: there is no easy solution here as far as I am aware.

You'll still encounter the problem even if you limited it to 1. The problem is in order to keep the game synced, everyone has to send their commands over the network (which means sending 8000 'build lotus' commands to everyone which causes the lag). What you're proposing is doing something after the commands are sent (AllowCommand). What you WANT is CommandNotify which does not provide enough information to us to prevent the problem from occurring. CommandNotify and AllowCommand are two very different callins (read: events):

CommandNotify:
- Happens BEFORE network transmission
- Allows coders to block commands from propagating (Ie: this is what we want to do!)
- Does not provide the unitID to the function (only cmdID, cmdParams, cmdOpts)
- is UNSYNCED

AllowCommand:
- Happens AFTER network transmission
- Allows coders to drop commands from units
- Does provide useful information that would allow limiting queue size
- is SYNCED

What is happening is that we have to transmit huge amounts of data over the network (1000's of commands). This transmission is what generates the "lag" you see. This makes AllowCommand ineffectual (which is what you're suggesting). We need CommandNotify, but we can't get enough information. Now we could do some hacky behavior, and get the selection under the assumption that commands are human issued, but this breaks things (namely commands can also be internally generated. see: unitAI).

Unfortunately, since this is unsynced malicious actors can and will bypass the protection (see editing game files). While this would caused mod checksum mismatch if done in gadgets-unsynced, it would not stop someone from breaking games unlike if it was synced (which would create desync for that one player).

Note also that every time we check something it generates a little bit of 'lag', so checking huge queues like this in AllowCommand would just make the problem way worse because not only do you not prevent the massive flood of packets, now you're having to check every command on top of that.

Note as well that once the large queue is done transmitting, it no longer has a sizable impact outside of cluttering the view-all-commands view and creating fps drops there (ie: not really a big problem).

TL;DR: this is an 'engine needs to do this' problem.