Movement Rules in the dll

[JosEPh_II]

The AI does not understand stack limits at all.

-1 is the only recommended value as it is the only value the AI understands and does not cause infinite loops. (Waiting for Civs) eg the AI makes a unit in a city which can't stay in the city because of the stack limit but can't move to any other terrain because they are full or are of the wrong terrain type (sea for land units...)

If you get a Waiting for Civs infinite loop you need to set the stack limit to -1 for a few turns before you turn it back to what ever value you had it on.

I'm just going off of what koshling himself posted. And I don't remember ever having a WfoC hang that was ever found to be Max Units Per Tile caused when submitted as a CTD or Hang in the Bug thread. At least no one that made fixes of my savegames and dump file submissions ever said "don't use anything but 0 in the BUG setting for Max Units Per Tile". <shrug>

JosEPh

 

[olduser]

I don't understand why a limit to units per tile should be a valid way to fix bad an inefficient code?

My example was a extreme worst case szenario that is perfect to show how inefficient the unit movement and attaking code is. If you test it with only 10 units you might just not be able to really see what causes slowdowns but they are still there.

 

[JosEPh_II]

I don't understand why a limit to units per tile should be a valid way to fix bad an inefficient code?

My example was a extreme worst case szenario that is perfect to show how inefficient the unit movement and attaking code is. If you test it with only 10 units you might just not be able to really see what causes slowdowns but they are still there.

I agree.

I believe the original intent of Max Units per Tile (MUPT) was to restrict the AI and Player from putting more than 100 units on a tile at a time.

BUG also has a Stack setting that I confuse with MUPT. I don't understand the difference.

JosEPh

 

[Sparth]

Simple solution - reduce quantity of units build by AI or by Player. Or by increasing building cost or by increasing maintaince cost.

 

[Thunderbrd]

Why can't the AI be recoded so that it does not try to build a unit if the stack limit in a city is already reached. Or is this in the unobtainable part of the code? Just asking.

Something like:

If units in city = stacklimit
Do not select a unit
select a building/wonder etc.
else select anything.

I am assuming the dispersal code to move units out of a city works.

This is just a quick thought.

The problem is far more complicated than that. Has to do with hundreds of places in the code rather than one.

Simple solution - reduce quantity of units build by AI or by Player. Or by increasing building cost or by increasing maintaince cost.

Which is basically what I'm suggesting, just that we do it the way it really should be done by establishing the base costs along closer lines to the re-evaluated curve of unit build cost progressions that they should be following. From classical to modern the curve is way too cheap, then suddenly starts catching up to itself in transhuman.

As for costs, the naval review included a start to ramping these up more appropriately. But only for navy. Other unit chains should be evaluated once the naval corrections are made.

 

[olduser]

Simple solution - reduce quantity of units build by AI or by Player. Or by increasing building cost or by increasing maintaince cost.

I understand what you mean but that has nothing to do with the overhead caused by new movement rules.

If simply reducing the number of units is the way to fix the increased turn times caused by a new feature or bad and slow code. Then in a few years we only play on tiny maps with 5 units max per player. It might be something new in the world of C2C but if a new feature leads to very slow turns and/or higher memory usage and those issues can't be fixed then that feature should not be added. Or if it is already part of the mod it should be removed again.

 

[Yudishtira]

I understand what you mean but that has nothing to do with the overhead caused by new movement rules.

If simply reducing the number of units is the way to fix the increased turn times caused by a new feature or bad and slow code. Then in a few years we only play on tiny maps with 5 units max per player. It might be something new in the world of C2C but if a new feature leads to very slow turns and/or higher memory usage and those issues can't be fixed then that feature should not be added. Or if it is already part of the mod it should be removed again.

Why are you exaggerating so ridiculously? If you have unlimited numbers of units, then you will eventually have crazy slowdowns caused by the processing when stacks interact.

