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

[Toffer90]

Ok, I will keep playing with "FREE_CITY_CULTURE = 0" as an experiment until I can notice if anything works differently than when it is "FREE_CITY_CULTURE = 2".

You can claim a plot for a city but not own it. It just means the city has dibs on it for when it has some culture and the plot is within its ownership range. (A claim is particularly more pertinent between competing cities of the same player or the same team.) The last bit of code is the part that gives it a minimum of 1 culture to that plot where the city was founded. That's the global I wouldn't mess with.

I struggle to understand what this means in game terms.
In my test game I have FREE_CITY_CULTURE = 0 = FREE_CITY_ADJACENT_CULTURE.

• When settling a city in neutral land it gets the center tile claimed right away.
  • Didn't make screenshot of this, though it is easy to test with the first settler when starting a new game.
• It is not possible to settle in foreign land.
• I tried settling a city one tile away from my capital city (changed another global to remove the city distance restriction just for this test).
  • The new city could the turn it was founded work the center tile and four other tiles that was previously claimed by the capital city.
  • Attachments illustrate this point.

 

[Thunderbrd]

Ok, I will keep playing with "FREE_CITY_CULTURE = 0" as an experiment until I can notice if anything works differently than when it is "FREE_CITY_CULTURE = 2".
I struggle to understand what this means in game terms.
In my test game I have FREE_CITY_CULTURE = 0.

• When settling a city in neutral land it gets the center tile claimed right away.
  • Didn't make screenshot of this, though it is easy to test with the first settler when starting a new game.
• It is not possible to settle in foreign land.
• I tried settling a city one tile away from my capital city (changed another global to remove the city distance restriction just for this test).
  • The new city could the turn it was founded work the center tile and four other tiles that was previously claimed by the capital city.
  • Attachments illustrate this point.

View attachment 512310 View attachment 512311

There are probably redundancies elsewhere to address this if it were to fail, such as later enforcing that if the city doesn't own its own tile then that's a problem and it must be changed immediately. There's also no claiming of the surrounding tiles in this initial establishment of having culture on them. That would be later in the code. You can claim a tile but it isn't really yours or your city's to work unless you also own the tile. You don't own the tile unless you have your culture in it and have more culture in it than any other competitor.

Ok, so apparently it is unacceptable to some players that the city would only start with its own tile for even the first round because too often those players go into the city immediately to force which tile it works right away and they don't wish to have to remember to do it the next round. So I'll have to do something more like what you had expressed in code.

 

[Toffer90]

Ok, so apparently it is unacceptable to some players that the city would only start with its own tile for even the first round because too often those players go into the city immediately to force which tile it works right away and they don't wish to have to remember to do it the next round.

That's a good argument.

 

[Thunderbrd]

The line pPlot->setOwner(getOwnerINLINE(), bBumpUnits, false); shortcuts the absolute need for culture in the plot where the city is initialized. I'm not sure why they wanted to ensure a culture level in that plot but it might be for the benefit of later ownership validation checks.

EDIT: I just realized the bBumpUnits bool in use there - this must be also a channel for the process that kicks out non-new-owner units. That would be of fair importance. And to do that properly, it might need a little culture there.

For that reason as well, the FREE_CITY_ADJACENT_CULTURE coding should just be conditionally switched to a value of 0 IF the game option is on but otherwise the rest of the code lines should remain there. Gotta be careful with unintended consequences of some changes so it's often best to preserve as much as possible because you never know the tripwires you might be setting off in the future and debugging becomes a lot more irritating when you find yourself re-installing code you killed thinking it would be an innocent slaying - particularly when you could've gone about it in a less brutal manner. Saving a few lines of code often isn't worth the risk and a global is not much memory either.

There IS a slight slowdown depending on the method used, for calling for a global - and if you use the other method then it does allocate more memory so it should be done when it's going to call that global commonly. This is a fairly infrequent call. Shouldn't be noticeable either way.

 

[Toffer90]

EDIT: I just realized the bBumpUnits bool in use there - this must be also a channel for the process that kicks out non-new-owner units. That would be of fair importance. And to do that properly, it might need a little culture there.

Are you sure, it doesn't make sense to me that the rules for that would be based on plot culture values when it is far more universal to base it on plot ownership regardless of what the culture values are in numbers...

 

[Thunderbrd]

Are you sure, it doesn't make sense to me that the rules for that would be based on plot culture values when it is far more universal to base it on plot ownership regardless of what the culture values are in numbers...

