Single Player bugs and crashes v36 plus (SVN) - After the 24th of October 2015

[JosEPh_II]

Indeed it does. I have not had the problem myself but have not switched between them recently. I will do a little bit of investigation later.

And the CTD only occurs in the City Screen when adjusting Specialists and Involved the Doctor specialist. Clicked - button on engineer and then clicked +button on Doctor.

JosEPh

 

[Thunderbrd]

Maybe we should bring back old Siege system and rams should be used like Catapults and Trebuchets? Seems that work in BTS and should work in C2C.

If we dont know how to do fix then why we cant bring back BTS siege system?
I dont think that players will be sad if they need to use Rams as catapults or trebuchets. It's only a game and some simplifications are normal. And AI know (more or less) how to use catapults

The problem exists regardless of the manner in which they attack. The changes made that introduced these problems go far back to Koshling's work on the AI and while it may seem like it took place around the time that rams were adjusted, this is due to the fact that adjustments to get the AI to build more than one siege unit at all (which was a major initial flaw in Koshling's unfinished AI work there) revealed underlying problems.

The FIX will be a few months of solid AI work. No quick fixes can really help here. The problem is the whole manner in which the AI works its stacks now. If Koshling had finished what he'd started it would probably be much better and he has, himself, advised that Siege units now be handled as a separate AI rather than a city attack AI (which ultimately is the source of the problem.)

Truly sorting this out is going to require overhaul level work on the most complex programming in the dll. Forgive me if I'm addressing other AI problems first ... one reason for holding off on that is due to working into such massive AI adjustments by focusing on simpler cases first. This will give me the opportunity to build the 'building blocks' of an improved system that can then make the needed overhaul MUCH easier to implement.

Stack limits is another of those "seems like a good idea" things that were added but no ai was written to support so it only confuses the ai. It is quite possible that the ai has decided to build an attack stack much larger than the limit you have set. It then only gets to build the ram part of the stack but finds it can't add any more units to the stack so tries to make another! The AI has no idea about using multiple stacks to do something so doesn't consider those it has already built.

You are absolutely correct. Those playing with stack limits are most likely causing massive (and I mean MASSIVE) overbuilding of units. Reason:

The way it currently works is this:

1) The initial seed unit for an attack stack is built.

2) When it is, a random number (that ranges in the thousands) is given to this stack seed unit (it's birthmark.)

3) How many units are called for by the stack to feel 'ready for attack' is determined as a random percentage of that birthmark.

4) This means that, from birth, the stack's destined 'target' number of units is defined.

5) Every round the unit that is seeding the stack is called to take its turn it evaluates its stack size and composition and places orders through the contract brokerage system for more units.

6) If the ordered units cannot join the stack that ordered them, the stack will NEVER be considered READY for any use beyond some limited reactionary commands it may make before deciding to wait for the ordered units to arrive.

In short, stack limits are paralyzing the stack from ever doing anything and causing an infinite cycle of round after round ordering.

To make matters worse, when the units that cannot join the stack discover they cannot move to the stack to do so, they disengage from the command to get to that tile to join the stack and start being considered a whole new city attack stack seed, AND START ORDERING UP A NEW STACK! It's POSSIBLE for the stack readiness size to vary due to the leading unit's birthmark being the defining factor in how powerful the stack should be, and therefore it's possible for some stacks to form that actually do something within the limits of a tile count limitation. But the smaller you set the limit, the more you are inspiring the AI to grow an infinite tree of never to be used city attackers.

I have to wonder if this is really the ultimate problem with many of the games reporting such a big flaw here differentiating from the games that never do seem to struggle with it.

Perhaps from this explanation alone you can begin to see the depth to which the system must be altered and redesigned to truly address the numerous problems that exist here. I've attempted limited fix tweaks but without diving in and basically rewriting much of the stack formation AI entirely, this is just going to be a major mess for a bit.

CTD.

Open save enter Minneapolis city screen. Deselected engineer, then select Great Doctor, immediate CTD, repeatable.

This game was started with 9070 build updated to 9074 this morning. This game is also using CIVPLAYER8's new Civic set Modmod that DH made Modular (zzNewCivics) and was placed in My_Mods Folder.

Save and mini below.
EDIT: After posting realized that I had Not put the new Civic set in after Updating to 9074 this morning! Went back and put zzNewCivics back into My_Mods folder and No CTD now.

Does make you wonder why the Mod would CTD by reverting Back to the original Civics set though.

JosEPh