Anyway, why is this debate about removing sea tunnels, when they have been in the mod for years and did not cause this problem? At most, the debate should be about removing TB's recent changes.

Then, you hit the issue of whether the changes were more of an improvement than a liability. They were. This issue only arises in the tiny tiny tiny minority of games on massive maps that make it to modern/transhuman, and maybe only a small fraction of those! It's kind of like (I said kind of) removing functionality because someone who was trying to break the mod succeeded.

 

[Thunderbrd]

I don't think you understand. Tunnels were broken in many ways before my attempt to fix them. If you retract what I've done and accept our 'limitations' then what you have is not only a need to give up on tunnels entirely but a need to give up on a great many other goals and accept that movement rules cannot go any deeper than they were for BtS and that tunnels will never work properly. I certainly wasn't trying to break anything.

At the heart of the issue: Land units were attacking ships from tunnels and ships were attacking land units. This is because the most basic movement rules that stated: "If any of your units can see an enemy unit, then any of your units that can ever attack WILL attack that visible enemy when they go to move onto the plot it exists on." Simply trying to deepen that rule even one bit to allow the state of the enemy unit to also play a role in determining whether your unit can attack it or not is what has caused so much evaluation that it causes a slowdown.

aka, FIXING tunnels is what is causing a slowdown. Alberts is pointing out that even a small slowdown can be too much when you consider how it can extrapolate to a large effect when compiled over all the numbers of units in the game. Whether you stack them all on one plot or not is actually irrelevant. Each unit having to evaluate anything about the visible enemy unit before determining if it can attack or share a space with the enemy unit is going to create a large sum of a problem as the game goes on into larger numbers of units.

Still... I don't know why we would even consider that it may not be possible to sort out. Surely there's a WAY. There really must be somehow. This rule is simply a wretched design limitation that must be breached or the game will always feel like nursery school when we're trying to get it up to high school level 'reality resolution'. Obviously, it just needs to be determined how it can be done in a more efficient way. Another clever shortcut must be found apparently.

At the moment I'm proposing:
1) Limit units to layers of existence that have more sweeping consequences in what is and what is not visible, not on a unit by unit basis but a layer by layer basis. This way we take what can a small check per unit per round and turn it into a larger sweeping check of visibility per layer per round with new visibilities edited in and cached as they are for the game as a whole now, only tracked by layer instead of just one visible/not visible state. This should make the slowdown finite and manageable.

2) Change the need for units that can't attack to evaluate whether the other unit can attack or not by making it possible for them to move into and overlap any enemy unit. Then setup a mission to attack the same space and work out any bugs that result from trying to have both fighting units existing on the same tile - this was an important step and goal coming up anyhow. So that once you've moved your 'unable to attack' unit onto a tile with an enemy unit, you may still be attacked once the enemy gets his turn. There's a list of difficult issues this suggestion would fix. The slowdown issue is one of them because we'd be removing the need to evaluate the enemy unit data while solving that list of problems the current structure was implemented to solve.

By taking these two steps, we will then need to iron out the rest of the details that may be shifty afterwards but we will have greatly eliminated the infinite potential for slowdown and left ourselves with a slowdown that is finite, manageable, and the same regardless of the number of units in the game.

Ok, so it's a little difficult to pull off. But I think it can and should be done before we start thinking about giving up and reverting back. However, if we want to revert back before moving forward into this, I can see the point in that because the new system would want to mirror much about the old system. But even that sort of retractive surgery might be no less difficult in itself so it may be better to just build into the new from where we are.

 

[Yudishtira]

I certainly wasn't trying to break anything.

If you're replying to me, of course I know that, and wasn't accusing you, or indeed anyone.

My comment was inspired by the extreme extremeness of the scenario in Talin's game that started all this. (And I was not suggesting that Talin was trying to break the mod either.)

 

[Thunderbrd]