I'm not 100% sure no but it's not worth eliminating that bit of code. There's no gain in it. However, plot ownership is likely validated BY culture values, regardless of how it is established. Let's put it this way, without spending hours poring over code, there's the general rule here to assume that if the original programmers put this stuff there, there's a reason they did. I'm guessing as to what those reasons could be, sure, but I'm sure there's a reason because so far as I've seen, the firaxis team never did anything without a cause - might disagree with that cause at some point but there was always a cause.

 

[Toffer90]

You know me, tenacity itself, I don't like leaving any stone unturned. ^^

 

[Thunderbrd]

I can't set the Status Stay the Hand on my regular military units (Stone Axeman, Atlastist, Slinger) anymore. It worked in an earlier SVN version but I can't tell which update caused it to disappear. It's surely a recent change. It still works for my Hunters and Ambushers.

Edit: SVN 10321

Edit2: I think it was before SVN 10316. I think the bug was there today in my test game. I started my main game on SVN 10299 and I think I used this status in my game earlier so It happened after that but I'm not entirely sure. Unless I screwed up my game by downgrading to 10316 from 10319 and it caused the problem on my system.

I researched this and have found that the bug is a lack of a display line on a special prerequisite that Stay the Hand has. I'm rectifying that now but soon it will clearly have a line in the description that states:
Only units that have some natural invisibility ability can select this promotion.

This has been a feature of this promo for a while but was never really shared with the player. It may not have been when the promotion was initially created.

 

[Thunderbrd]

You know me, tenacity itself, I don't like leaving any stone unturned. ^^

No fault in it - keep looking to find out why if you wish but I'm thinking it could be in a lot of possible places and thus could soak a lot of time to try to figure it out.

 

[Morlark]

This may be not a bug at all, but I thought I'd ask:

I attacked a Malinese city with my ambushers, and they captured the city. But because ambushers have hidden nationality, the city was actually captured by the barbarian civ. Within that same turn, I then took control of the city with my normal units. However, the city did not retain its original African culture building like it normally does. Instead it just got my European culture. The "(Mali)" designator also disappeared from by the city name. I'm assuming this is because the game bases that on the city's most recent owner instead of its original owner. Is this intended?

I'm thinking there may be potential for unintended consequences there. Like, if you let an enemy civ conquer one of your cities, then subsequently retake the city, do you really get the enemy's culture building, even though it doesn't really make thematic sense to imagine that their culture would have permeated into the city in such a short time? Seems like it could be an exploity way to acquire foreign cultures.

 

[Thunderbrd]

I'm assuming this is because the game bases that on the city's most recent owner instead of its original owner. Is this intended?

Close. Barbs are a special case that erase the culture in the city when they take it.

 

[Morlark]

Ok, fair enough. I was just a little confused, because the city still showed "(Mali)" by the name while the barbarians owned it.

 

[Thunderbrd]

Ok, fair enough. I was just a little confused, because the city still showed "(Mali)" by the name while the barbarians owned it.

Yeah, they'll keep it but when you take it from them it loses it. At least that's what I remember from when this was brought up. However, if you're actually correct, which you might be, and you can reliably exploit in that manner, then by all means go for it. It's not a bug I'm going to seek to fix because I eventually plan a slightly different culture method and trying to take time to fix this would thus become a discarded effort.

 

[DC0]

SVN 10326
Presumably after v.10319 update several Inca city names now look like: TXT_KEY_CITY_NAME_MACHU.
I've applied update to ongoing game. Cache was cleared before update.

 

[raxo2222]

SVN 10326
Presumably after v.10319 update several Inca city names now look like: TXT_KEY_CITY_NAME_MACHU.
I've applied update to ongoing game. Cache was cleared before update.

I guess @Toffer90 forgot to add actual names somewhere along lines.

 

[Toffer90]

SVN 10326
Presumably after v.10319 update several Inca city names now look like: TXT_KEY_CITY_NAME_MACHU.
I've applied update to ongoing game. Cache was cleared before update.

Hmm, I didn't realize that removing or changing any of those tags would cause cities that is already founded to loose their name.
Seems my last TXT_Change wasn't 100% save game compatible, all new cities will get the correct name, but a city that already has a name will keep referencing the TXT_KEY it originally used when the city was founded, I thought it saved the string in the save after fetching it from the XML instead of saving the TXT_KEY type string in the save.