I can take a look at the mini at least. Could be interesting to see what 'kind' of problem it was. Might not be quite as related to the obvious likely causes as may be assumed without taking a look.

EDIT: The crash is taking place in the exe so is suggestive that something reporting to the exe fouled up core level processing. This could mean it was a graphics issue. Could also mean there was a mathematical flaw or inconsistency it didn't expect due to changing assets - SOMETIMES this can happen when backing out of a change.

 

[Harrier]

The problem exists regardless of the manner in which they attack.

You are absolutely correct. Those playing with stack limits are most likely causing massive (and I mean MASSIVE) overbuilding of units.
The way it currently works is this:

In short, stack limits are paralyzing the stack from ever doing anything and causing an infinite cycle of round after round ordering.

Is this built into the part of the orogram you do not have access to? I guess it must be.

If not, what is the problem? Do a stack check before trying to build a new unit.

Just a guess as I know nothing about the base game.

 

[Thunderbrd]

Is this built into the part of the orogram you do not have access to? I guess it must be.

If not, what is the problem? Do a stack check before trying to build a new unit.

Just a guess as I know nothing about the base game.

No... it's not the issue. The issue is the tremendous complexity of a structure that is so flawed it needs dramatic redesign rather than small tweaks. It's not insurmountable... just something we need to be very patient with because to do it right will mean also reviewing and redefining and defining new UnitAI types entirely. To do THIS right will mean we balance out units in the process so that the AI is built to work with units and all the roles they can fill in a highly effective manner.

In short, the whole of the strategic AI in the game basically needs to be rewritten from go. Many small modules within the big picture can remain intact but even these need lots of review because they may have severe flaws of their own.

 

[Dancing Hoskuld]

Is this built into the part of the orogram you do not have access to? I guess it must be.

If not, what is the problem? Do a stack check before trying to build a new unit.

Just a guess as I know nothing about the base game.

The stack says "I need 100 units to be ready. I have 50 so gimme more." The city says "I'll build you some!." Builds them and sends them to the stack. The unit gets next to the stack and tries to join it but the plot says "I am full! Go away.".

The ai needs to be added to the stack so it knows that there is a limit on how many units there can be on the plot. Trivial! Then the real problem occurs. The stack still thinks it needs 100 units to be ready but can't ever get more than 50! Therefore it does nothing, it is not ready. Meanwhile the nation says "I need an attack stack and none of those I have are ready so build a new one!".

What is needed is ai so that two or more stacks can work together and that is a whole factor of difficulty and complexity to be added. Mind you the same stuff is needed for the ai to use Surround and Destroy as well.

 

[Thunderbrd]

The stack says "I need 100 units to be ready. I have 50 so gimme more." The city says "I'll build you some!." Builds them and sends them to the stack. The unit gets next to the stack and tries to join it but the plot says "I am full! Go away.".

The ai needs to be added to the stack so it knows that there is a limit on how many units there can be on the plot. Trivial! Then the real problem occurs. The stack still thinks it needs 100 units to be ready but can't ever get more than 50! Therefore it does nothing, it is not ready. Meanwhile the nation says "I need an attack stack and none of those I have are ready so build a new one!".

What is needed is ai so that two or more stacks can work together and that is a whole factor of difficulty and complexity to be added. Mind you the same stuff is needed for the ai to use Surround and Destroy as well.

EXACTLY! You could also put the limit of a stack as the maximum size the attack stack will ever think it should be before mobilizing and that could be a quick fix for stack limits to an extent but there's likely to still be major problems then with composition and effectiveness of this limited size stack to take a position with the same limit. A 50 unit attack stack probably couldn't take out a 50 limit defense filled to the brim in a city. So there would be other issues to address there again. Which points back to overall unit balancing.

Lots of worms in that can and I'm taking my time to consider the full plan of 'attack' to address it properly.

 

[Sparth]

The problem exists regardless of the manner in which they attack. The changes made that introduced these problems go far back to Koshling's work on the AI and while it may seem like it took place around the time that rams were adjusted, this is due to the fact that adjustments to get the AI to build more than one siege unit at all (which was a major initial flaw in Koshling's unfinished AI work there) revealed underlying problems.

Why we can't remove these changes and bring back siege engines AI from BTS? This can't be hard.

 

[Thunderbrd]

Why we can't remove these changes and bring back siege engines AI from BTS? This can't be hard.

Far too much incompatibility now between original coding and current.

 

[strategyonly]

What is auto pirate? Is this naval??

 

[JosEPh_II]

