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

[Thunderbrd]

Ok i had a bit of time and something is really off there. Even after a few turns i had the first wrong value this must have something to do with all the changes in CvUnit::defenderValue and the functions it calls. Alot changed since Koshling added that cache so it seems it's no longer working. I don't think it would be possible to cache it another way because CvUnit::defenderValue seems to return a different value starting at the second time it is called with the same arguments in the same turn.

Ok, so this was the main turn time slowdown issue I've been suspecting has been the big cause of five and 10 minute turn times. I had disabled a seriously important caching as a result of some problems I was having with it that led to this final comment from Alberts as we tried to work out what was wrong.

For the record, I've figured out the issue.

1) CvUnit:defenderValue is not coming up with different answers each time the function is called. If it were, the unit determined to be the target would change or the odds would differ and when the caching is disabled, that is not happening. (I also did some checking to ensure it wasn't happening anyhow and even if it was, with the caching on, it wouldn't be the cause of the original issue because CvUnit::defenderValue is only called when the checksum doesn't come up with a valid hit.

2) The caching is working fine... UNTIL any assassination calls.

3) The reason for this most likely comes down to the fact that we're simply adding numbers to get an appropriate 'hit'. Then we check that against the current hit points to make sure its the same unit and that the unit hasn't been engaged in battle or injured in any way that could change the results of the valuation. What's happening seems to be that this allows the checksum to reference the wrong result set when assassination calls are made.

So the fix is to reinstate the caching but to exclude assassination combat checks and always force those to fully evaluate. Unfortunately, this does suggest there is a fundamental potential flaw in the checksum method that can take place at times and should perhaps have an extra check circumstance to enforce correct referencing. But the speedup is worth it to turn it on without much heavier engineering because you'd rarely ever SEE the problem manifest. If you do, it would likely be a very odd case of the unit attacking an unexpected defender when you actually go to attack. This should not be common but it was quite common with the assassination checks because of the adjustment of the final checksum reference being in increments of 1(even 1*10 or * 100 or * 1000 and the problem would not be uncommon to replicate itself.)

So once this new dll effort has been recommitted to the SVN, I'm hoping that there will be few rule breaches and much faster end turns.

This has been one of the 'big ones' I've been hung up on for a while here.

 

[strategyonly]

So once this new dll effort has been recommitted to the SVN, I'm hoping that there will be few rule breaches and much faster end turns.

This has been one of the 'big ones' I've been hung up on for a while here.

Nice efforts, thx to everyone that helped, , . .

 

[Thunderbrd]

Musketeers, the French culture unit, are either losing their free Speed promotion immediately or failing to get it. Probably related to the promotion validity changes in SVN9270. Might as well just give them 2 base movement speed instead of messing with that, I'd say.

Ah... unique units. That explains why it had been the way it was. Well... there's other ways to work around that. The idea of course was to make it so they would hold on to that after upgrade as well, which makes it different from simply being given +1 speed as a base. We'll have to list off these when we find them. I can think of a way perhaps.

 

[Taxman66]

SVN9265

1)
I can't seem anyway to get the Arrow Barrage promotions. There is no prereq. stated on the wiki promo page for them and I can't find them on the wiki promo tree page.
Additionally the Red Fox Archer unit is supposed to start with all 3 Arrow Barrage promos, but doesn't have any; thus rendering it identical to comp bowmen.
*Figured out that I had to go into Bug and turn Archer bombard off and Ranged bombard on. I suggest that the default bug settings be reviewed and updated (e.g. turn storms off, units per tile to zero, etc...), particularly since this will be a save breaking version and we shouldn't carry over our user settings.

2)
The Hoplomachus unit is an exact duplicate of the patrol unit (as far as I can tell), what's special about it?

3)
I have a 12 pop. city on a 4 tile island that is 1 tile away from the mainland and it doesn't have any of the burial traditions available to be built. None show up even if I change the filter to show unbuildable buildings. The city is trading with the mainland as evidenced by the resource tab. Ship building is my latest navel tech.


Sorry if these were already covered/fix.
Save game can be provided if desired.

 

[BlueGenie]

How come the Fortify button no loner does anything?
Should it not do the fortify build-up promotion automatically when clicked?
It gets very tedious to go through every single City Defender to start building fortify build-up with them after upgrading them.

Cheers

 

[Thunderbrd]

