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

[Toffer90]

Some more thoughts:

The option is pretty much the opposite of GAMEOPTION_ANIMALS_STAY_OUT.
One of them has to disable the other if both are used in a game. This should be explained in the tooltip for the one that disables the other; or for both.

Some animals should still be able to spawn within cities with GAMEOPTION_DANGEROUS_WILDLIFE active.

Spoiler Possible part of dll implementation :

bool CvUnit::canAnimalIgnoresBorders() const
{
    if GC.getGameINLINE().isOption(GAMEOPTION_DANGEROUS_WILDLIFE)
    {
        return true;
    }
    if (!GC.getGameINLINE().isOption(GAMEOPTION_ANIMALS_STAY_OUT) && mayAnimalIgnoresBorders())
    {
        return true;
    }
    return false;
}

bool CvUnit::canAnimalIgnoresImprovements() const
{
    if GC.getGameINLINE().isOption(GAMEOPTION_DANGEROUS_WILDLIFE)
    {
        return true;
    }
    if !GC.getGameINLINE().isOption(GAMEOPTION_ANIMALS_STAY_OUT)
    {
        int iAnswer = m_pUnitInfo->canAnimalIgnoresBorders();
        iAnswer += getAnimalIgnoresBordersCount();
        return (iAnswer > 1);
    }
    return false;
}

bool CvUnit::canAnimalIgnoresCities() const
{
    if (!GC.getGameINLINE().isOption(GAMEOPTION_ANIMALS_STAY_OUT))
    {
        int iAnswer = m_pUnitInfo->canAnimalIgnoresBorders();
        iAnswer += getAnimalIgnoresBordersCount();
        return (iAnswer > 2);
    }
    return false;

bool CvSpawnInfo::getNeutralOnly()
{
    if (GC.getUnitInfo(getUnitType()).isWildAnimal() && GC.getGameINLINE().isOption(GAMEOPTION_DANGEROUS_WILDLIFE))
    {
        return false;
    }
    return m_bNeutralOnly;
}
}

 

[Thunderbrd]

Some more thoughts:

The option is pretty much the opposite of GAMEOPTION_ANIMALS_STAY_OUT.
One of them has to disable the other if both are used in a game. This should be explained in the tooltip for the one that disables the other; or for both.

Some animals should still be able to spawn within cities with GAMEOPTION_DANGEROUS_WILDLIFE active.

Spoiler Possible part of dll implementation :

bool CvUnit::canAnimalIgnoresBorders() const
{
    if GC.getGameINLINE().isOption(GAMEOPTION_DANGEROUS_WILDLIFE)
    {
        return true;
    }
    if (!GC.getGameINLINE().isOption(GAMEOPTION_ANIMALS_STAY_OUT) && mayAnimalIgnoresBorders())
    {
        return true;
    }
    return false;
}

bool CvUnit::canAnimalIgnoresImprovements() const
{
    if GC.getGameINLINE().isOption(GAMEOPTION_DANGEROUS_WILDLIFE)
    {
        return true;
    }
    if !GC.getGameINLINE().isOption(GAMEOPTION_ANIMALS_STAY_OUT)
    {
        int iAnswer = m_pUnitInfo->canAnimalIgnoresBorders();
        iAnswer += getAnimalIgnoresBordersCount();
        return (iAnswer > 1);
    }
    return false;
}

bool CvUnit::canAnimalIgnoresCities() const
{
    if (!GC.getGameINLINE().isOption(GAMEOPTION_ANIMALS_STAY_OUT))
    {
        int iAnswer = m_pUnitInfo->canAnimalIgnoresBorders();
        iAnswer += getAnimalIgnoresBordersCount();
        return (iAnswer > 2);
    }
    return false;

bool CvSpawnInfo::getNeutralOnly()
{
    if (GC.getUnitInfo(getUnitType()).isWildAnimal() && GC.getGameINLINE().isOption(GAMEOPTION_DANGEROUS_WILDLIFE))
    {
        return false;
    }
    return m_bNeutralOnly;
}
}

*sigh*
I was wondering when someone would realize that this is so much easier done in the dll with this sort of simple code switch. I was also more about discussing the concerns I have regarding my own soon to be developed optional trait set. Hopefully the replacement mechanism won't find that too much to handle. I can live with it if it doesn't work well for 200+ unit entries though... that WOULD be a tremendous amount of memory.

I'll whip this up right now.

 

[raxo2222]

*sigh*
I was wondering when someone would realize that this is so much easier done in the dll with this sort of simple code switch. I was also more about discussing the concerns I have regarding my own soon to be developed optional trait set. Hopefully the replacement mechanism won't find that too much to handle. I can live with it if it doesn't work well for 200+ unit entries though... that WOULD be a tremendous amount of memory.

I'll whip this up right now.

Well my suggestion was to make it DLL option in beginning.