<snip>
In short, stack limits are paralyzing the stack from ever doing anything and causing an infinite cycle of round after round ordering.

To make matters worse, when the units that cannot join the stack discover they cannot move to the stack to do so, they disengage from the command to get to that tile to join the stack and start being considered a whole new city attack stack seed, AND START ORDERING UP A NEW STACK! It's POSSIBLE for the stack readiness size to vary due to the leading unit's birthmark being the defining factor in how powerful the stack should be, and therefore it's possible for some stacks to form that actually do something within the limits of a tile count limitation. But the smaller you set the limit, the more you are inspiring the AI to grow an infinite tree of never to be used city attackers.

I have to wonder if this is really the ultimate problem with many of the games reporting such a big flaw here differentiating from the games that never do seem to struggle with it.

The part I have high lighted in Red I find to be the exact Opposite of what you have stated in actual game play. I have save games to illustrate.

By reducing the Stack limit down to 20 (from previously using 40 and 50 before) coupled with the recent changes to Rams strength plus your code tweak you did, there are in fact (with a 20 Stack limit) Less stacks surrounding the AI city.

And there seems to be a few more Regular fighting units appearing. In fact in my current game, the neighboring AI that Dow'ed me, his Capital (and only city) has had stacks of 20 that had up to 8 Llama riders. Of course the other 12 units of this 20 stack was Battering rams. But sadly there have also been stacks with 12 Rams and 8 healers, or 14-18 Rams and the rest archers. Although just getting a Stack with more than 2 real fighting units in it to me is a Big step forward.

No I have to say that upping the Stack limit produces the opposite of what you say is going on. God only knows what it would be like to go back to the default Stack Limit or the 100 units per tile.

Now all this has occurred in the late Preh and Ancient Era. And the current status of what I'm saying can be seen in the savegame I provided.

One other area that is now different and I don't like much (imagine that! ) is that even with IDW On in BUG the rate at which tiles flip from culture is now so slow as to be as bad or maybe worse than using Realistic Culture Spread (you guys didn't make that a default Option now did you?)

And if the AI has built a palisade and you take that palisade, it does not change to your culture Until you bring in a 2nd or 3rd unit. This was not the case just 20-30 versions ago. Also if you have troops stationed on an enemy tile it (so far after almost 100 turns on an Epic game) the % owner ship rarely moves. Even having a growing city right next to the other culture Makes no change to the changing of the %s of cultural ownership. And these tiles are 5 tiles from the Enemy AI's city. Something smells fishy in Denmark over this Cultural reluctance/resistance to ownership change.

JosEPh

 

[Thunderbrd]

What is auto pirate? Is this naval??

It's a naval automation setting.

The part I have high lighted in Red I find to be the exact Opposite of what you have stated in actual game play. I have save games to illustrate.

By reducing the Stack limit down to 20 (from previously using 40 and 50 before) coupled with the recent changes to Rams strength plus your code tweak you did, there are in fact (with a 20 Stack limit) Less stacks surrounding the AI city.

And there seems to be a few more Regular fighting units appearing. In fact in my current game, the neighboring AI that Dow'ed me, his Capital (and only city) has had stacks of 20 that had up to 8 Llama riders. Of course the other 12 units of this 20 stack was Battering rams. But sadly there have also been stacks with 12 Rams and 8 healers, or 14-18 Rams and the rest archers. Although just getting a Stack with more than 2 real fighting units in it to me is a Big step forward.

No I have to say that upping the Stack limit produces the opposite of what you say is going on. God only knows what it would be like to go back to the default Stack Limit or the 100 units per tile.

I'd wager if you tried it you'd see more concisely designed stacks. If the problem with volume isn't showing to be true, (which is largely a theoretical discussion at this point) then the odd stack compositions you're mentioning are still likely a result of limits.

One other area that is now different and I don't like much (imagine that! ) is that even with IDW On in BUG the rate at which tiles flip from culture is now so slow as to be as bad or maybe worse than using Realistic Culture Spread (you guys didn't make that a default Option now did you?)

And if the AI has built a palisade and you take that palisade, it does not change to your culture Until you bring in a 2nd or 3rd unit. This was not the case just 20-30 versions ago. Also if you have troops stationed on an enemy tile it (so far after almost 100 turns on an Epic game) the % owner ship rarely moves. Even having a growing city right next to the other culture Makes no change to the changing of the %s of cultural ownership. And these tiles are 5 tiles from the Enemy AI's city. Something smells fishy in Denmark over this Cultural reluctance/resistance to ownership change.

