Single Player bugs and crashes v37 plus (SVN) - After the 24th of December 2016

[strategyonly]

Am STILL getting this python error when i try to use a subdued cow on an open area for a "resource"

Traceback (most recent call last):

File "CvRandomEventInterface", line 9545, in doBuildCowBonusAndPasture

AttributeError: 'CyUnit' object has no attribute 'setImprovementType'
ERR: Python function doBuildCowBonusAndPasture failed, module CvRandomEventInterface

 

[Thunderbrd]

Am STILL getting this python error when i try to use a subdued cow on an open area for a "resource"

Traceback (most recent call last):

File "CvRandomEventInterface", line 9545, in doBuildCowBonusAndPasture

AttributeError: 'CyUnit' object has no attribute 'setImprovementType'
ERR: Python function doBuildCowBonusAndPasture failed, module CvRandomEventInterface

@DH or Toffer: Is there something I need to do in the dll to correct this do you think or is this all python side?

 

[Toffer90]

Ok so we are in
<UnitInfo>

<Class>UNITCLASS_SUBDUED_COW</Class>
<Type>UNIT_SUBDUED_COW</Type>​

                        <Outcome>
                            <OutcomeType>OUTCOME_BUILD_DOMESTICATED_HERD_WITH_PASTURE</OutcomeType>
                            <iChance>100</iChance>
                            <PlotCondition>
                                <Greater>
                                    <Python>canBuildCowBonusAndPasture</Python>
                                    <Constant>0</Constant>
                                </Greater>
                            </PlotCondition>
                            <PythonCallback>doBuildCowBonusAndPasture</PythonCallback>
                        </Outcome>

The python function doBuildCowBonusAndPasture(argsList) seems to assume that it is getting a specific plot as a function argument, when it is really getting the unit info for any UNIT_SUBDUED_COW.
It is then trying to use plot methods on a unit, resulting in the malfunction.
The function canBuildCowBonusAndPasture(argsList) that is called by the <PlotCondition> is getting a specific plot as an argument.

A possible solution might be if canBuildCowBonusAndPasture could store which plot it is getting in a global python variable and then the doBuildCowBonusAndPasture could use that, perhaps...

It would probably be better to solve it on the dll side.
In CvOutcomeMission.cpp :
I think this is where the dll gives a plot to the canBuild function:
--------------------------------------------
isPossible(CvUnit* pUnit, bool bTestVisible)

...
if (m_pPlotCondition)

if (!m_pPlotCondition->evaluate(pUnit->plot()->getGameObject()))​

--------------------------------------------

And this is where a unit is given as the argument to doBuild:
--------------------------------------------
execute(CvUnit* pUnit)

...
getOutcomeList()->execute(*pUnit);​

--------------------------------------------
Since the unit info is probably used by some of the mission functions I would suggest to just add in a second argument for the plot.

 

[Noriad2]

I see a theory that can be had in evaluating this minidump but it would be much more helpful if I could catch this in process. Do you have a save?

Hi Thunderbrd,

I tried the last 6 saves before the minidump, and played them at least 5 turns each. The 6th save did crash on the third turn after loading, but doing the same again (twice) did not reproduce the crash.

In short, I have no idea how this crash is triggered or how to reproduce it reliably. Is there anything I can do to test your theory?

P.S. By continually saving, and reloading on each crash as it happened, I eventually went past whatever was the trouble, and thus managed to continue my current campaign.

 

[Thunderbrd]

Hi Thunderbrd,

I tried the last 6 saves before the minidump, and played them at least 5 turns each. The 6th save did crash on the third turn after loading, but doing the same again (twice) did not reproduce the crash.

In short, I have no idea how this crash is triggered or how to reproduce it reliably. Is there anything I can do to test your theory?

P.S. By continually saving, and reloading on each crash as it happened, I eventually went past whatever was the trouble, and thus managed to continue my current campaign.

It has to do with a city attack and a lead unit in a looped through group being non existent when it shouldn't have been possible for it to have been somehow removed from the list before the check that finds it missing. I could read how it happens easier from a save in progress. It's possible that a unit is dying at an odd moment in time that some portion of the code isn't expecting. Probably an AI and the slightest differences in how you play the round could throw the random results into a different sequence thus how you get through.

 