It's not that extreme when you consider that stack size is not the problem, it's number of units evaluating their moves that is a problem. So if we have a hope of opening up multi-maps or playing in any era where a large number of units simply exists in the game, you'll have a growingly obvious slowdown. Talin's was large enough to cause a 30 minute turn so although it may seem like an unusual case, it's still a warning that we have dangerously enabled an unlimited potential for greater delay.

I completely agree something needs to be done differently.

But I appreciate that you feel the effects are worth the delay and weren't trying to accuse me there of trying to do something that shouldn't have been done.

 

[Yudishtira]

Could Size Matters have been involved there? I'm at a loss to understand how there could suddenly be 2500 units in a stack, and suddenly be a 30-minute delay when there wasn't last turn. Does Size Matters AI ever split 100+ units at once so as to create 10 times as many as were there before?

And if so, can we stop it doing that?

 

[JosEPh_II]

Was Zappara's Underwater Cities based on tunnel code? Iirc they both existed in RoM during that time. And while Tunnel code is "intriguing" the Need for Tunnels in the game is really Not that high nor do that many players depend upon them. Tunnels when introduced many years ago was to circumvent needing enough Troop Transports and/or Airports (both Mil and Civil) to move sufficient amounts of troops. Tunnels negated much of the need (if you used them) for building and maintaining sufficient naval forces and Airports/airbases. Yes it was a "cool" ides when they were introduced. But they are actually more of a novelty than necessity for gameplay. And of course once a player starts using a design such as this they get comfortable with it and then feel it's a necessity for their play. Others who don't use it or even ocassionally use don't see the need to "fuss" over it. Spend valuable Modding time on it. Especially when there are more commonly used "features/designs" that need attention.

So is Tunnels a real priority or a perceived priority? Does it warrant a huge investment in coding for the time frame it comes into play and the number of users that get to that point that "want" to use it, in any C2C game? And in the grand scheme is this a "swallowing an elephant to eliminate a gnat" situation? it is kind of like this exaggerated scenario: do I spend my paycheck on my house, food and utilities, Or do I go gambling, boozing and womanizing?

JosEPh

 

[Thunderbrd]

Could Size Matters have been involved there? I'm at a loss to understand how there could suddenly be 2500 units in a stack, and suddenly be a 30-minute delay when there wasn't last turn. Does Size Matters AI ever split 100+ units at once so as to create 10 times as many as were there before?

And if so, can we stop it doing that?

I discussed what size matters AI flaws exist in a previous post in this thread. They are issues but I don't think it's what would cause THAT much unless there's a bigger bug than I realize.

Again, it's just # of units in the game... whether stacked or not is irrelevant.

 

[Thunderbrd]

Was Zappara's Underwater Cities based on tunnel code? Iirc they both existed in RoM during that time. And while Tunnel code is "intriguing" the Need for Tunnels in the game is really Not that high nor do that many players depend upon them. Tunnels when introduced many years ago was to circumvent needing enough Troop Transports and/or Airports (both Mil and Civil) to move sufficient amounts of troops. Tunnels negated much of the need (if you used them) for building and maintaining sufficient naval forces and Airports/airbases. Yes it was a "cool" ides when they were introduced. But they are actually more of a novelty than necessity for gameplay. And of course once a player starts using a design such as this they get comfortable with it and then feel it's a necessity for their play. Others who don't use it or even ocassionally use don't see the need to "fuss" over it. Spend valuable Modding time on it. Especially when there are more commonly used "features/designs" that need attention.

So is Tunnels a real priority or a perceived priority? Does it warrant a huge investment in coding for the time frame it comes into play and the number of users that get to that point that "want" to use it, in any C2C game? And in the grand scheme is this a "swallowing an elephant to eliminate a gnat" situation? it is kind of like this exaggerated scenario: do I spend my paycheck on my house, food and utilities, Or do I go gambling, boozing and womanizing?

JosEPh

For me, it's not about tunnels. I feel the same way about tunnels. If we didn't have tunnels, it's not the end of the world. It's about everything that was otherwise planned that we'd be losing out on if we accept the limitation that I find frustrating.