this is why I tagged DLL modders in my suggestion, as I had suspicion, that things may explode in XML.

 

[Dancing Hoskuld]

this is why I tagged DLL modders in my suggestion, as I had suspicion, that things may explode in XML.

Having the XML "explode" as you put it is not a problem if the dll handles it correctly. In fact it can be an advantage if all you are doing is having a single set for each option. You simply have a separate file for each option so that you can easily compare between options and use copy/paste/change to get new sets (eg a new animal) across all options.

It can also be more flexible allowing modders to swap and change things while they are trying stuff out. Meanwhile having something hard coded in the dll can cause things to become to restrictive.

 

[raxo2222]

Having the XML "explode" as you put it is not a problem if the dll handles it correctly. In fact it can be an advantage if all you are doing is having a single set for each option. You simply have a separate file for each option so that you can easily compare between options and use copy/paste/change to get new sets (eg a new animal) across all options.

It can also be more flexible allowing modders to swap and change things while they are trying stuff out. Meanwhile having something hard coded in the dll can cause things to become to restrictive.

Well this option is meant to make absolutely all animals spawn within borders and even on improved tiles.
So DLL fits it best here.

There may be some more animal/spawn definitions in modules - DLL override catches them all.

There is list of all animals by @Toffer90

 

[Thunderbrd]

Meanwhile having something hard coded in the dll can cause things to become to restrictive.

I believe with this particular option it's better to put the switch in the dll... the coding for it is tremendously simple and will not require updating with new animals added later. I really may have to think of something that's between replacement, option switch and modularity as a third option for setting up options. The problem is, if you want something like a modular solution in terms of actual real replacement of the original data, then it must be determined during the load process (or rather, before.)

When you mentioned it, Raxo, I wasn't touching the coding with a 10' pole. And I do see some added potential benefit to including varying animal definitions under this option but if it's too much, it's good we found a point where we must consider where too much is too much.

 

[Dancing Hoskuld]

I believe with this particular option it's better to put the switch in the dll... the coding for it is tremendously simple and will not require updating with new animals added later. I really may have to think of something that's between replacement, option switch and modularity as a third option for setting up options. The problem is, if you want something like a modular solution in terms of actual real replacement of the original data, then it must be determined during the load process (or rather, before.)

Or before is what MLF does However my suggestion was not about modules per se, but just about how you maintain the XML files. In the same way as we have separated the regular, special and wonder buildings you could have separate files for the different spawn options. In this case though you would be able to use comparison software between the files to keep the bits in sync easier than having them all in one file.

 

[raxo2222]

Or before is what MLF does However my suggestion was not about modules per se, but just about how you maintain the XML files. In the same way as we have separated the regular, special and wonder buildings you could have separate files for the different spawn options. In this case though you would be able to use comparison software between the files to keep the bits in sync easier than having them all in one file.

Is it possible to separate gamespeeds in four files?
First set is normal, second one is for upscaled production, third one is for upscaled research and fourth one is for both upscaled options.

 

[Thunderbrd]

Or before is what MLF does However my suggestion was not about modules per se, but just about how you maintain the XML files. In the same way as we have separated the regular, special and wonder buildings you could have separate files for the different spawn options. In this case though you would be able to use comparison software between the files to keep the bits in sync easier than having them all in one file.

That's a good idea for the sake of organization, yes, but the problem we were having with Rax's first approach was a memory overload due to so many replacements being used, which, as you pointed out, we'd have the same problem with an option switch method. Sadly there's probably not much of a method between the two unless players are expected to manipulate files.

 

[Toffer90]

That's a good idea for the sake of organization, yes, but the problem we were having with Rax's first approach was a memory overload due to so many replacements being used, which, as you pointed out, we'd have the same problem with an option switch method. Sadly there's probably not much of a method between the two unless players are expected to manipulate files.

It might be better to implement the alternative gamespeed options as a simple global define with a dll solution.
Both GAMEOPTION_UPSCALED_RESEARCH_COSTS and GAMEOPTION_UPSCALED_BUILDING_AND_UNIT_COSTS would have their own global define, currently both upscale 40% so the define would be set to 140 for both.

UPSCALED_COST_BEAKER = 140
UPSCALED_COST_HAMMER = 140

In dll when it usually adds gamespeed modifier to research cost it would also do a "if GAMEOPTION_UPSCALED_RESEARCH_COSTS" then multiply by UPSCALED_COST_BEAKER and divide by 100.

Same with anything that cost hammers would the dll when calculating the cost have an "if GAMEOPTION_UPSCALED_BUILDING_AND_UNIT_COSTS" then multiply with UPSCALED_COST_HAMMER and divide by 100.

 

[raxo2222]

It might be better to implement the alternative gamespeed options as a simple global define.
Both GAMEOPTION_UPSCALED_RESEARCH_COSTS and GAMEOPTION_UPSCALED_BUILDING_AND_UNIT_COSTS would have their own global define, currently both upscale 40% so the define would be set to 140 for both.

