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

For @Thunderbrd : In this game, all my units have the forestry or the hillman promotion, they lose the ability to make the double moves granted by those promotions since rev 10688 or 10689.
 

Attachments

  • Oiam BC-77227.CivBeyondSwordSave
    1.7 MB · Views: 61
When my Drone Helicopter passed 2000 in strength it startet to count down when more XP was added. Now it is -1988.36 and is unusable until I give it another 2000XP to get back to zero i guess. Does this apply to all units?
Game is build 10650, using unlimited XP.
Screenshot included.

Another thing is that rival civs stockpiling guard units in their cities. I had to set a cap at 100 units per tile, else they get houndreds of units in each city which makes the game very slow. This I have had for some months now, always using latest builds.

Civ4ScreenShot0000.JPG
 
When my Drone Helicopter passed 2000 in strength it startet to count down when more XP was added. Now it is -1988.36 and is unusable until I give it another 2000XP to get back to zero i guess. Does this apply to all units?
Yes, as programmers didn't thought, that someone may accumulate this much XP on single unit.
That is you managed to cause overflow.
 
Yes, as programmers didn't thought, that someone may accumulate this much XP on single unit.
That is you managed to cause overflow.
Don't you want to know how come it's 10902AD? Advanced Start, or is there a 'natural' way that can happen:rolleyes:?

