Actually scratch that, Modern Engineering is better.

I hear you corpsey. Didn't know that the limit is officially a bug, though.


I tried asking about this; how would killing an enemy with gibs be detected though? As far as I know, gibs don't retain any memory of where they came from. Same goes with every "kill x with y".

It's a limitation of the engine. Every MOID has to have a unique ID and there are only 255 of them to go around, so once you reach that things start to be confused in the physics engine and explode.

Oh, right. The limitation itself is not a bug. Are the consequences of reaching the cap a bug though?

Ehhhhh, more of a defect. Solving it requires a bit of an overhaul.

Technically not. It's a conflict between MOID ids. The physics engine is keeping track of both MOIDs and because they're in two different places attempts to push them back together (the logic being that they're supposed to be the same thing, so in effect it's one object that's vibrating wildly between two positions), leading to instagibbings.
To fix it, Dan could raise the MOID cap (not sure how difficult that'd be), disallow further MOIDs from being tracked (which would be weird if you suddenly couldn't order things or things started disappearing), or potentially break the physics engine by trying to work around the instagib issue.

I could be wrong on all accounts as I haven't investigated the details of the problem myself but that summary is what I've picked up over the years.

Other issues involve really jack ass tracking of collisions between MOPixels, and MOSprites when the physics engine is screwed.
You can in fact get injured from a hundred meters away, and you are left with bullet wounds floating in the middle of the air.

The problem isn't what happens when the MOID limit is exceeded, but that the player can so easily exceed the MOID limit.

Most activities have built in functions that stop the AI from spawning new actors when a certain MOID count is reached (the value can be found in constants.lua, 210 is the base I think), so it's only when the player orders enough additional units (or a really extreme spam of other MOs) that the limit is exceeded and the weirdness happens.

The MOID limit is essentially a game rule. Raising the number is just gonna move the moment at which the weirdness happens. I also have serious doubt about how many more MOs CC can actually handle, especially anything with AI that also needs to be run for each actor individually. So since we're stuck with the MOID limit as a gamerule, it needs to be enforced on the player as well.

Currently it is a gamerule that a new player doesn't know about, never gets any information about, and which can be freely broken, which can result in essentially breaking the game. This is in my opinion pretty bad game design and it needs to be fixed.

The fix doesn't need to be hard, or require any engine work or anything like that. My simple lua suggestion: Create a new global variable in constants.lua, something like rte.PlayerCanBreakLimit, default it to 0, then alter the craft AI, so that if the craft+its ACrab, Ahuman or actor cargo would exceed the MOID limit, it instantly gets refunded and displays a message, something like: "Overpopulation detected: Tradestar refuses to deliver cargo to overpopulated areas"

You get the best of both worlds: new players can't inadvertently break their games and they get some information as to why they can't do something, while veteran players can change one 0 to a 1 to get the full weirdness.

Again, there will always be some kind of limit as to how much stuff CC can handle, and the player can't just be allowed to break the game by going over that limit.

I know nothing about the underlying code, but theoretically changing an unsigned byte value to a short (or an int if you're feeling exceedingly generous) seems like it might be a pretty simple fix that would remove the problem for the vast majority of ever.
I'd be interested in seeing if that's an option from Dan's perspective, however (I'm sure the issue is much more complicated than that), and your in-Lua suggestion seems like a good way to go about it as well.

Otherwise, you can implement some unum, that allocates bits/byte dynamically.
(It works, but nothing is really optimised for it)