In dll when it usually adds gamespeed modifier to research cost it would also do a "if GAMEOPTION_UPSCALED_RESEARCH_COSTS" then multiply by the global define designated that option and divide by 100.

Same with anything that cost hammers would the dll when calculating the cost have an "if GAMEOPTION_UPSCALED_BUILDING_AND_UNIT_COSTS" then multiply with aplicable global define and divide by 100.

With Upscaled production costs following things are scaled: iTrainPercent, iConstructPercent, iCreatePercent, iBuildPercent, iImprovementPercent, iFeatureProductionPercent, iUnitHurryPercent

 

[Toffer90]

With Upscaled production costs following things are scaled: iTrainPercent, iConstructPercent, iCreatePercent, iBuildPercent, iImprovementPercent, iFeatureProductionPercent, iUnitHurryPercent

True, GAMEOPTION_UPSCALED_BUILDING_AND_UNIT_COSTS would require far mode dll modifications to work as expected.

At least GAMEOPTION_UPSCALED_RESEARCH_COSTS would be most elegant to hardcode in dll with one global define. It's a bit odd to have 4 sets of gamespeed entries just to accomodate an option that only increases beaker cost of techs by 40%.
2 sets, a few dll code lines and 1 global define makes more sense.

 

[Thunderbrd]

True. I'll address that in a bit.

 

[Silica_Pathways]

Very very likely.

Awesome. Then I will likely just wait for the next big non-SVN release, thanks.

 

[JosEPh_II]

Awesome. Then I will likely just wait for the next big non-SVN release, thanks.

I used to supply Updated Releases for the Official release for Non SVN users (although setting up the SVN to get the latest is Not had to do).

But I don't have a Dropbox or similar account anymore to give a link to. Perhaps one of the other Modders on the Team would feel inclined to do so in my stead? IDK so asking.

 

[DC0]

SVN 10272

Do following buildings exist?

1. Bug cage
2. Bug Enclosure
3. Fox traps

They are in description text for Tarantula and Fennex Fox. But I couldn't find them in Sevopedia in list of buildings.


Volcano text seems to mismatch volcano animations.
When volcano explodes and lava starts to flow, text is "volcano has quieted down".
When volcano sits with no lava flowing, text is "is now erupting and countryside has been devastated".

Build queue now doesn't persist in between saves-loads.
While in city screen, pressing Ctrl+number key should save build queue. It does so for the currently loaded game only.
It used to be saved in between saves-loads, too. It was very convenient.

 

[Septimius]

Newest SVN - I'm seeing 2 gatherers being escorted out in the wilds by 7 story tellers. The gatherers are building roads, the story tellers are possibly going to a city the AI built very far from it's capital at this early stage of the game (still in the first era).
They aren't using the direct route, so it seems more like they're on patrol duty.

I'm also still seeing stacks of crime fighters moving about the AI's territory.

Savegame included.


And another issue. On deity nightmare there are several civs which are basically unplayable due to early unhappiness.

Unless you take a civ with a happiness boost, your city will become unhappy as soon as the common cold hits (usually within a few turns). This means you're producing very little and researching less.

If you start with a civ with negative happiness traits, your city will start out unhappy and once the common cold hits, you will have to play for hundreds of turns to research the necessary stuff to cancel out the negatives.

I'd suggest either removing the unhappiness from the common cold, or set it to come into effect once a city grows to size 2.

It can't be the point of the hardest difficulty to make you start out crippled if you get a civ with negative happiness traits.

 

[DC0]

SVN 10272
Build queue now doesn't persist in between saves-loads.

It seems saved build queue is discarded as soon as a new city is founded.

 

[Noriad2]

@Septimius: Language and Oral tradition give one happiness in each city, although switching to the civic oral tradition removes one again.
Besides, you have your central city square and your Palace which gives 8 commerce. It's not like losing one active pop temporarily will finish you off for good.

 

[Septimius]

@Septimius: Language and Oral tradition give one happiness in each city, although switching to the civic oral tradition removes one again.
Besides, you have your central city square and your Palace which gives 8 commerce. It's not like losing one active pop temporarily will finish you off for good.

You're saying nothing I don't know already.

You've made a lot of changes to the diseases, which are fine, but this one just isn't. Getting to those techs will take you over a hundred turns on the slowest speed, while your building speed is slowed down to a crawl. It makes no sense from a gaming perspective to just basically ruin nigthmare for almost all of the civilizations. I had to pick a happiness boost civ to have a normal game.

You can fix it by raising the common cold to hit at city size 2 or not have it hit from the start of the game. Or remove the unhappiness from it.


Also, just because the "common" cold is common today, it's actually over 200 different viruses that cause it - and it wouldn't have been common at all 200.000 years ago.