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

Status
Not open for further replies.
Cool! Just found this great free program for that. https://screencast-o-matic.com/home
I've been looking for a good excuse to set it up on my home system.

If you have a recent NVIDIA graphics card, you can use the free ShadowPlay software. It doesn't get much easier than that program to record screen happenings.

Recording screen is easy...getting the sound just right if you want to use a microphone is a bit trickier.
 
@T-brd and DH,

Just updated to 9292 And the Save game that was taking 10+ min per turn is now down to 3 min. Last 2 turns using 9292 and the turn times were 3 min 01 sec and 2 min 52 sec.

SVN 9292 did not break that save game. And it is now actually playable again for now.

JosEPh
 
SVN 9292 did not break that save game. And it is now actually playable again for now.

JosEPh

Same here, didnt break my game either, UNless it more down the road, ?? lol:confused:
 
@T-brd and DH,

Just updated to 9292 And the Save game that was taking 10+ min per turn is now down to 3 min. Last 2 turns using 9292 and the turn times were 3 min 01 sec and 2 min 52 sec.

SVN 9292 did not break that save game. And it is now actually playable again for now.

JosEPh

That's awesome to hear! I still want to take a look because 3 min still seems a little high to me and maybe it can be brought down somewhere further.

I suspect the python stuff I worked on over the weekend may have had something to do with correcting things there but it's a little unfortunate I hadn't been able to diagnose it directly before it was corrected, just to get a bit more visibility on things. Still, can't look a gift horse in the mouth. Sometimes you just work on things you know aren't right and other matters correct themselves.

Cool :D
 
SVN 9292

DH Sorry, XP still does not load with the new cultures. Dumpfile attached. I dont think it produced one initially (or I missed it), so some progress.

TB Do you still want repeatable CTDs from my Modern Era game? Currently using 9291.

I seem to be getting them every couple of turns, after updating from SVN. It's not that I want to keep playing the game. But if it throws up useful debugging info for the late game I am happy to continue. Also I can look at all the new future era stuff.

Does not take long to switch between versions.

As a side note I have never got this far in a game before. In the past I have had to stop in mid/late Industrial era. This due to the graphic card crashing and getting the Blue screen. So the error fixing is making lots of progress in this respect.
 

Attachments

SVN 9292

DH Sorry, XP still does not load with the new cultures. Dumpfile attached. I dont think it produced one initially (or I missed it), so some progress.

TB Do you still want repeatable CTDs from my Modern Era game? Currently using 9291.

I seem to be getting them every couple of turns, after updating from SVN. It's not that I want to keep playing the game. But if it throws up useful debugging info for the late game I am happy to continue. Also I can look at all the new future era stuff.

Does not take long to switch between versions.

Absolutely. These reports are still golden, yes. Minis are usually out of date by the time I can address them but saves that repeatedly crash are still good to get.
 
Just to verify tested a 9271 game and a 9291 game and all are still playable. The 9271 game is in the Med Era and the turn time was 1 min 12 sec. Several wars going on in this one too.

@T-brd,
I was hoping what you had found would help that 9265 game. And apparently it has. :goodjob::thumbsup:

On a different note:
Rev players have been complaining about not getting any Revolts when they think they should. The Revolt level is set at 1000. The next level down is 750. Perhaps the Revolution.xml in Assets/Config could have that value (750) instead of the 1000 to see if it suits them better?

JosEPh
 
9291 CTD.

Just press Enter.
 

Attachments

On a different note:
Rev players have been complaining about not getting any Revolts when they think they should. The Revolt level is set at 1000. The next level down is 750. Perhaps the Revolution.xml in Assets/Config could have that value (750) instead of the 1000 to see if it suits them better?

JosEPh
Might as well try it now that we've reachieved some balance there.

9291 CTD.

Just press Enter.
Thanks!
 
SVN 9265. This is a game I played a few weeks ago (see attached save game, just hit enter). I move my doomstack towards enemy territory and place it on a tile with 50% defense bonus. The next turn, the AI attacks me with its own combat stack, and it is a disaster for the AI. He loses almost 100 units, I lose not a single unit. Also, his support units (like battering rams) now lost their escorts, allowing me to kill another 50 or so units the next turn, again without losses on my side.

Basically the AI handed me a massive victory on a silver platter. A defeat of such a size cannot be explained by mere bad luck. So what happened?

1) Is there a miscalculation? or
2) Does the AI just walk along predetermined paths and didn't notice my stack standing in the way? Or
3) does the AI just go RAAH ME SMASH ENEMIEZ without bothering to calculate whether it is going to be a victory?

I have tested this save twice. The AI attacked both times, with the same disastrous result both times.
 

Attachments

SVN 9265. This is a game I played a few weeks ago (see attached save game, just hit enter). I move my doomstack towards enemy territory and place it on a tile with 50% defense bonus. The next turn, the AI attacks me with its own combat stack, and it is a disaster for the AI. He loses almost 100 units, I lose not a single unit. Also, his support units (like battering rams) now lost their escorts, allowing me to kill another 50 or so units the next turn, again without losses on my side.