[Thunderbrd]

Ok so we are in
<UnitInfo>

<Class>UNITCLASS_SUBDUED_COW</Class>
<Type>UNIT_SUBDUED_COW</Type>​

                        <Outcome>
                            <OutcomeType>OUTCOME_BUILD_DOMESTICATED_HERD_WITH_PASTURE</OutcomeType>
                            <iChance>100</iChance>
                            <PlotCondition>
                                <Greater>
                                    <Python>canBuildCowBonusAndPasture</Python>
                                    <Constant>0</Constant>
                                </Greater>
                            </PlotCondition>
                            <PythonCallback>doBuildCowBonusAndPasture</PythonCallback>
                        </Outcome>

The python function doBuildCowBonusAndPasture(argsList) seems to assume that it is getting a specific plot as a function argument, when it is really getting the unit info for any UNIT_SUBDUED_COW.
It is then trying to use plot methods on a unit, resulting in the malfunction.
The function canBuildCowBonusAndPasture(argsList) that is called by the <PlotCondition> is getting a specific plot as an argument.

A possible solution might be if canBuildCowBonusAndPasture could store which plot it is getting in a global python variable and then the doBuildCowBonusAndPasture could use that, perhaps...

It would probably be better to solve it on the dll side.
In CvOutcomeMission.cpp :
I think this is where the dll gives a plot to the canBuild function:
--------------------------------------------
isPossible(CvUnit* pUnit, bool bTestVisible)

...
if (m_pPlotCondition)

if (!m_pPlotCondition->evaluate(pUnit->plot()->getGameObject()))​

--------------------------------------------

And this is where a unit is given as the argument to doBuild:
--------------------------------------------
execute(CvUnit* pUnit)

...
getOutcomeList()->execute(*pUnit);​

--------------------------------------------
Since the unit info is probably used by some of the mission functions I would suggest to just add in a second argument for the plot.

hmm... will require some pondering on this.

 

[Dancing Hoskuld]

hmm... will require some pondering on this.

It just needs a check to ensure the plot is not null. If it is null then just leave.

If it is null then the function is not being called correctly and so is not being called from that Outcome. This is a known issue with BtS and event style code. Pepper2000 has the actual Python inside the XML rather than in the CvRandomEventInterface code. Having it there seems to fix what ever it is that is calling random bits of code but having the test for null is as good.

edit the code is already testing for a valid value in Plot which is the first parameter in the call.

 

[Thunderbrd]

A null would probably cause a crash so it probably had to be protected. Obviously something isn't quite right though and I will have to really look it over because this is using AIAndy code and he understands the use of some data storage mechanisms in ways I do not.

 

[Toffer90]

As I said, the function is designed as if it got a plot as the argument input, but it get a unit instead. An error occurs when the function tries to place a pasture on the back of the subdued cow unit. Another error would have occured in the next line when it tries to make the subdued cow pasture unit provide a cow bonus.
It would be cool if this worked and we could get a cow bonus and pasture unit that can move around on the map.
A bit of irony is present in this post.

 

[Dancing Hoskuld]

Except it is working fine for me using the current SVN.

 

[Thunderbrd]

And this is where a unit is given as the argument to doBuild:
--------------------------------------------
execute(CvUnit* pUnit)
...
getOutcomeList()->execute(*pUnit);
--------------------------------------------
Since the unit info is probably used by some of the mission functions I would suggest to just add in a second argument for the plot.

This is incorrect. getOutcomeList()->execute(*pUnit); is calling to:
bool CvOutcomeList::execute(CvUnit &kUnit, PlayerTypes eDefeatedUnitPlayer, UnitTypes eDefeatedUnitType)
which is a much more extensive bit of programming.

If what you say is true, however, which I suspect it is but would not know how to verify since I'm not familiar with python debugging, that

The python function doBuildCowBonusAndPasture(argsList) seems to assume that it is getting a specific plot as a function argument, when it is really getting the unit info for any UNIT_SUBDUED_COW.