1)
I can't seem anyway to get the Arrow Barrage promotions. There is no prereq. stated on the wiki promo page for them and I can't find them on the wiki promo tree page.
Additionally the Red Fox Archer unit is supposed to start with all 3 Arrow Barrage promos, but doesn't have any; thus rendering it identical to comp bowmen.
*Figured out that I had to go into Bug and turn Archer bombard off and Ranged bombard on. I suggest that the default bug settings be reviewed and updated (e.g. turn storms off, units per tile to zero, etc...), particularly since this will be a save breaking version and we shouldn't carry over our user settings.

We should probably figure out how to turn Archer bombard right off and set Ranged Bombard as AT LEAST a default on.

How come the Fortify button no loner does anything?
Should it not do the fortify build-up promotion automatically when clicked?
It gets very tedious to go through every single City Defender to start building fortify build-up with them after upgrading them.

1) I noticed it wasn't working properly in the MP game but I was not aware it wasn't in the main. It SHOULD still be functioning so I'll have to look into why it's not.
2) You should be able to use the blue shield icon (auto-buildup selection) to avoid the tedium.

I realize that it may seem like it should be trivial to give a 'group selection' feature to the build ups but it's not as apparent how to do this as it may seem given that it's an entirely different method to many other 'group selection' features in the game. If you select a buildup that's not valid for all units selected, for example, it can cause a crash that way.

 

[BlueGenie]

Volcano event:
When the game starts with volcanoes it has not added the +1 to all surrounding tiles but when the volcano is being removed through the "volcano goes dormant" event the tiles all lose one food.

Cheers

 

[TrippedOnACloud]

Volcano event:
When the game starts with volcanoes it has not added the +1 to all surrounding tiles but when the volcano is being removed through the "volcano goes dormant" event the tiles all lose one food.

That reminds me, in almost all of my recent games, I've noticed that there are no longer any active or even dormant volcanoes remaining on the map. Presumably the events/etc that remove the volcanoes are happening more often than the eruptions, but it's rather disappointing to settle next to one in hopes of building the Grand Fire Festival and such, only to have it go extinct and never return.

Also, I kind of miss the +50 bug, haha.

Regarding the unique units and their promotions, I don't recall very many that get free promotions that aren't normally available to their combat class. Musketeers get Speed, I think there's one Mounted unit that gets Poison Tips, and... I can't really think of any others. Also, if the intent was for it to retain the bonus after upgrading, it was failing anyway. Musketeers lose the Speed promotion on upgrading due to invalid unit class, and did even before the changes.

There's also something I recently noticed with regards to blockades. I've had blockades that can't be lifted, despite the blockading ship being destroyed. What's more, they wind up wreaking havoc on affected resources, to the point where they're occasionally still accessible, or even multiplied. I suspect it's related to defender withdrawal, in that if the blockading ship withdraws from an attack it no longer counts as the blockading unit, but the blockade still persists.

 

[Dreifels]

1) in game there is no wild camel (green man), but lot of fields with camels as source fields in tghe desert.

2) mass of aurochses in desert (and this is really a failure)

3) ranking of "most powerful civs"

4) I have 2 x "Barbar" as civs and 3x "Green man", is that right? (when I look in world builder what civs exist.)

 

[TrippedOnACloud]

1) in game there is no wild camel (green man), but lot of fields with camels as source fields in tghe desert.

2) mass of aurochses in desert (and this is really a failure)

Animal spawning depends on resources, terrain, and map coordinates. That is, if your camel-deserts are at a latitude and longitude that corresponds to, say, South America or Australia, you still won't get camels.

4) I have 2 x "Barbar" as civs and 3x "Green man", is that right? (when I look in world builder what civs exist.)

Yes. Neanderthals and Barbarians, then the three categories of animals.

 

[JosEPh_II]

Ok, so this was the main turn time slowdown issue I've been suspecting has been the big cause of five and 10 minute turn times. I had disabled a seriously important caching as a result of some problems I was having with it that led to this final comment from Alberts as we tried to work out what was wrong.

For the record, I've figured out the issue.

1) CvUnit:defenderValue is not coming up with different answers each time the function is called. If it were, the unit determined to be the target would change or the odds would differ and when the caching is disabled, that is not happening. (I also did some checking to ensure it wasn't happening anyhow and even if it was, with the caching on, it wouldn't be the cause of the original issue because CvUnit::defenderValue is only called when the checksum doesn't come up with a valid hit.

2) The caching is working fine... UNTIL any assassination calls.