Basically the AI handed me a massive victory on a silver platter. A defeat of such a size cannot be explained by mere bad luck. So what happened?

1) Is there a miscalculation? or
2) Does the AI just walk along predetermined paths and didn't notice my stack standing in the way? Or
3) does the AI just go RAAH ME SMASH ENEMIEZ without bothering to calculate whether it is going to be a victory?

I have tested this save twice. The AI attacked both times, with the same disastrous result both times.
There's also option 4 which is that the AI understands there's a chance it may work and the likelihood is enough to try it but when it goes forward with it, the luck is against the AI rather than for it and it would need to be quite FOR it to have worked out.

A while back, Koshling modified the odds tolerances by giving some additional willingness to attack based on the potential rewards. Are there capturable units in the stack or an important resource you control underneath the stack? These could be modifiers that might play a role.

I am quite glad to have this save though because it can certainly help.

I was surprised by the AI the other day in some personal playtesting. It astutely decided to change target cities for invasion when I managed to build up defensive buildings and units in the city they were approaching and went for a city I couldn't get as much defense into as quickly and 'wham' they had it. Sometimes they do some clever stuff so when I evaluate things like this I have to be tremendously careful not to destroy what's RIGHT about the system.
 
There's also option 4 which is that the AI understands there's a chance it may work and the likelihood is enough to try it but when it goes forward with it, the luck is against the AI rather than for it and it would need to be quite FOR it to have worked out.

Sorry, but losing 97 units to 0 units can be in no way, shape or form be attributed to "bad luck". Not even close. And the outcome was the same in three different attempts.

In mathematics (probability theory) there is the Law of Large Numbers (you can google that term) : if you use random numbers (die rolls), the more rolls you make, the more the random factors (good luck/bad luck) will average out and cancel each other. So if you attack with such a large stack, the outcome is pretty certain to be very close to the average outcome. And the average outcome can be calculated by the AI with a fairly straightforward algorithm. For example, if you throw a six-sided die a thousand times and you add up the numbers, the resulting total will be very close to 3500.

The AI attacking in the situation in the save game was a complete misjudgement of the odds. Or something else was going wrong...
 
Sorry, but losing 97 units to 0 units can be in no way, shape or form be attributed to "bad luck". Not even close. And the outcome was the same in three different attempts.

In mathematics (probability theory) there is the Law of Large Numbers (you can google that term) : if you use random numbers (die rolls), the more rolls you make, the more the random factors (good luck/bad luck) will average out and cancel each other. So if you attack with such a large stack, the outcome is pretty certain to be very close to the average outcome. And the average outcome can be calculated by the AI with a fairly straightforward algorithm. For example, if you throw a six-sided die a thousand times and you add up the numbers, the resulting total will be very close to 3500.

The AI attacking in the situation in the save game was a complete misjudgement of the odds. Or something else was going wrong...
Don't forget that C2C does not use a new random seed on reload, for debugging purposes. So if you reload the same turn, the outcome will still be the same.

Although, my personal theory on this is that the overall odds at the beginning were somewhat reasonable, but were dependent on the first X battles doing some certain minimal amount of damage. The RNG was against it, but the AI failed to reevaluate after its initial losses. I'm wondering how often the AI reconsiders its decisions, since it seems possible that what happened was along the lines of "If I throw stack A at stack B, I have a 50% chance of success", but after the first 20 losses, the overall odds dropped significantly but no reevaluation (and thus retreat) took place.


Oh, also, I checked the latest SVN files, the 221B Baker Street Great Wonder (in Modules/Vokarya) is still giving +1000 culture and espionage, along with +50% espionage. I really feel like somebody with SVN access should go and change that to 10 of each, as it only takes 5 seconds and 1000 is ridiculously wrong.
 
Did something happen to the "Civic Upkeep", because it doesnt change like it used to, not until, waaaay late like Modern Era or so??? Then its only from a 1:gold: to a 2:gold:??

See pic, and what i have circled is for ALL civics?? Did i change something that needs to be "back"??:confused:
 
Sorry, but losing 97 units to 0 units can be in no way, shape or form be attributed to "bad luck". Not even close. And the outcome was the same in three different attempts.

In mathematics (probability theory) there is the Law of Large Numbers (you can google that term) : if you use random numbers (die rolls), the more rolls you make, the more the random factors (good luck/bad luck) will average out and cancel each other. So if you attack with such a large stack, the outcome is pretty certain to be very close to the average outcome. And the average outcome can be calculated by the AI with a fairly straightforward algorithm. For example, if you throw a six-sided die a thousand times and you add up the numbers, the resulting total will be very close to 3500.

The AI attacking in the situation in the save game was a complete misjudgement of the odds. Or something else was going wrong...
With each attack, the first few rounds are what matters the most. Thereafter, the unit that got the upper hand gains steam and it makes it harder and harder for the losing, increasingly damaged unit to make a comeback.

If the odds are nearly overwhelming against the first defenders, the hope in lemming style attacks is to wear down those initial defenders with a few nearly impossible hits. The goal, of course, is to weaken them enough that later attackers can start getting the upper hand.

