Unit Limit / Save the Megagame

[Hadrian_II]

The megagame (Perpetuality) might now come to a very disapointing end, as we have hit the unit limit, and now summons and spells like earth attack and ghostriders had stopped working properly.

I know that a game on a 1000 province map and 65 nations on it is a bit out of the bounary of the game, but its still a bug and it might be fixed (*pleeease*).

Dumb question to the end, why is there such a limit anyway?

[Kristoffer O]

The limit is there as it lowers hosting time. Hosting time is proportional to the unit limit IIRC. All possible unit nbrs are cycled through every turn I think. Thus games would take longer time to host regardless of the actual number of units in the game. The current limit was set *too* high. 1000 province maps were not on our maps when we set the limit.

I'll ask JK and see what he says. There is a patch around the corner anyway. I hope it will make it to christmas. It would be fitting. Unfortunately I only have a few free days left, so it might become the 2008 new year patch instead.

[vfb]

Whenever it's released, Christmas or New Years, please know that it is very much appreciated!

[Dedas]

Maybe one should be able to set the limit oneself? Longer hosting times should not be a problem for megagames.

[Agrajag]

All possible unit nbrs are cycled through every turn I think.

As a hobbyist programmer:
That sounds unlikely, why would you need to access a unit number for a unit that doesn't yet exist?
I could see how hosting times could get huge with a very high unit limit if you actually reach that limit (since then all numbers up to that limit are used and therefore must be cycled through), but I'm guessing that if you reached the limit, then a longer hosting time won't be a problem for you. (so an even bigger limit won't be a problem.)
A limit that does make sense to me is if you are reaching a point where you risk overflow.

Though obviously I don't have access to the code, so I can't be sure

[capnq]

Agrajag said:

As a hobbyist programmer:
That sounds unlikely, why would you need to access a unit number for a unit that doesn't yet exist?

I can take a guess at that.

At minimum, you have to check every unit number up to the highest one assigned so far, even if thousands of lower numbered units have already been destroyed. Renumbering the units to account for casualties would be even more time consuming than just cycling through the range.

[DrPraetorious]

You could raise the unit limit dynamically as the game went on - but an engine change like that would almost certainly introduce horrible memory bugs that would eat our computers alive, drive us into cannibalism and madness, and lead to the downfall of western civilization.

And, yes, your excellent work on the patch is greatly appreciated.

[Agrajag]

capnq said:

I can take a guess at that.

At minimum, you have to check every unit number up to the highest one assigned so far, even if thousands of lower numbered units have already been destroyed. Renumbering the units to account for casualties would be even more time consuming than just cycling through the range.

That's almost what I said - at most you have to check every unit number up to the highest one assigned so far, so there's no reason to go beyond that and reach all the way to the unit limit.
Furthermore, I don't think there could ever be any renumbering going on because IIRC the game intentionally keeps track of dead units.
But if it didn't, renumbering would actually be a piece of cake:
When unit dies:
1) Replace unit number between current one and last one.
2) "Kill" the dead unit that's now at the end.
And if renumbering is impossible due to engine constraints (for example, if a global spell remembers that it has been cast by unit #n and not the other way around), you could still reuse old numbers by merely making dead units "inactive" and whenever a new unit is created it can "steal" the dead unit's number.

[DrPraetorious]

Actually, I think the game only keeps track of dead units which are either pretenders or in the hall of fame.

So newly recruited units will already steal old unit #s - you can tell when this starts happening because newly recruited commanders will no longer appear at the bottom of the screen (I think.) I assume that what it does is start at some index value, and progress through the array until it finds enough empty spaces for the new recruits.

This actually happens quite quickly - whereupon, each turn, you cycle through all (say) 10,000 unit id#s to see which ones are currently in use. And if you raised the limit to 100,000, this would take 10 times as long each host, once the 100,000th unit had been recruited (including dead ones) which would happen pretty fast.

What you *could* do is start with a unit limit of 1,000. Keep that unit limit until the search for vacant unit #s on recruitment fails, and then double the unit limit.

But this would require memory management which I think is to be avoided, because it's generally time consuming and, frankly, there are other things I'd rather see than a fix to enable ginormous maps with autospawners to keep going past turn 100, which is a pretty specialized issue.

[Hadrian_II]

I dont think the problem is that the number of units is limited due to a loop that checks them all every turn. As a simple check if something exists is very fast, and even medicore computers could do a few millions of them per second, so this might only be a problem, if this loop is checked a gazillion times per turn.

Also to implement a static barrier to break big games when they else just would take longer seems pretty strange to me, so i suppose there is something other going on. But it might be that we just have hit 65536 (2 ^ 16) units, and now some variables begin to flow over and so causing mischief.

Also i suspect that some parts of dom3 are the same as in dom1 and just got extended with new features, and are so now looking quite hacky. (As i cant see the code this is solely based on speculation, but there where dev comments in other threads succesting such things)