3) The reason for this most likely comes down to the fact that we're simply adding numbers to get an appropriate 'hit'. Then we check that against the current hit points to make sure its the same unit and that the unit hasn't been engaged in battle or injured in any way that could change the results of the valuation. What's happening seems to be that this allows the checksum to reference the wrong result set when assassination calls are made.

So the fix is to reinstate the caching but to exclude assassination combat checks and always force those to fully evaluate. Unfortunately, this does suggest there is a fundamental potential flaw in the checksum method that can take place at times and should perhaps have an extra check circumstance to enforce correct referencing. But the speedup is worth it to turn it on without much heavier engineering because you'd rarely ever SEE the problem manifest. If you do, it would likely be a very odd case of the unit attacking an unexpected defender when you actually go to attack. This should not be common but it was quite common with the assassination checks because of the adjustment of the final checksum reference being in increments of 1(even 1*10 or * 100 or * 1000 and the problem would not be uncommon to replicate itself.)

So once this new dll effort has been recommitted to the SVN, I'm hoping that there will be few rule breaches and much faster end turns.

This has been one of the 'big ones' I've been hung up on for a while here.

Can't wait to try this on my 45 min EoT game.

JosEPh

 

[JosEPh_II]

That reminds me, in almost all of my recent games, I've noticed that there are no longer any active or even dormant volcanoes remaining on the map. Presumably the events/etc that remove the volcanoes are happening more often than the eruptions, but it's rather disappointing to settle next to one in hopes of building the Grand Fire Festival and such, only to have it go extinct and never return.

Also, I kind of miss the +50 bug, haha.

Regarding the unique units and their promotions, I don't recall very many that get free promotions that aren't normally available to their combat class. Musketeers get Speed, I think there's one Mounted unit that gets Poison Tips, and... I can't really think of any others. Also, if the intent was for it to retain the bonus after upgrading, it was failing anyway. Musketeers lose the Speed promotion on upgrading due to invalid unit class, and did even before the changes.

There's also something I recently noticed with regards to blockades. I've had blockades that can't be lifted, despite the blockading ship being destroyed. What's more, they wind up wreaking havoc on affected resources, to the point where they're occasionally still accessible, or even multiplied. I suspect it's related to defender withdrawal, in that if the blockading ship withdraws from an attack it no longer counts as the blockading unit, but the blockade still persists.

I'm still getting active volcanoes in my games. But All Event(s) chance % per turn was recently reduced. Ppl complaining they were happening too often. Now we got the opposite.

And "afaik", no one has went in and changed any event recently. The only change has been the % per turn chance of any Event occurring.

JosEPh

 

[strategyonly]

So once this new dll effort has been recommitted to the SVN, I'm hoping that there will be few rule breaches and much faster end turns.

What is a approx ETA on this, just wondering????

 

[Thunderbrd]

Can't wait to try this on my 45 min EoT game.

JosEPh

What is a approx ETA on this, just wondering????

I noticed some other slight issues and kept digging just to make sure I had the right diagnosis. Something didn't sit well about my original conclusion and I was right that I was slightly off. I now know exactly what was wrong and am putting it to the fastest, simplest solution I can while maintaining a strong accuracy.

I tried reprogramming the caching entirely but Koshling knew something I didn't realize - my method didn't work at all because we're operating within a const function here. I really don't like consts!

Anyhow, suffice it to say, an attempt to massively rewrite the caching for greater accuracy and memory efficiency failed but led to the more accurate diagnosis and thus the most honest 'fix'.

I'll have this up very soon.

@Joe: I suspect there's a few other issues afoot in your game so if it doesn't diminish turn times as much as hoped don't be too surprised. I expect to find more to address when I look directly into your save.

 

[JosEPh_II]

If it takes the Eot down to 3 min. level I will be Happy.

JosEPh

 

[Publicola]

I think I discovered a bug related to city maintenance. No idea where it would be, though.

Edit: I'm using the most recent "v.36 Crime Patch," corresponding to SVN 9265.

The relevant civics I was using were:

Chiefdom: +20% distance maintenance, +20% number of cities maintenance
Obedience: +25% distance, +50% number
Tribal: +50% distance, +35% number
No Currency: +30% distance, +25% number

