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

[Thunderbrd]

But it seems clearMissionQueue has to be called there so I would put it back in and the answer for these problems is in that function.

I would do that except that until its figured out, the but without clearMissionQueue is much more playable with than the one without it.

 

[olduser]

I used the vanilla Stack Attack almost always and don't remember any problems in vanilla BtS or any other mods.

I would do that except that until its figured out, the but without clearMissionQueue is much more playable with than the one without it.

If there was no issue in Bts with Stack Attack the answer has to be somewhere else. It can't be clearMissionQueue or the spot where it was rremoved because it worked in Bts.

 

[Thunderbrd]

With extreme prejudice and care. That's What Peace Among NPCs gives you now.

It strikes me that we need to turn the spawn down on that option. We may have been trying to turn it down and finding we were turning it up. This may also be one of the problems with scaling animal spawns (I don't they should be scaled at all). When you scale them to spawn more on faster games you get a seriously clogged up map on faster gamespeeds and yet a very sparse map on slower ones. This also means that it takes longer to explore on a game where you have less time to do it. I know the argument about having less time to capture animals thus you feel you need more animals to capture, but if it keeps you geologically limited, it actually hinders the ability to capture a wider type array of animals for more myth bonuses by limiting how far out you can hunt. It also causes a lot more unit death as you don't have healing times scaled and thus can get overwhelmed by what would otherwise be fairly minor challenges.

I'm not touching these numbers myself but I welcome some response to these considerations.

I don't think there's anything special about the exile in the animal capture system that would keep them from being capable of it but maybe criminals have a penalty to the effort somehow on the python side DH might have to look at that.

 

[Thunderbrd]

If there was no issue in Bts with Stack Attack the answer has to be somewhere else. It can't be clearMissionQueue or the spot where it was rremoved because it worked in Bts.

BtS didn't have the BUG stack attack, which relies on some interesting methodology. Besides, it's not really Stack Attack options that are having trouble, it's the non-stack attack that is, and it may be due to changes in one of those two wrapup functions so as to debug stack attacks.

There's also a pretty good chance that if we sort this out properly, combat animations will probably naturally start working again without causing crashes here and there.

 

[olduser]

BtS didn't have the BUG stack attack, which relies on some interesting methodology. Besides, it's not really Stack Attack options that are having trouble, it's the non-stack attack that is, and it may be due to changes in one of those two wrapup functions so as to debug stack attacks.

There's also a pretty good chance that if we sort this out properly, combat animations will probably naturally start working again without causing crashes here and there.

If the BUG stack attack mainly has problems the answer has to be in the code that handles that option. Without the clearMissionQueue call attacking a single unit with a single unit doesn't even work correctly and that's something that really should work.

 

[Thunderbrd]

If the BUG stack attack mainly has problems the answer has to be in the code that handles that option. Without the clearMissionQueue call attacking a single unit with a single unit doesn't even work correctly and that's something that really should work.

The thing is that the stack attack option(s) rely on bfinish coming up as being false (in updateCombat) when the combat is actually complete. This then gets caught later by the core update units routine finding things aren't fully resolved then sending the stack again through updatemission (the move isn't yet indicated as complete). Then it cycles back through and makes the next attack. All attacks technically finish one after another after the LAST one is made, which is the point where it becomes ok for bfinish to be true. This whole method makes for a greatly complicated set of conditions.

I think you're right that we can figure out how to MAKE it work. We should probably stop expecting the vanilla processing to work as a perfect template guideline of 'what works' however. Particularly with ambushes also factoring in.

But again, it is much more player-level annoying to have to go hunting back for the stack you're attacking with after each attack puts it to sleep than it is to have to hit the pass button to let go of the unit or stack after an attack.

