Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

[Thunderbrd]

In the Asserts that keeps coming up from each debug effort there is 1 that keeps referencing a Size Matters condition; CvUnit.cpp, Line 20048, Expression: getCargo()==aUnits.size(). I am not playing with Any SM Options on any of the 4 games I have going. This is the fix for SO's complaint about the War Cats. " [*]Corrects the merging/splitting rule rewrite for SM Uncut" SVN 10339

The assert is common and will come up regardless if you're using the option or not - probably because you aren't in this case since I programmed it with a little less comprehension of asserts to begin with. There are some issues with that but it shouldn't be having anything to do with your game and that adjustment made at that time wouldn't either. There's no way there would've been any bleedover in that since all that was being done there was adjusting filters to the rules on when a unit can and cannot merge or split while in such a game.

It's an interesting collection of data that I'll have to look at that you bring up though.

EDIT: Also, the condition you are talking about in that assert is not referring to size having anything to do with size matters. It is a check that is there to ensure that the expected number of units loaded is equal to the number of units actually reported as being loaded on a transport. There's been a problem with this for a while and may very well relate to bad gamestate issues with units. Some work does need done there to figure out how this happens.

EDIT EDIT: Just for the sake of knowledge sharing, aUnits.size() is a request for the value that equals the size, # of entries, of a vector. The vector, in this case, is aUnits. .size is a very generic programming statement for requesting the entry count in that vector.

 

[JosEPh_II]

While looking at the files thru SF's comparison tool I noticed that the changes you made to SM Uncut (line 42,xxx) were not made to SM (line 20042 thru 200150). Perhaps that is nothing, but perhaps it is. Especially if there is a syntax error Like an extra or missing { or something of that nature? An extra whitespace? I don't really know which because I'm not familiar with these.

But this is just an uneducated observation and probably carries no salt.

 

[Thunderbrd]

While looking at the files thru SF's comparison tool I noticed that the changes you made to SM Uncut (line 42,xxx) were not made to SM (line 20042 thru 200150). Perhaps that is nothing, but perhaps it is. Especially if there is a syntax error Like an extra or missing { or something of that nature? An extra whitespace? I don't really know which because I'm not familiar with these.

But this is just an uneducated observation and probably carries no salt.

The point was to make the change to SM Uncut but NOT to SM. It was allowing a rule change that SO would prefer but I strongly feel breaks strategic game balance and allows the use of only a few unit choices and to render many others unnecessary. Since I wanted him to have what he wants but to not have that ruin the core SM game, I did what I usually do in these cases and did it for Uncut only, which is basically my modmod of SM for StrategyOnly only.