I wasn't able to check that these modifiers were factored in to the raw maintenance numbers for my cities. However, when distance + number + building maintenance were tallied, I discovered that there was a -80% modifier reducing maintenance in each of my cities. I checked the buildings, wonders, and special tabs for anything that might explain it, but didn't see anything. It wasn't the Palace, either -- that merely provided an additional -10% maintenance modifer (so my capital city's maintenance was reduced by 90% total).

Was this intentional? Or is this a known bug?

 

[JosEPh_II]

I think I discovered a bug related to city maintenance. No idea where it would be, though.

Edit: I'm using the most recent "v.36 Crime Patch," corresponding to SVN 9265.

The relevant civics I was using were:

Chiefdom: +20% distance maintenance, +20% number of cities maintenance
Obedience: +25% distance, +50% number
Tribal: +50% distance, +35% number
No Currency: +30% distance, +25% number

I wasn't able to check that these modifiers were factored in to the raw maintenance numbers for my cities. However, when distance + number + building maintenance were tallied, I discovered that there was a -80% modifier reducing maintenance in each of my cities. I checked the buildings, wonders, and special tabs for anything that might explain it, but didn't see anything. It wasn't the Palace, either -- that merely provided an additional -10% maintenance modifer (so my capital city's maintenance was reduced by 90% total).

Was this intentional? Or is this a known bug?

What Difficulty level, Game speed, and Map size?

JosEPh

 

[Publicola]

What Difficulty level, Game speed, and Map size?

JosEPh

If I recall correctly:

Difficulty level was Noble
Game Speed was Snail
Map Size was Giant (I was playing on the 5-civ Giant Earth Map scenario)

 

[olduser]

Ok, so this was the main turn time slowdown issue I've been suspecting has been the big cause of five and 10 minute turn times. I had disabled a seriously important caching as a result of some problems I was having with it that led to this final comment from Alberts as we tried to work out what was wrong.

For the record, I've figured out the issue.

1) CvUnit:defenderValue is not coming up with different answers each time the function is called. If it were, the unit determined to be the target would change or the odds would differ and when the caching is disabled, that is not happening. (I also did some checking to ensure it wasn't happening anyhow and even if it was, with the caching on, it wouldn't be the cause of the original issue because CvUnit::defenderValue is only called when the checksum doesn't come up with a valid hit.

2) The caching is working fine... UNTIL any assassination calls.

3) The reason for this most likely comes down to the fact that we're simply adding numbers to get an appropriate 'hit'. Then we check that against the current hit points to make sure its the same unit and that the unit hasn't been engaged in battle or injured in any way that could change the results of the valuation. What's happening seems to be that this allows the checksum to reference the wrong result set when assassination calls are made.

So the fix is to reinstate the caching but to exclude assassination combat checks and always force those to fully evaluate. Unfortunately, this does suggest there is a fundamental potential flaw in the checksum method that can take place at times and should perhaps have an extra check circumstance to enforce correct referencing. But the speedup is worth it to turn it on without much heavier engineering because you'd rarely ever SEE the problem manifest. If you do, it would likely be a very odd case of the unit attacking an unexpected defender when you actually go to attack. This should not be common but it was quite common with the assassination checks because of the adjustment of the final checksum reference being in increments of 1(even 1*10 or * 100 or * 1000 and the problem would not be uncommon to replicate itself.)

So once this new dll effort has been recommitted to the SVN, I'm hoping that there will be few rule breaches and much faster end turns.

This has been one of the 'big ones' I've been hung up on for a while here.

Good work that should help alot with the turn times.

It suggests that caching never really worked, i though it did so i didn't look at the checksum. There must be some error in the algorithm that is used in CvChecksum that leads to collisions in case you add 1 to it.

CvChecksum is used for other things as well so it could cause more issues.

 

[JosEPh_II]

If I recall correctly:

Difficulty level was Noble
Game Speed was Snail
Map Size was Giant (I was playing on the 5-civ Giant Earth Map scenario)

1st your Capitol is not affected by the Dist. Maint %. All other cities are.
2nd I could not find the GEM 5 civ scenario map. And Only 2 maps in the Maps and Scenario sub forum are up to date with 9265; Pit2015's UEM and the RFC from cross clayton.
3. Was this game continued from a previous version? Or did you start it New with 9265?

4. The Big One: On Noble the DistMaint is reduced by 20%, Number of Cities Maint by 25% and Inflation by 35% which = 80%.

JosEPh