then the problem is right there in the python programming where we're not taking the step to get the plot from the plot() function of the unit and using that.

 

[Toffer90]

Except it is working fine for me using the current SVN.

Well, at least in SO's case the python argument was a unit. The problem must be more complex than I first imagined. I don't know why the argument is not always a plot, perhaps the dll sometimes gives it a pointer to a deleted variable in memory which could be any random data that got stored in that memory bit position... Or something of that sort.

 

[Thunderbrd]

Well, at least in SO's case the python argument was a unit. The problem must be more complex than I first imagined. I don't know why the argument is not always a plot, perhaps the dll sometimes gives it a pointer to a deleted variable in memory which could be any random data that got stored in that memory bit position... Or something of that sort.

I'm going to be as much as useless here. We'll need to confer with AIAndy I believe.

 

[Dancing Hoskuld]

I suspect that the problem is that SO has a stack of units with many subdued/tamed cows and it is the second one that is having the problem.

It should not be getting processed at all in this case unlike some other missions which can be applied to multiple units these can only be done to one in a stack.

 

[strategyonly]

I suspect that the problem is that SO has a stack of units with many subdued/tamed cows and it is the second one that is having the problem.

It should not be getting processed at all in this case unlike some other missions which can be applied to multiple units these can only be done to one in a stack.

Nope no stack, just one subdued unit that was at play on a certain "plain" terrain area . . .

 

[Toffer90]

I tried in-game to do the MISSION_BUILD_DOMESTICATED_HERD with a subdued Auroch after having gained Iron Working tech which is needed to trigger the OUTCOME_BUILD_DOMESTICATED_HERD_WITH_PASTURE outcome.
the result was that I got the same error message as SO reported.

I did however add in a

print argsList​

as the first line in the doBuildCowBonusAndPasture(argsList) function.
It reported this.

<CvPythonExtensions.CyUnit object at 0x64E03260>, -1, -1​

I think TB is right that a simple change from this:

pPlot = argsList[0]​

to:

pPlot = argsList[0].plot()​

Will fix the error. I'll test that now.

Edit: yep, that worked just fine, the pasture and bonus got placed in the correct plot without any error messages.

Edit: I also tested what would happen if a stack of subdued Aurochs were selected when performing the mission, and it is working as it should.
Only one Auroch disappeared in exchange for the bonus and improvement.

 

[Thunderbrd]

I tried in-game to do the MISSION_BUILD_DOMESTICATED_HERD with a subdued Auroch after having gained Iron Working tech which is needed to trigger the OUTCOME_BUILD_DOMESTICATED_HERD_WITH_PASTURE outcome.
the result was that I got the same error message as SO reported.

I did however add in a

print argsList​

as the first line in the doBuildCowBonusAndPasture(argsList) function.
It reported this.

<CvPythonExtensions.CyUnit object at 0x64E03260>, -1, -1​

I think TB is right that a simple change from this:

pPlot = argsList[0]​

to:

pPlot = argsList[0].plot()​

Will fix the error. I'll test that now.

Edit: yep, that worked just fine, the pasture and bonus got placed in the correct plot without any error messages.

Edit: I also tested what would happen if a stack of subdued Aurochs were selected when performing the mission, and it is working as it should.
Only one Auroch disappeared in exchange for the bonus and improvement.

Well done!

 

[strategyonly]

have a saved game that does not load, but i went back to another savedgame and is working, so only do IF u have time, thx.

also when did the boats/fishing things change color to BROWN?? pic attached
now they are back to normal .. must have been a glitch

EDIT: Now they are back to brown again,????????

 

[Thunderbrd]

have a saved game that does not load, but i went back to another savedgame and is working, so only do IF u have time, thx.

also when did the boats/fishing things change color to BROWN?? pic attached
now they are back to normal .. must have been a glitch

EDIT: Now they are back to brown again,????????

Not sure about the coloring issue. But the other matter is similar to the previous crash situation. I'm looking into it.

 

[strategyonly]

i believe that the "partisan" stuff is out of whack... they start out at str 60, waaaay above the 20-30 units fighting against them, plus now they are showing up all over the map rather than around the city that was conquered????