So, a minor flaw of CC is that its event queue is limited to only 256 events. This normally is not an issue whatsoever, until you start working with command computers.

You can queue a ton of commands at once, but the commands will quickly overrun the event queue when you try to do so. This will potentially cause issues if you're using parallel (or a similar multitasking system, or even just queuing 256 commands then sleeping to the next tick to run more) to wait for something else to occur.

As an example, I was at one point working on a chunk generator. The issue there was that there are thousands or more commands that need to be ran to generate a single chunk of blocks, and you have to limit yourself a lot otherwise you risk potentially fully stalling your program. Since I needed to wait until the next tick to queue more commands, if I queued too many commands in one tick, the sleep timer I had waiting for the next tick would get discarded.

What I am then proposing, is a responseless version of commands, for when you don't particularly care if the command succeeds or not. You would call commands.responselessAsync("setblock bla bla bla") (or whatever the method would be named), and it would simply run the command in async without returning a task_complete event on the next tick.

This would allow for many more commands being ran per tick without having to worry about over-running the event queue. You could even run some commands through the responseless system and others through just execAsync in order to be able to get results of some commands while ignoring others.

Alternatively, a larger event queue size for command computers to account for more events being sent would be good as well.

You could batch multiple task_complete events into task_complete_batch events.