Now I'm wondering if I should revert the TXT_KEY names of the XML entries back to what they were even though they now don't match the actual names at all in many cases...
Or if I should add in a lot of dummy text XML entries that will never be used in new games but will be used in games played before that SVN rev I recently committed...
Or if I should just let it go... people can rename their cities manually in those old saves..

What do others think about it?

 

[Toffer90]

No fault in it - keep looking to find out why if you wish but I'm thinking it could be in a lot of possible places and thus could soak a lot of time to try to figure it out.

You made a mistake in your commit regarding the FREE_CITY_ADJACENT_CULTURE usage.

Spoiler Current code :

    if (GC.getGameINLINE().isOption(GAMEOPTION_1_CITY_TILE_FOUNDING))
    {
        int iAdjCulture = GC.getDefineINT("FREE_CITY_ADJACENT_CULTURE");
        for (iI = 0; iI < NUM_DIRECTION_TYPES; iI++)
        {
            pAdjacentPlot = plotDirection(getX_INLINE(), getY_INLINE(), ((DirectionTypes)iI));

            if (pAdjacentPlot != NULL)
            {
                if (pAdjacentPlot->getCulture(getOwnerINLINE()) < iAdjCulture)
                {
                    pAdjacentPlot->setCulture(getOwnerINLINE(), iAdjCulture, bBumpUnits, false);
                }
                pAdjacentPlot->updateCulture(bBumpUnits, false);
            }
        }
    }

Now it is:
When 1CTF add free culture to plots around new city.

It should be the opposite like I showed in my suggested code.
When not 1CTF add free culture to plots around new city.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Also I would prefer:

if (pAdjacentPlot->getOwnerINLINE() == NO_PLAYER)​

instead of this:

if (pAdjacentPlot->getCulture(getOwnerINLINE()) < iAdjCulture)​

So that the culture is only added to neutral plots, and not added to plots owned by other players.
Then that code does only what it is meant to do, claiming the neutral land in the first rung around the city the moment it is founded.

 

[Thunderbrd]

You made a mistake in your commit regarding the FREE_CITY_ADJACENT_CULTURE usage.

Spoiler Current code :

    if (GC.getGameINLINE().isOption(GAMEOPTION_1_CITY_TILE_FOUNDING))
    {
        int iAdjCulture = GC.getDefineINT("FREE_CITY_ADJACENT_CULTURE");
        for (iI = 0; iI < NUM_DIRECTION_TYPES; iI++)
        {
            pAdjacentPlot = plotDirection(getX_INLINE(), getY_INLINE(), ((DirectionTypes)iI));

            if (pAdjacentPlot != NULL)
            {
                if (pAdjacentPlot->getCulture(getOwnerINLINE()) < iAdjCulture)
                {
                    pAdjacentPlot->setCulture(getOwnerINLINE(), iAdjCulture, bBumpUnits, false);
                }
                pAdjacentPlot->updateCulture(bBumpUnits, false);
            }
        }
    }

Now it is:
When 1CTF add free culture to plots around new city.

It should be the opposite like I showed in my suggested code.
When not 1CTF add free culture to plots around new city.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Also I would prefer:

if (pAdjacentPlot->getOwnerINLINE() == NO_PLAYER)​

instead of this:

if (pAdjacentPlot->getCulture(getOwnerINLINE()) < iAdjCulture)​

So that the culture is only added to neutral plots, and not added to plots owned by other players.
Then that code does only what it is meant to do, claiming the neutral land in the first rung around the city the moment it is founded.

No difference. If theres existing culture then 1 pt is insignificant. Ill fix the error anyhow.

 

[raxo2222]

Why AIs don't improve resources outside of vicinity range @Thunderbrd ?
This happens too frequently.
In this Blitz/Nightmare/Tiny test largest AI doesn't have copper because it doesn't have improvement on copper ore.
This means no electricity (doesn't import copper stuff from other AIs) and it has largest empire.
Smaller AI is industrial era and it has copper.
It banned Slavery, so it builds factories.

Spoiler :

 

[Thunderbrd]

Why AIs don't improve resources outside of vicinity range @Thunderbrd ?
This happens too frequently.
In this Blitz/Nightmare/Tiny test largest AI doesn't have copper because it doesn't have improvement on copper ore.
This means no electricity (doesn't import copper stuff from other AIs) and it has largest empire.
Smaller AI is industrial era and it has copper.
It banned Slavery, so it builds factories.

Spoiler :

View attachment 512382 View attachment 512383

They probly do eventually just not as high priority as other tasks. If they need the resource they should make it a higher.