The beauty of the current situation is that the final and last bug is this. So if we pretty much leave everything alone and just figure out how to conditionally correct this one matter that takes place only on non-stack attack, then we should be good (provided we don't have a problem now with units that withdraw from an ambush as I suspect we might.)

 

[Dancing Hoskuld]

Why do you think it only happens on not stack attack? Or did I miss something and you have a fix for the problem with stack attack and I just have not seen the update on the SVN. Because I am having the problem with stack attack on.

 

[olduser]

With the newest SVN 9990 I get a CTD when waiting for the next turn of the attached savegame, MiniDump is 0 Bytes. With SVN 9986 it runs fine.

This should be fixed now in the svn.

The real reason this CTD is happening is a route having -80 movement but from the current XML this is not possible. It could only come from the Interstate event if that event is fired multiple times because besides XML this is the only other thing that changes route movement cost.

 

[glaucus.b]

SVN9991 CTD in the next turn.

 

[glaucus.b]

SVN9991 forestry upgrade does not work for the warrior.

 

[Snofru1]

Thank you, Albert, at least my CTD is gone!

I can´t remember having an Interstate Event though. Or could it have to do with the Route 66 wonder, I have built that one.

 

[Thunderbrd]

Why do you think it only happens on not stack attack? Or did I miss something and you have a fix for the problem with stack attack and I just have not seen the update on the SVN. Because I am having the problem with stack attack on.

Which stack attack and what exact scenario? 1 unit attacking and advancing? 1 unit attacking without advance (because there's more to attack)? Multiple units selected attacking and advancing? Or multiple units attacking without advance? or other?

I'm also assuming you are saying the problem is where the unit or selection group has held onto being selected when it should've been released and a pass command is required to let go of the selection?

Edit: I see... you're not talking about the BUG stack attack. That's working perfectly at the moment. But one unit attacking one unit does hold onto the selected unit after the battle on core stack attack. The difference between that and the non-stackattack bug is that if you attack with a stack and there are more attackers left over after the advance that haven't attacked and they just move in with the rest of the stack, then the stack loses the selection focus as it should.

 

[Dancing Hoskuld]

Which stack attack and what exact scenario? 1 unit attacking and advancing? 1 unit attacking without advance (because there's more to attack)? Multiple units selected attacking and advancing? Or multiple units attacking without advance? or other?

I'm also assuming you are saying the problem is where the unit or selection group has held onto being selected when it should've been released and a pass command is required to let go of the selection?

Edit: I see... you're not talking about the BUG stack attack. That's working perfectly at the moment. But one unit attacking one unit does hold onto the selected unit after the battle on core stack attack. The difference between that and the non-stackattack bug is that if you attack with a stack and there are more attackers left over after the advance that haven't attacked and they just move in with the rest of the stack, then the stack loses the selection focus as it should.

Moving in with the rest of the stack is fine but loosing selection (and put to "sleep" for turn) when all units still have movement points even the attacker is not. I have not updated from the SVN since Saturday morning my time. I will do so and try it out soon to see if this is still happening. I think I have one barbarian city to go and a stack of chariots to attack it.

 

[olduser]

SVN9991 CTD in the next turn.

Possibly fixed.
I did get a CTD a few turns later when i attacked and destroyed another unit with an Exile.

 

[Thunderbrd]

I have found a fix to our movement problems. There remains just one quirky bug and I've got a pretty good bead on hunting it down. Has to do with a withdrawal when attacking during an ambush but it's even a bit more unique than that - other situations must exist for a bug to take place there. Without going into detail, I think I can fix it. But I'm going to work on that later and get the fixes I have already in place on the SVN first.

Then I welcome all the stress testing y'all can come up with to see if you can find a messed up movement/attack scenario. If you find one, please report with a save.

 

[Thunderbrd]

@Raledon & @Toffer90

The first thing I'd like to request is that we keep some structural standards with if/else and brackets. I find it much cleaner and easier to read code when it follows organization principles.

int CvCity::growthThreshold() const
{
    int iThreshold = GET_PLAYER(getOwnerINLINE()).getGrowthThreshold(getPopulation());
    int iThresholdModifier = (GET_PLAYER(getOwnerINLINE()).getPopulationgrowthratepercentage() + 100);
    int iDivide = 100; //used to reduce possible rounding error, as it's assumed that we won't be near int overflow
   
    iThresholdModifier *= (getPopulationgrowthratepercentage() + 100);
    iDivide *= 100;
   
    if (getNumCityPlots() == NUM_CITY_PLOTS)
    {
       iThresholdModifier *= (100+GC.getDefineINT("CITY_THIRD_RING_EXTRA_GROWTH_THRESHOLD_PERCENT"));
       iDivide *= 100;
    }

    if ( isHominid() )
    {
       iDivide *= 2;    //    Those barbarians are just so damned fecund!
    }

   iThresholdModifier/=iDivide;
   if (iThresholdModifier<1)//we got -food%
   {
       iThresholdModifier -=1; //we want "need -100%" to be -1, not 0
       iThresholdModifier *=-1; //switch sign
       iThreshold/=iThresholdModifier;
   }
   else
   {
       iThreshold*=iThresholdModifier;
   }

    return std::max(1,iThreshold);
}

This is how I would've expressed the code you stated earlier, Raledon. I know it's just picky but if kept to this kind of indentation structure I can read the code much easier, even if it IS legal either way in the compile process.

As for the math... I'm not really sure. With both of your examples I'm getting a bit lost in what we're trying to achieve exactly. My understanding is that the goal is to adjust the formula so that we can be more granular when we get into negative amounts of thresholdmodifier (aka getPopulationgrowthratepercentage from all sources). That it becomes divisional at that point as opposed to just reducing things down to a minimum of 1. Is that right? I suspect the code above is a touch more complex than necessary for that but I will probably need to think it through a lot more than I have.

 

[stachnie]

SVN from 2018-02-27 (I don't know how to check the number).

1. It is impossible to build Yoruba missionaries without making it the State Religion. Appriopriate building is available only when this is the SR (usually some first buildings of religions may be built without SR, this is not the case for Yoruba), and the missionaries cannot be built under Organized Religion (the case for some religions without Monasteries, their missionaries need some special building to be built).

2. How do Aristocrates work? I thought they just increase GP rate without changing the odds. My typical strategy is to get as many Cultures as possible, build all possible Heroes and (after using them to build appriopriate Small Wonders) settle them in my Capital as Aristocrates (to increase GP rate) or, if not available, as Great Generals in my main military city. It seems they just increase the Great Artist probability - in my present game I avoided building most of GA spawning wonders in my Capital (Unlimited Wonders on), settled a lot of Aristocrates and the odds are: 42% Great Artist, 22% Great Prophet etc.

S.

 

[Dancing Hoskuld]

SVN from 2018-02-27 (I don't know how to check the number).

1. It is impossible to build Yoruba missionaries without making it the State Religion. Appriopriate building is available only when this is the SR (usually some first buildings of religions may be built without SR, this is not the case for Yoruba), and the missionaries cannot be built under Organized Religion (the case for some religions without Monasteries, their missionaries need some special building to be built).

That has been fixed recently.

 

[Toffer90]

@Raledon & @Toffer90
As for the math... I'm not really sure. With both of your examples I'm getting a bit lost in what we're trying to achieve exactly. My understanding is that the goal is to adjust the formula so that we can be more granular when we get into negative amounts of thresholdmodifier (aka getPopulationgrowthratepercentage from all sources). That it becomes divisional at that point as opposed to just reducing things down to a minimum of 1. Is that right? I suspect the code above is a touch more complex than necessary for that but I will probably need to think it through a lot more than I have.

Hmm, so he want threshold reductions to act differently from threshold increases, I initially though Raledon's suggestion was only about reducing rounding errors. With that in mind I would have written it like this:

int CvCity::growthThreshold() const
{
    int iThreshold = GET_PLAYER(getOwnerINLINE()).getGrowthThreshold(getPopulation());
    int iDenominator = 1;
    int iNumerator = 1;
    int iThresholdModifier = GET_PLAYER(getOwnerINLINE()).getPopulationgrowthratepercentage();

    if ( iThresholdModifier < 0 )
    {
        iDenominator *= iThresholdModifier * -1 + 100;
        iNumerator *= 100
    }
    else if ( iThresholdModifier > 0 )
    {
        iNumerator *= iThresholdModifier + 100;
        iDenominator *= 100;
    }
    iThresholdModifier = getPopulationgrowthratepercentage();

    if ( iThresholdModifier < 0 )
    {
        iDenominator *= iThresholdModifier * -1 + 100;
        iNumerator *= 100
    }
    else if ( iThresholdModifier > 0 )
    {
        iNumerator *= iThresholdModifier + 100;
        iDenominator *= 100;
    }
    if (getNumCityPlots() == NUM_CITY_PLOTS)
    {
        iThresholdModifier = GC.getDefineINT("CITY_THIRD_RING_EXTRA_GROWTH_THRESHOLD_PERCENT");

        if ( iThresholdModifier < 0 )
        {
            iDenominator *= iThresholdModifier * -1 + 100;
            iNumerator *= 100
        }
        else if ( iThresholdModifier > 0 )
        {
            iNumerator *= iThresholdModifier + 100;
            iDenominator *= 100;
        }
    }
    if ( isHominid() )
    {
        iDenominator *= 2;    //    Those barbarians are just so damned fecund!
    }
    iThreshold *= iNumerator / iDenominator

    return std::max(1,iThreshold);
}

I know it looks a bit scarier, but it isn't all that difficult to grasp what is done mathematically.
I check if the modifiers are below 0 right away while Raledon multiply all the modifiers together and then check if the result is below 0.
I found the possible flip flopping between negative and positive value for the iThresholdModifier as somewhat confusing. ^^

This line is the only place where a rounding error would occur: iThreshold *= iNumerator / iDenominator

In Raledon's initial example there was two rounding error spots:
iThresholdModifier /= iDivide;
iThreshold /= iThresholdModifier;

 

[Cyrus317]

VERY new to C2C, and even newer to the SVN. I apologize if this has been covered elsewhere.

I just installed the SVN, and I'm missing the entire screen wrap. What I mean by this is, I can ONLY see the map and its contents. All buttons, information fields, etc are missing. I seem to recall having this problem once before with another mod, but I cannot seem to remember what the fix was. Can anyone tell me what option I've enabled or disabled that has left me with this problem?

For clarification purposes, the top is my C2C game. The bottom is a standard Civ game.