Still, I'm not personally working on any coding for a while so if Alberts wants to revert it to the way it was, as said, it could be easier to work our way into what I think would be a real solution from that basis anyhow.

 

[JosEPh_II]

Could Size Matters have been involved there? I'm at a loss to understand how there could suddenly be 2500 units in a stack, and suddenly be a 30-minute delay when there wasn't last turn. Does Size Matters AI ever split 100+ units at once so as to create 10 times as many as were there before?

And if so, can we stop it doing that?

No Talin's game was started long long ago. His units did not "suddenly " jump to 2500 in a stack" it's had those stack for sometime. He has purposefully played it to try and reach the Modern era and beyond. It was a game started with iirc 32 AI. I posted some of the observations about his game when I tried to run it. His game was started back in the v29 to v31 timeframe again iirc from what he has posted. I would sugggest that those interested go D/L his savegame that hung and just let it load on your comp. Then look at it's details. But don't try to advance it unless you have a 4th Gen i7 comp. Mine is only a 2nd gen i7 and it CTD at 17 min during EoT wait.

But you do raise some strong questions about what impact SM may have on a game that well along/developed.

Sidenote: It really is time that a Disclaimer was posted in a Main Stickied Thread that Playing C2C on Giant maps with more than 20 AI on the Slower game speeds Is Not Recommend and Not supported. Otherwise more of these type discussions, efforts on bug squashing will be spent on peripheral C2C possible games instead of more mainstream games were core play Needs to be more refined and polished, Impo.

JosEPh

 

[olduser]

Why are you exaggerating so ridiculously? If you have unlimited numbers of units, then you will eventually have crazy slowdowns caused by the processing when stacks interact.

Anyway, why is this debate about removing sea tunnels, when they have been in the mod for years and did not cause this problem? At most, the debate should be about removing TB's recent changes.

Then, you hit the issue of whether the changes were more of an improvement than a liability. They were. This issue only arises in the tiny tiny tiny minority of games on massive maps that make it to modern/transhuman, and maybe only a small fraction of those! It's kind of like (I said kind of) removing functionality because someone who was trying to break the mod succeeded.

What i posted was a worst case scenario to test for slowdowns nothing else.

Huge numbers of units in a game lead to longer turn times but the same goes for cities or players. But if they cause extreme slowdowns then there is something wrong. There where two reasons for the 50 minutes slowdown in talins game TB's movement changes and some inefficient code which was revealed by a single ~1600 unit stack. But what you don't understand is that the bad code was the bigger problem not the number of units. Because those inefficent pices of code make all turns longer even if there are less units in the game.

If you are looking for the cause of those huge numbers in that game there are many. I even noticed slowdowns caused by the unit production in AI cities. It turned out that the AI is good in creating unit production cities and producing hundreds of units in just a few turns is no problem for them. That is enabled by all the buildings giving +% to production and unit production.

 

[JosEPh_II]

alberts2 wrote: But what you don't understand is that the bad code was the bigger problem not the number of units. Because those inefficent pices of code make all turns longer even if there are less units in the game.

Every Player, Every Modder Needs to Understand this! This is Vital Information. It changes So Many discussions over Production, Units, and AI.

I wish there was a prominent place to Post this. It is that Important. But it will get lost in this every growing thread impo.

Thank you for the info alberts2.

JosEPh

 

[Rwn]

Wouldn't a simple solution be to set Sea Tunnels unchecked by default in the Bug Menu? (currently it's on by default). So only aware people would turn it on and accept the performance drain if they wish so.

 

[Arakhor]

Well, if you annotated the option to make that choice clearly apparent, then that might be a useful idea.

 

[Rwn]

Well, if you annotated the option to make that choice clearly apparent, then that might be a useful idea.

What do you mean? There's currently an option in the BUG menu named "Sea tunnels", it looks obvious enough doesn't it?