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

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?
That change was because double terrain movement was causing all early ships to be able to move into and then out of reef and coral plots without being stuck on them when only kayaks and outriggers (early exploration boats) were intended to be able to do so.

Coastal plots cost 2 movement as a base terrain with wooden ships having double movement in coast terrain. This is meant to make each coastal plot only have a cost of 1 for wooden ships, which is not supposed to completely negate the cost of any features in those coasts.

What that first change attempted to correct was the fact that the plot would, in this order:

1) Tally up the movement cost of terrain + feature.
2) Limit the cost of the plot to the movement remaining on the unit. (this is the step removed in that revision)
3) Then half the movement cost for each applicable double terrain or double feature (I'll include hills in this as a feature for the remainder of this discussion though it's somewhat a special case). Thus if the unit had forest double move, the plot overall cost would be halved if it had a forest, and if it had plains double move and the forest was on a plains in that plot, the unit would halve the cost of the plot again. (There's kinda an undiscussed bug in this too if you think enough on it.)

By limiting the cost first, no amount of movement cost placed on a feature could stop a unit with 2+ movement that had EITHER double terrain OR double feature movement applying in that plot.

So my original analysis saw it as a flaw that we were reducing the total before we halved (then potentially halved again) the cost of the plot to the remaining movement of the unit.

Taking that away and giving explorers double movement through reefs and coral ALSO did solve the math equation for that, but then a one space movement wouldn't get the added movement if they moved into a forest if they had double forest movement. That was the bug reported, which is what you are advocating the rules system should work like.

If that were to be the rule, then the promotions to take double forest movement and double hill movement would lose all value in 90% of their applications and they are situated on the promotion tree in a location that makes a player have to go a little suboptimal to get this ability, which can greatly enhance the speed at which you get some exploration and hunting units to get around the map, particularly the tougher ones, also a key component in a strategy for making axes and spears capable of often getting quickly into a surrounding position for S&D. There's a number of play strategies that hinge on this working as it was originally designed. Which answers your question of why it's important to retain this expected behavior and to not let it be obsoleted by other rule changes.

So as I looked at this again, I realized that in the situation we have now of an additive move cost between terrain and feature, there are now two halves of a cost equation to consider, not just one. Furthermore, that feature double movement is simply meant to be more powerful than terrain double movement. You want a mounted unit with double movement through flat terrains to be able to half the movement cost of the flat, unfeatured terrains he moves through, but not completely be able to move an extra space through a flat terrain with a forest, but you DO want that one space moving axeman to be able to get through that forest plot and move to the next before his movement is up. Thus the terrain double move doesn't even apply IF there's a feature there to replace the most important aspect of that plot AND you have the feature move doubling ability that applies to that feature. However, you do halve the movement cost of the plot if you have a feature there and it's the right terrain you have the double movement for, but that may well not mean that you're going to get through it in full because the terrain and feature on it do add their values together. But if you HAVE the feature double movement, you must be assumed to be able to get through the terrain under that feature with the same amount of efficacy.

I know it's complicated but it's important that it works this way for the sake of a lot of tactical strategy that the game has been founded on from the beginning to be applicable and for other complaints (Such as DH's complaint that he couldn't set the reefs and coral to any amount which would be enough to stop wooden ships with more than 1 movement) to be addressed properly as well. Now both situations work. Maybe this could bring up some other situations but ultimately, the math actually does make sense to the intention of the tags and it's not really the hack it looks like so I'm fairly confident this is the proper movement equation.

The main thing to understand is that feature double movement insists that the terrain underneath that feature is also considered halved if the feature exists there but terrain double movement does not have a second half of the total movement cost equation to be concerned about and does not demand that if there is a feature on the plot that both halves of the equation are halved, only that the sum total of the plot is, so that features may still be able to stop the movement of units with double terrain movement, even on a plot that has the stated terrain.
 
That change was because double terrain movement was causing all early ships to be able to move into and then out of reef and coral plots without being stuc
on them when only kayaks and outriggers (early exploration boats) were intended to be able to do so.

That could have been done in other ways
without affecting other rules as well. It would have been possible to change this rule for narval movement only. Or by adding tags for half movement through xxx.
 
@Thunderbrd:
After the release we really have to rethink some plot tooltip text content: 8800_20190718194303_1.jpg
The obvious one would be to not display all the promotions held by every single unit on the plot.

I'm calling on you, or any other dll programmer who is interested, because the text content of tooltips is constructed in dll code. Python only display it.
 
Last edited:
That could have been done in other ways
without affecting other rules as well. It would have been possible to change this rule for narval movement only. Or by adding tags for half movement through xxx.
Could've but this is the original design intent being struck right on the head so I'm not sure why we'd have needed such further programming.
 
@Thunderbrd:
After the release we really have to rethink some plot tooltip text content: View attachment 529995
The obvious one would be to not display all the promotions held by every single unit on the plot.

I'm calling on you, or any other dll programmer who is interested, because the text content of tooltips is constructed in dll code. Python only display it.
I've often questioned whether they should be displayed or not and I'd say no because it is very easily overwhelming, but it is also important for some strategic evaluating to know - unless we think it shouldn't matter or we should provide the info in a better way, like a hotkey click that opens up a whole page that details the contents of the units on the plot perhaps. Flat out there's just too much critical information we need to deliver somehow and the delivery mechanism has surpassed the grace of even an expanded and widened hover tooltip.
 
There is an Event with Hunters , where to choose one of three posibilities of promotions.
In the text it says "Every Chaser , Tracker or Hunter " will become the selectet promotion.
But only one of my hunters have it get.
 
I've often questioned whether they should be displayed or not and I'd say no because it is very easily overwhelming, but it is also important for some strategic evaluating to know - unless we think it shouldn't matter or we should provide the info in a better way, like a hotkey click that opens up a whole page that details the contents of the units on the plot perhaps. Flat out there's just too much critical information we need to deliver somehow and the delivery mechanism has surpassed the grace of even an expanded and widened hover tooltip.
I don't feel the promotion list for enemy units is critical information at all, all I find critical to know is strength, movement points and unit level.
We should imo restrain it to only show the promotions held by the first unit in that list, the one on the top is usually the top dog unit of a stack too.

If one can get a unit on the same plot as the enemy units are on one can also look at each unit individually in the unit plot list. So that gives more usage for spy like units or other invisible units.
I mean invisibility can then be used to gather information about the enemy army instead of getting the information served for free in a tooltip that explodes.
 
I don't feel the promotion list for enemy units is critical information at all, all I find critical to know is strength, movement points and unit level.
Pretty critical to know if an Axemen has more anti-melee promos than yours does for example.
We should imo restrain it to only show the promotions held by the first unit in that list, the one on the top is usually the top dog unit of a stack too.
At that point, you might as well just not have it show at all because it's the rest of the stack that will still matter what they've been specialized in.
If one can get a unit on the same plot as the enemy units are on one can also look at each unit individually in the unit plot list. So that gives more usage for spy like units or other invisible units.
Very good point... that's the kind of thing that sells me on taking the promotion display out of the plot list display entirely. For faster evaluation and debugging, it would be nice if, at least with chipotle on, you could still hit a hotkey and get the display of them though.
I mean invisibility can then be used to gather information about the enemy army instead of getting the information served for free in a tooltip that explodes.
Makes a lot of sense, yes.


The promos are added in the dll part of the display aren't they? So would that have to be corrected in the code or is that something PPIO rewrites entirely?
 
An error with the UI.
Happens when you have so much units in town ,that you need to use the " Arrow down" to see the second columm.
Then , when going to another unit in field , there is something missing.
Pic 1 : something missing
Pic 2 : So it should be

Solveable only through save and load...
 

Attachments

  • Civ4ScreenShot0030.JPG
    Civ4ScreenShot0030.JPG
    292.8 KB · Views: 137
  • Civ4ScreenShot0031.JPG
    Civ4ScreenShot0031.JPG
    307 KB · Views: 131
The promos are added in the dll part of the display aren't they? So would that have to be corrected in the code or is that something PPIO rewrites entirely?
It's entirely managed by the dll, python just displays the string it gets from the dll on the screen within a tooltip window. I had a look at the code some months back, and removing the promos looked straight forward enough.
An error with the UI.
Happens when you have so much units in town ,that you need to use the " Arrow down" to see the second columm.
Then , when going to another unit in field , there is something missing.
Pic 1 : something missing
Pic 2 : So it should be

Solveable only through save and load...
Ok, looks like a PPIO issue, I'll look into it. Fixed
 
Last edited:
It's entirely managed by the dll, python just displays the string it gets from the dll on the screen within a tooltip window. I had a look at the code some months back, and removing the promos looked straight forward enough.
Yeah I remember debating if we needed them or not but you've clearly sealed it for me with the idea of requiring an invisible to go check out the tile - back then you couldn't share tiles with anything but spies BUT spies were easily captured in foreign lands so were super unreliable to use in this manner. I'll try to remember to correct this in the next version. Remind me if you need to please.
 
What is the difference between Polar Deep sea and Deep Sea that restricts outrigger movement?

Seems odd.
 

Attachments

  • Civ4ScreenShot0091.JPG
    Civ4ScreenShot0091.JPG
    385.5 KB · Views: 117
  • Civ4ScreenShot0092.JPG
    Civ4ScreenShot0092.JPG
    381.2 KB · Views: 118
What is the difference between Polar Deep sea and Deep Sea that restricts outrigger movement?

Seems odd.
Odd indeed, especially odd that there is deep sea that is not polar that far north on the map.

Probably an oversight in the movement rule xml setup somewhere where I or someone forgot to add the temperate version of that terrain to some list.

@raxo2222: want to investigate? I could look into it tomorrow after getting some sleep.
 
Could've but this is the original design intent being struck right on the head so I'm not sure why we'd have needed such further programming.
The answer in your previous post.
That change
was because double terrain movement was causing all early ships to be able to move into and then out of reef and coral plots without being stuck on them when only kayaks and outriggers (early exploration boats) were intended to be able to do so.

You want to have some units moving slower as other units trough the same plot. This means half moves through a feature or terrain.
 
The answer in your previous post.


You want to have some units moving slower as other units trough the same plot. This means half moves through a feature or terrain.
In that particular case, it's a sweeping rule difference between double moves on terrains and double moves on features that is key to the end behavior desired. At this point, those special units (the wooden ship/explorer units) have both double moves on coast and double moves on the Reef and Coral, and that's why it works for them now and makes normal wooden ships still halve all coastal plots, but not usually enough that they can get through reefs and coral now. The math works out to:

Reef & Coral: 2 + Coast: 2 = 4.

Kayaks: 2 mv, double move on Reef, Coral, Coast. The double movement on the coast doesn't count since the Reef/Coral double movement takes precedence and as it applies, the plot cost is divided by 4. 4/4 = 1. With 2 movement, they can get through to the next plot. It can even get away with being a bit higher on Reefs and Coral and because they have 2 movement, they could get through that plot until the total plot move cost becomes 8 or higher as a result of having 2 movement and double movement on the feature.

Canoes: 2 mv, double move only on Coast. A normal coast, they move 2 spaces. When they hit a Reef or Coral, they get stopped even at full movement, as they should, because the movement cost is 4 divided by 2 for their double move on the terrain. The 2 points eats up their full amount of movement (though barely).

Meanwhile, it works for the land units as well. The fact that this more closely relates to the original method of features completely overriding the movement costs of the terrain is both closer to the original movement rule intentions while still enabling the deeper strategic purpose in making terrains and features additive instead.

Again, the main point is that double feature move must take into account that there is also a terrain portion being added to the equation (which wasn't the case in the original rules), whereas double terrain move doesn't have to, and actually we don't want it to, account for the potential that a feature could be adding to the move cost of the plot, except to halve the overall total which will cut into the feature's portion of the cost some. This also keeps the benefits of both kinds of double movement from totaling to something too powerful when they both apply for a unit.

Looking at this again now, it occurs to me that we do need to increase the Reef and Coral amounts back up a bit so they still stop larger and faster wooden ships as intended as well. I have to commit another fix tonight so I'll take care of that as well.
 
In that particular case, it's a sweeping rule difference between double moves on terrains and double moves on features that is key to the end behavior desired. At this point, those special units (the wooden ship/explorer units) have both double moves on coast and double moves on the Reef and Coral, and that's why it works for them now and makes normal wooden ships still halve all coastal plots, but not usually enough that they can get through reefs and coral now. The math works out to:

Reef & Coral: 2 + Coast: 2 = 4.
Reef without improvement has movement cost of 5.
Is that intentional?
 
Odd indeed, especially odd that there is deep sea that is not polar that far north on the map.

Probably an oversight in the movement rule xml setup somewhere where I or someone forgot to add the temperate version of that terrain to some list.

@raxo2222: want to investigate? I could look into it tomorrow after getting some sleep.
I noticed that some ships can go to ocean with Optics tech instead of Astronomy.
Also you or someone forgot to add polar/tropical variants of deep sea everywhere.
Same thing happened with Trench.

I fixed those issues now.
 
Last edited:
Hmm, I can't seem to replicate the error on my side, could you give me a more detailed description on how to recreate the problem?

City with lots of units , units selected . " Down Arrow " in the bottom of screen. ->Pic 1
Even more Units ->Pic 2
Then circle to another unit , not in city stack, something from the UI is missng Pic->3
Go back to city stack , now here are the Arrows missing. ->Pic4
 

Attachments

  • Civ4ScreenShot0032.JPG
    Civ4ScreenShot0032.JPG
    431.4 KB · Views: 104
  • Civ4ScreenShot0034.JPG
    Civ4ScreenShot0034.JPG
    425.2 KB · Views: 120
  • Civ4ScreenShot0035.JPG
    Civ4ScreenShot0035.JPG
    304.9 KB · Views: 115
  • Civ4ScreenShot0036.JPG
    Civ4ScreenShot0036.JPG
    415.9 KB · Views: 111
City with lots of units , units selected . " Down Arrow " in the bottom of screen. ->Pic 1
Even more Units ->Pic 2
Then circle to another unit , not in city stack, something from the UI is missng Pic->3
Go back to city stack , now here are the Arrows missing. ->Pic4
Ok, thanks. Is this city specific though, does it work if you move all the units out of the city and do the same?
Edit: Nothing to do with cities, will take some time to debug though, lots of code to re-familiarize myself with, been a while since I wrote it.
Fixed
 
Last edited:
Reef without improvement has movement cost of 5.
Is that intentional?
Yes, and with the coast, a total of 7. 7/4 = 1.75 movement cost for those with double movement through reefs, allowing even a 2 move unit to get through it since he'd have .25 remaining after moving onto it. Any remaining amount allows another move. This is so that anything that doesn't have the double move for this sort of tile is pretty much bound to get stuck on it otherwise.
 
Back
Top Bottom