In c2c, this is much harder to accomplish than it was in vanilla. The evaluation may believe it is more possible that it is and you also have to understand the evaluation is not absolute odds mathematics but boils down to much simpler unit power counts to get what the code thinks is an assumable conclusion which does not take into account this increased difficulty. On a smaller scale, this works fine but when you start talking about nearly evenly matched large multi hundreds in the stacks, its easy for these approximation mechanisms to get thrown off of reality significantly.

Like many other potential improvements we could make, trying too hard to give stronger accuracy to these evaluations may end up costing a tremendous price in turn times. Not that it shouldn't be looked into, just that it's an area to take great care in and very difficult to directly test.

EDIT: Probability theory is pretty much what is used to lean against in the coding that exists but it doesn't take into account the weakening of units as they get damaged that takes place in C2C. I'm guessing this is the issue basically. Think of it this way: A unit may get an average of a minimum of 6 5% chances to injure that indomitable foe they face by the time they die in the standard vanilla combat system. When they do strike a hit, they will deal a minimum of 6 damage of 100. Enough units and you can overwhelm an enemy with such a system.

In C2C the minimums are pretty much gone and the chances get worse every round they didn't succeed. So that same combat in C2C would mean 1 round to get a 5% chance to strike a hit which may do 3 pts out of 100 and then, failing to do so the first round, the next round its a 3% chance to do 2 pts of 100, then the third round a 1% chance to do 1 pt of damage and then 1 % chance to do 1 pt, then failing that round they die.

This changes the underlying coded assumption that enough units can overcome extremely powerful defenders.

Don't forget that C2C does not use a new random seed on reload, for debugging purposes. So if you reload the same turn, the outcome will still be the same.

Although, my personal theory on this is that the overall odds at the beginning were somewhat reasonable, but were dependent on the first X battles doing some certain minimal amount of damage. The RNG was against it, but the AI failed to reevaluate after its initial losses. I'm wondering how often the AI reconsiders its decisions, since it seems possible that what happened was along the lines of "If I throw stack A at stack B, I have a 50% chance of success", but after the first 20 losses, the overall odds dropped significantly but no reevaluation (and thus retreat) took place.
That's pretty much it right there in a nutshell. And if it did re-evaluate with greater frequency, it would absolutely slaughter turn times. Those evaluations are already singularly one of the greatest sources of lag in the game. Imagine then telling it to happen more often.

Oh, also, I checked the latest SVN files, the 221B Baker Street Great Wonder (in Modules/Vokarya) is still giving +1000 culture and espionage, along with +50% espionage. I really feel like somebody with SVN access should go and change that to 10 of each, as it only takes 5 seconds and 1000 is ridiculously wrong.
When this comes up in the debug queue for me if it hasn't been done yet I'll do it. I haven't because I thought it was DH's building.

Did something happen to the "Unit Upkeep", because it doesnt change like it used to, not until, waaaay late like Modern Era or so??? Then its only from a 1:gold: to a 2:gold:??

See pic, and what i have circled is for ALL civics?? Did i change something that needs to be "back"??:confused:
Hmm... well, unit upkeep actually works now for one thing. But if you're saying that it never tallies up then that's possibly another issue entirely. Are you keeping your forces within the amount of units you get for free?

I've noticed correct upkeep shifts when large stacks leave my borders lately so I'm not sure what could be causing your report.

EDIT: looking at the pic again, are you talking about civic upkeep or unit upkeep? Those numbers do look waaaaaaaaaaaaaaaaaaay too small for civic upkeep of course but could that be due to a trait you have being perhaps too severe at reducing upkeep amounts?
 
EDIT: looking at the pic again, are you talking about civic upkeep or unit upkeep? Those numbers do look waaaaaaaaaaaaaaaaaaay too small for civic upkeep of course but could that be due to a trait you have being perhaps too severe at reducing upkeep amounts?

It used to go up like 3-10 sometimes, depending on the civic u pick, but now it just stays at 1 for some reason , i hope i am explaining it//
 
It used to go up like 3-10 sometimes, depending on the civic u pick, but now it just stays at 1 for some reason , i hope i am explaining it//
There are tags in the xml for that but I'm not sure if they are on the gamespeeds, the difficulty settings or the civics themselves. And there are numerous factors that come into the final displayed # like traits, for example. That's Civic Upkeep you are referring to by the way.

Joe might have a better idea why the values are so low for you as I think he's got a better understanding right now of how it all comes together.

Unit upkeep has had some coding adjustments to get it to work properly lately but that's not what you are referring to there. What you are pointing to would have to be a matter of xml changes alone.
 
Oh, also, I checked the latest SVN files, the 221B Baker Street Great Wonder (in Modules/Vokarya) is still giving +1000 culture and espionage, along with +50% espionage. I really feel like somebody with SVN access should go and change that to 10 of each, as it only takes 5 seconds and 1000 is ridiculously wrong.

When this comes up in the debug queue for me if it hasn't been done yet I'll do it. I haven't because I thought it was DH's building.

It is one of Vokarya's. I'll see if I can get to it today.

edit It is one of those buildings awaiting the Great Detective working.
 
Status
Not open for further replies.
Back
Top Bottom