@futar :
XP only gives strength x20 by Quality Ups. So how many of those have you taken, and is there no maximum (I did note the 1700HP which implies 7. That seems like too many, but I'm not familiar enough with Size Matters to be sure of that)?

How many XP has the unit received all up (more than 264 obviously, but then Quality Ups reset XP to 0)? And how did it get that many?

By "started to count down" you must mean it changed to -2000 and started to count up/down back towards zero (that's what overflows do). I just thought that needed clarification.

It appears you have mucked around and broken the mod (slightly). If you try hard enough you can do that. I'm pretty sure there's no way to stop you. I find it more fun not to try so hard.
 
Don't you want to know how come it's 10902AD? Advanced Start, or is there a 'natural' way that can happen:rolleyes:?
Either advanced start or calendar calibration sent calendar way out of whack.
But this game could been tampered though.
 
Don't you want to know how come it's 10902AD? Advanced Start, or is there a 'natural' way that can happen:rolleyes:?

@futar :
XP only gives strength x20 by Quality Ups. So how many of those have you taken, and is there no maximum (I did note the 1700HP which implies 7. That seems like too many, but I'm not familiar enough with Size Matters to be sure of that)?

How many XP has the unit received all up (more than 264 obviously, but then Quality Ups reset XP to 0)? And how did it get that many?

By "started to count down" you must mean it changed to -2000 and started to count up/down back towards zero (that's what overflows do). I just thought that needed clarification.

It appears you have mucked around and broken the mod (slightly). If you try hard enough you can do that. I'm pretty sure there's no way to stop you. I find it more fun not to try so hard.

Yes, I meant really counting up from -2000. Sorry for making that unclear.

The unit got like around 50 XP at its creation (as a type of horse military national unit). (Now new Drone Helicopters starts with 211 XP). Then sizemattered together, and adding to it a warlord and general. The rest of the XP are from military victories and upgrades to new units. I can't remember how many quality ups I did, but maybe you can see it in the screendump from my first post.
It is played at fastest speed (really a test game). And with only military victory as winning condition. At this gamespeed the games advances slower relative to the year, I was in iron age at around 2019.

Game is tampered only at making more animals and more barbarians appear, also made to not show city buildings as I find it runs faster without them.(in A_New_Dawn_GlobalDefines.xml).
And it's not using advanced start. If you play long enough I guess you can play until the years also overflow (?). I am glad the Treasury overflow problem was fixed some time ago.

This 10650 build is the most stable I've tried for a long long time. Usually the game crashes before I reach Information Age. I don't think I have broked the mod as I believe you should be able to play the game to its limits. I include the latest savegame and my (slightly) edited A_New_Dawn_GlobalDefines.xml if you want to look at it yourself.
 

Attachments

  • futar BC-31000.zip
    1.6 MB · Views: 49
  • A_New_Dawn_GlobalDefines.xml
    11.7 KB · Views: 47
It is played at fastest speed (really a test game). And with only military victory as winning condition. At this gamespeed the games advances slower relative to the year, I was in iron age at around 2019.
This is just illusion - its just you being too slow compared to calendar progression on Ultrafast.

Game would advance slower calendarwise and turnwise on slower game speeds.
Technically on Normal you would spend 4x more turns to get here compared to Ultrafast.

By the way calendar date is not saved if you play past end turn.
That is past 500/1000/2000/... turn on Ultrafast/Blitz/Normal/... calendar will revert to 200 000 BC everytime you load game.

On Blitz you would be in Information era at ~600th turn or so depending on how you play.
Typical tech rate is around two/one/half tech per turn on Ultrafast/Bitz/Normal...
 
Last edited:
Which is the main way I fixed the problem in the sea travel. This is some tricky stuff trying to rig the math to work a touch differently between these two cases. I'll have to evaluate the move cost of hills and forests to see exactly how everything is adding up. This might be an XML fix at this point.
Yes, as programmers didn't thought, that someone may accumulate this much XP on single unit.
That is you managed to cause overflow.
Not an XP overflow but a stack overflow on strength in general which has numerous decimal adjustments to get to the final calculation, which itself is a float. This is kinda a known lategame problem that can happen on SM that I knew about but didn't have to address until recently because games could never go this far before. I can't promise a quick fix on this.

Late game has some bugs y'all... that's kinda where we stand. Scaling breaks a lot of things after a point.
 
herd of horses have the wrong nif. . .

also the Nea Wanderer and Brute

more" rows 1-4 have wrong nif's also etc etc......
Are you sure you are not using low graphic settings/no unit animations, and thus not seeing reskins properly?
 
Which is the main way I fixed the problem in the sea travel. This is some tricky stuff trying to rig the math to work a touch differently between these two cases. I'll have to evaluate the move cost of hills and forests to see exactly how everything is adding up. This might be an XML fix at this point.
Ok, I figured out what was wrong and a trick that should work for all situations.
 
Ok, I figured out what was wrong and a trick that should work for all situations.

The whole thing seems like a terrible hack. After the change to make the movement costs additive the double moves tags should have been changed into something like ignores feature and ignores terrain movement costs tags.

What is the issue you are trying to solve with making it possible for the movement costs to be higher as the number of moves a unit has? Why not make it impossible for some units to move through instead.
 
The whole thing seems like a terrible hack. After the change to make the movement costs additive the double moves tags should have been changed into something like ignores feature and ignores terrain movement costs tags.

What is the issue you are trying to solve with making it possible for the movement costs to be higher as the number of moves a unit has? Why not make it impossible for some units to move through instead.
Here's the thing... the original vanilla method of establishing the move cost for a plot was to make a plot have a move cost of EITHER the XML established cost of the terrain (if there is no feature) OR the feature (including hills overriding forests). Therefore, when it came to double move, it would reduce the movement cost to half, which would be less than a full 1 cost.

Note: In Vanilla a hill or forest cost something like 1.5 movement points rather than a full 2, which is why when it was halved it would allow an extra movement for a 1 movement point unit.

Therefore a warrior with 1 movement would move 2 spaces if their first move was into a forest because they would have leftover movement points (a float value at this point) after the first plot was moved into. That would work on a hill too as long as there was a forest. And if he had double move on hills, it would work whether the hill had a forest or not. Otherwise it pretty much works like you might expect.

However, what I just had was a lot like what you just suggested and I was thinking that would work, except that since the terrain and feature is additive to get a final cost now, it would mean that the unit would need BOTH the double move on the feature AND the terrain to get the ability to move an extra space beyond like it was in vanilla. This way matches the original math much more closely and it works in all situations I considered would need checking.

This way, moving onto a plot with a feature you have double move would thus assume that you have double move for the terrain portion of the assigned movement cost of that plot as well as for the feature's portion of the movement cost and thus 1/2(for the feature half of the overall plot equation) of 1/2(for the terrain half of the overall plot equation) = 1/4 the move cost for that plot, rather than just 1/2. Thus, this is much closer to vanilla behavior if you have additive terrain and feature costs to determine move costs for a plot. I realized I was failing to take into account the second half of the equation, the terrain half, which was overridden completely in Vanilla instead.

As you can see, if we don't get this working close to Vanilla on this, many players do complain that it is a bug, including my wife who is very attached to this working as it did. Even the complaint today was that it was behaving exactly as you said it should in your post.
 
Last edited:
Are you sure you are not using low graphic settings/no unit animations, and thus not seeing reskins properly?
I've been playing all day and haven't seen a single error like SO is reporting here.
Check your graphics options SO, make sure you don't have "animations frozen" option checked.
yeppers checked it by mistake, thx. . . DUH!!!!:blush::blush:
 
Why not make it impossible for some units to move through instead.
It's an interesting proposition, I've seen it be done in plot based games before and it added an interesting layer to that game.
If a unit have full movement points (haven't moved this turn) it can enter all legal neighboring plots even if the cost is higher than its movement points, but if the units remaining movement point is not higher or equal to the plot cost then the unit cannot enter the plot. (This is what I've seen in other plot based games and sounds like what you were proposing at least.)

There are some implications that needs to be thoroughly considered if we wanted to add such a rule to movement.
e.g. We would have to consider how the AI would deal with this without getting landlocked due to being in a valley surrounded by forested hills or something.
The path calculation AI use would have to understand that the unit sometimes need to not use all its movement points every turn to get the most efficient and safe route from A to Z.
Forced march would play nicely with these rules, but the AI don't know when to use it at the moment.

I'm not saying it's a good idea, not a bad one either, just considering it as a valid idea in case we want to further discuss it.
 
Here's the thing... the original vanilla method of establishing the move cost for a plot was to make a plot have a move cost of EITHER the XML established cost of the terrain (if there is no feature) OR the feature (including hills overriding forests). Therefore, when it came to double move, it would reduce the movement cost to half, which would be less than a full 1 cost.

Note: In Vanilla a hill or forest cost something like 1.5 movement points rather than a full 2, which is why when it was halved it would allow an extra movement for a 1 movement point unit.

Therefore a warrior with 1 movement would move 2 spaces if their first move was into a forest because they would have leftover movement points (a float value at this point) after the first plot was moved into. That would work on a hill too as long as there was a forest. And if he had double move on hills, it would work whether the hill had a forest or not. Otherwise it pretty much works like you might expect.

However, what I just had was a lot like what you just suggested and I was thinking that would work, except that since the terrain and feature is additive to get a final cost now, it would mean that the unit would need BOTH the double move on the feature AND the terrain to get the ability to move an extra space beyond like it was in vanilla. This way matches
the original math much more closely and it works in all situations I considered would need checking.

This way, moving onto a plot with a feature you have double move would thus assume that you have double move for the terrain portion of the assigned movement cost of that plot as well as for the feature's portion of the movement cost and thus 1/2(for the feature half of the overall plot equation) of 1/2(for the terrain half of the overall plot equation) = 1/4 the move cost for that plot, rather than just 1/2. Thus, this is much closer to vanilla behavior if you have additive terrain and feature costs to determine move costs for a plot. I realized I was failing to take into account the second half of the equation, the terrain half, which was overridden completely in Vanilla instead.

As you can see, if we don't get this working close to Vanilla on this, many players do complain that it is a bug, including my wife who is very attached to this working as it did. Even the complaint today was that it was behaving exactly as you said it should in your post.
This issue came up again because you
changed the movement costs calculation in this change in CvPlot.

What was the reason for that change and
are you sure it didn't cause any other issues?

C2C changed lots of Vanille rules why is it so important to keep these double moves even with a complely different set of movement rules? A set of 'ignores movement costs from xxx' tags would make much more sense with your new set of rules.
 
Top Bottom