Missing { will show up in the compile as a host of errors very quickly and whitespace doesn't mean hardly anything in C++ (python is actually a bigger PITA than C++ in this regard.)

There was a change I made a while back to correct some problems with Barbs being able to fight Ruffian units still. THAT had the potential for some slowdown, particularly during wars - of course it represents some enforcement of rules that were being broken so that sucks but I MIGHT be able to simplify the fix a bit somehow and look for redundancies it might have made unnecessarily. Any chance you can see if this took place before or after the issues you're seeing?

 

[JosEPh_II]

Any chance you can see if this took place before or after the issues you're seeing?

I think that was made right before I added the 1st set of Civic changes SVN 10322. I will have to look thru the SVN logs again to pinpoint that change. But I think it was right before my 1st Civics commit.

By going back to SVN 10322 and the saves of that time frame in which 3 or 4 games were already started. I can be looking for that but none of my games are using any Combat Mod or SM options when they were started. Most are using the Vanilla BtS Combat Option. Plus I have no other older save games that I have kept that were started back in November or earlier.

And going back to 10322 and the saves of that time I am losing a considerable amount of accrued turns in each game.

Note: Even trying to do a Re-Calc (when the pop up appears) on the save game that I submitted from this Long GS game, now will not finish after doing the 10350 debug KaTioN asked. It too hangs and does not finish. On both the turn submitted 1318BC and the turn after the Debug advances to the next turn 1307BC. On the last debug effort which I started at a bit after high noon after the 3rd assert came up the game just sat there. So at 12:28pm I went over to the couch and laid down. When I woke up at 1:35pm my monitor had shut down (set at turning off after 1 hour) I restarted the monitor and saw that now new assert had popped up. I did a quick chore and when I came back the 4th assert had finally popped up. After that the next 3 asserts came relatively fast. (and is getting 7 asserts every time before the turn advances normal?) I played the turn until the city build queues were done and only unit actions were needed. Then I saved and exited. I then switched the .dlls back to normal positions and restarted that turn. When I did the Re-Calc came up and I clicked yes/ok. After another 15 minute wait, in which the window for the game went opaque and the cursor was a spinning circle of Window's blue, I killed it.

 

[Thunderbrd]

I can be looking for that but none of my games are using any Combat Mod or SM options when they were started. Most are using the Vanilla BtS Combat Option.

Should be rather irrelevant.

I think that was made right before I added the 1st set of Civic changes SVN 10322. I will have to look thru the SVN logs again to pinpoint that change. But I think it was right before my 1st Civics commit.

By going back to SVN 10322 and the saves of that time frame in which 3 or 4 games were already started.

Ok, well that then rules out one theory I have at the moment. I'm glad, tbh, because that one would really suck to try to fix. I'll have to further review but looking at the code changes in all of Kations, they seemed to be incapable of creating a slowdown. What COULD be capable would be a change of compiler. I added a newly compiled dll last night and you're saying that's not showing any improvement either then?

and is getting 7 asserts every time before the turn advances normal?

Absolutely.

A recalc during debug is never advised - I've wasted many hours of my life I'll never get back doing that. I only recalc with the normal dll. You're saying you can't get that to work on the normal huh? Definitely worth looking into further here. I'll see what I can figure out.

 

[Thunderbrd]

I think I've figured out the problem. I should write out a quick 'how to debug an infinite loop or super delay' thread. There are some tricks one can employ.

The process gets hung up on a particular unit figuring out its unitAI. Pausing upon discovering this, I find that the code is spending a LOT of time on trying to order up a sufficient defense force for a threatened city and doing it through this unit making the panic call. Each unit found to answer this call (which takes a bit of a time consuming search) was taking off about 350 pts of some demand of 250000. So what I think happened is that Nation A attacked Nation B and City B-1 in the path of the attack stack realizes it needs some hundreds of troops to defend itself and started going through the patient process of ordering up each and every one of them from the surrounding region and then from the cities that would build such units. I added a sanity check to limit how much strength could be requested in one such request blast (based on the strength of the best units being found so that it will adjust the volume of this sanity check limitation based on the kind of numeric strength values of units in this era). That may work but it might end up just widening the loop further. I'm testing that now but it's looking good. For the AI to try to assume that it can get all the help it should need to hold a city in this manner is... not strategically wise anyhow. I don't disagree that it should look for slackers that aren't helping elsewhere that much to come to the call but part of the planned AI overhaul is to eventually teach it to build a dedicated major defense stack and try to get THAT to respond during a time of need like this

Part of why it might be taking more time here on latest assets and not as much on earlier assets is due to the change in building costs - this could be a difference in calculatory behavior due to a city being finished with its builds and thus more available for this, or perhaps the invading force is larger because buildings were cheaper and gave the invader greater opportunity to swell his forces before attacking.

Anyhow, this doesn't look to be based on something new but a lurking mega delay potential that's been with us for a while. We've had reports like this before, where soon as a war breaks out there are super long turns. We've found that stack evaluations vs other stacks can bring on super long turns BUT I've long thought there was something else we haven't found yet. I think we found it this time. We'll see for sure as this turn continues to process but I just managed to get past the long pause I'm talking about already so this might have worked.

Looks like another unit type later also hits an infinite loop (or would have been if it didn't hit the pass limit that was installed to help detect and debug these issues.) This is another problem that needs to be discovered and corrected that will help with the delay experienced here. That said I won't have time to address it right away and it's the sort of thing that can wait and become the next debug project this week. There's a limit to the amount of delay these problems can create now but they should be debugged as soon as possible. This type is common to take place in the background and you'd never know it but it means there's a big problem in a unitAI programming.

OK, that's it, turn processed so I'm gonna compile and run the finalrelease dll and see if it feels like a fairly normal turn otherwise. If it's 'good' then I'll commit the new dll immediately.

 

[JosEPh_II]

Update: Using SVN 10322 I have been able to advance the Long game 4 turns. The turn times are running at 4min and 45 to 50 secs. After the 3rd completed turn, after I had saved it, I did a Re-Calc. The Re-Calc took 7min and 45 secs. I then took another turn and saved.
Tomorrow I will try the latest SVN. If it fails, then I will go back to 10322 and add all the commits up to the next .dll/source folder changes to it. That should be up to and thru SVN 10329 iirc.

If the latest SVN does work then I will continue with it as far as it will let me.

 

[JosEPh_II]

OK, that's it, turn processed so I'm gonna compile and run the finalrelease dll and see if it feels like a fairly normal turn otherwise. If it's 'good' then I'll commit the new dll immediately.

Good news! Thanks for looking into this.

 

[Thunderbrd]

Good news! Thanks for looking into this.

Turn time was about 3 min on my new system but I wasn't tracking to the second to come up with that. Didn't seem too bad but understandably delayed for the conflicts taking place. I'm hoping it's a huge improvement at least and I think I can get it better still, as noted.

 

[JosEPh_II]

Updated and have been using SVN 10358. Turn times are at the 4 minute 5 sec mark (+/- 5 secs). Re-Calc took 8 min 4 sec.. Even played 2 turns in a row without manually saving as a test and it has passed so far.

Pre SVN 10358 turn times were in the 4 min 45 sec (+/- 5 sec) range.

Long Game is playable again.

 

[Thunderbrd]

Updated and have been using SVN 10358. Turn times are at the 4 minute 5 sec mark (+/- 5 secs). Re-Calc took 8 min 4 sec.. Even played 2 turns in a row without manually saving as a test and it has passed so far.

Pre SVN 10358 turn times were in the 4 min 45 sec (+/- 5 sec) range.

Long Game is playable again.

I'm super happy to hear that! Again, I feel I can catch another noteworthy delay and speed it up by a bit more so I'll work on that later tonight.

 

[Thunderbrd]

I found the other problem and it was a fairly real issue in terms of game rules. Some may have noticed some strange behavior with the movement costs of razing. I goofed a while back, though I'm thinking there was a problem in the mathematical model I was trying to go off of in the first place. I think it's better now but be looking for some real weirdness with raze movement charges. The unitAI was thinking it could raze and it wasn't until it got deep into the razing function that it would be unable to but then it would leave thinking it had but still had movement left to work with and then find that it should be able to raze where it was and then get into trying to do it and it would infinitely repeat this process until caught by the loop limit.

Should be better now.

 

[JosEPh_II]

This sounds interesting.

EDIT: Turn times for EoT have increased from 4+ minutes to almost 6 min (5min 45 secs).

 

[Thunderbrd]

This sounds interesting.

EDIT: Turn times for EoT have increased from 4+ minutes to almost 6 min (5min 45 secs).

Would not be because of the changes I made of course. You may be encountering other issues to address perhaps. In this game you have going there's a lot going on.

 

[Yudishtira]

EDIT: Also, the condition you are talking about in that assert is not referring to size having anything to do with size matters. It is a check that is there to ensure that the expected number of units loaded is equal to the number of units actually reported as being loaded on a transport. There's been a problem with this for a while and may very well relate to bad gamestate issues with units. Some work does need done there to figure out how this happens.

Sorry if this is not what you're talking about, but when you buy a transport that had units on board, its cargo capacity doesn't reset, although obviously the units on board are removed (and there may be problems with this removal also - I don't know). Similarly if you buy a unit that had been on a transport, it doesn't show up in your unit list. You have to go through the unit list in the capital using . or ,: only then can you find them, and when you do, they will have a button to disembark. When you press that button, they go back to showing up as normal.

 

[Thunderbrd]

Sorry if this is not what you're talking about, but when you buy a transport that had units on board, its cargo capacity doesn't reset, although obviously the units on board are removed (and there may be problems with this removal also - I don't know). Similarly if you buy a unit that had been on a transport, it doesn't show up in your unit list. You have to go through the unit list in the capital using . or ,: only then can you find them, and when you do, they will have a button to disembark. When you press that button, they go back to showing up as normal.

That would definitely be one potential source of the problem but I THINK it's an issue that manifests as a problem without this kind of unit trade - still I think that because I never trade units but the AI might be doing that with other AI and that might have a lot to do with why it's a common issue. I suspect the problem comes from a number of sources but thank you for finding one of them. Unfortunately I think that unit trade stuff is all handled in python so I'll have to try and track that down and *shudder* solve it there. Ugh. Truth is, there could be a lot of reasons for this lurking in python that I wasn't aware of.

 

[Toffer90]

The ones in my game were: _ELASHMUNEIN (in the text 'El' is a separate word or hyphenated), _HIERACONPOLIS, _ANTIUM, _CALCUTTA, _STPETERSBURG, _JAUNPUR, _MACHU, _YUECHI (two words or hyphenated - personally I like 'Yue-chi'), _ESTRUSCAN (this is 'Etruscan' mispelled of course), _BOMBAY, _MADRAS, _TIWANAKU, _CORIHUAYACHINA (it was 'Corihuayrachina' in the text - I don't know which is right), _VILCAS, _VILCABAMBA, and _VITCOS

These will be reintroduced in the svn today. Anyone else have a list like this of city names that are currently broken in old saves?

 

[Yudishtira]

These will be reintroduced in the svn today. Anyone else have a list like this of city names that are currently broken in old saves?

Thanks. I found one more later which was _GHUZZ

 

[Thunderbrd]

From Discord:

YO
So here's the issue
Turkish modern infantry is horseman
how to fix?
it's really breaking my immersion

Can someone maybe help with this bug?

 

[raxo2222]

From Discord:

Can someone maybe help with this bug?

There is bug with unit artstyles.
Does he play with single unit graphics?