JosEPh

No... shouldn't be a default option at this point. RCS was slightly adjusted but shouldn't affect the main since the adjustments only took place where RCS factors are determined and being called on to tweak how the core functions work. Should be completely isolated from the main function if RCS isn't on.

As for the culture, when we have such a glut of culture production as we do now, it can easily drown out the ability to get tile flipping to take place. This is a process of numeric tug of war and a newer city has a hard time keeping up with the established cultural values on a tile from a more entrenched city, exacerbated here over Vanilla due to the massive amount of culture bonuses that can be obtained. AKA, it's just going to be harder to get tiles to flip and take a lot more culture to do it.

As for the Palisade, what was the first unit that took it? HN units do not attempt to take political possession of forts now. This keeps their Hidden Nationality status in tact.

 

[JosEPh_II]

Horseman and then another horseman to get it to change ownership.

I'd wager if you tried it you'd see more concisely designed stacks. If the problem with volume isn't showing to be true, (which is largely a theoretical discussion at this point) then the odd stack compositions you're mentioning are still likely a result of limits.

I have 3 game going that says you are wrong from practical play experience. One that was started before your code tweaks and my unit str changes, 40 Stack Limit. 2 started after those changes; 1 with 40 unit stack limit and the newest with 20 SL. The lower SL shows the better composition And less Stacks around the city. The 1st game was/is a SL hell! And mirrors what all those posters have complained about with Driefels being the latest.

JosEPh

 

[Thunderbrd]

Horseman and then another horseman to get it to change ownership.



I have 3 game going that says you are wrong from practical play experience. One that was started before your code tweaks and my unit str changes, 40 Stack Limit. 2 started after those changes; 1 with 40 unit stack limit and the newest with 20 SL. The lower SL shows the better composition And less Stacks around the city. The 1st game was/is a SL hell! And mirrors what all those posters have complained about with Driefels being the latest.

JosEPh

Interesting. I won't discount this feedback. I'm just not sure how its working out this way. These areas of the code are so complex one must basically theorize about a lot of what takes place until the deepest of study can take place. I know that the game does process as I explained but there could be some control factors I haven't seen. On that lower stack limit game, were the stacks mobilizing to attack or were they generally tending to stay lurking 'in wait'?

 

[strategyonly]

This is BACK again??

[112112.125] info type 'COLOR_HIGHLIGHT' not found, Current XML file is: xml\GameInfo\CIV4EspionageMissionInfo.xml

 

[Thunderbrd]

This is BACK again??

[112112.125] info type 'COLOR_HIGHLIGHT' not found, Current XML file is: xml\GameInfo\CIV4EspionageMissionInfo.xml

If I'm correct on this, you're only seeing this when running a debug dll right? Not that it doesn't warrant some further investigation - the really odd thing about this was that COLOR_HIGHLIGHT wasn't even found in that file when I searched it. So while I was able to find such a reference in the dll, if this is continuing, I'm a little confused as to how given that that file shows no sign of COLOR_HIGHLIGHT in it at all.

 

[Dancing Hoskuld]

That file may be the last one searched after everything else. It is searching for COLOR_HIGHLIGHT, has tried everywhere but the message reports the last file it checked. There are a couple of error messages like that.

 

[Thunderbrd]

That file may be the last one searched after everything else. It is searching for COLOR_HIGHLIGHT, has tried everywhere but the message reports the last file it checked. There are a couple of error messages like that.

Interesting... Maybe another spot where that was put into the code (my bad!) Problem is finding it! All the proper ones just add _TEXT after COLOR_HIGHLIGHT. I'm not sure how to easily find the flaw. Will take a patient search I suppose.

 

[Dancing Hoskuld]

The other problem is that it may not even be occurring in our code it could be in stuff we are inheriting fro BtS or Civ IV vanilla

 

[strategyonly]

If I'm correct on this, you're only seeing this when running a debug dll right?

Nope, never use the debug dll, sorry . .

 

[Thunderbrd]

The other problem is that it may not even be occurring in our code it could be in stuff we are inheriting fro BtS or Civ IV vanilla

Generally speaking if we are inheriting it from those sources, they would have the assets to support it. If a call is made to a text or color or xml entry of any kind, it will look at the mod first and if its not found in the mod it will look at BtS assets. If not found there it will look in Warlords (if you have it) assets. If not found there it will look in Vanilla assets. I've never found any inconsistencies in original calls where they didn't have the support for those calls.

I found one goof of my own with this same issue and must believe there is another.