Single Player bugs and crashes v35 plus (SVN) - After the 18th of August 2014

I have thought that we should make the tech Fire Making require the wonder building Captured Fire. Just so everyone gets that golden age. I specifically don't get that tech until after I have built the wonder and about the time I settle my 5th or 6th city.
In my civic modmod I made all early fire related buildings such as fire pit, smoke signal imu, bonfire, branding hut, etc. require the NW "Captured Fire" OR "Fire Making" Tech. This, together with a higher culture bonus from the NW, makes the captured fire a much more attractive building to make early. Fire pit is no longer given free to all cities when captured fire is built. I think it's a good idea.
 
I get the commit box up asking what I want to commit. I type in the reason for the commit and press enter. It asks for my password and then fails.

I would suggest that you go to your Sourceforge account and edit your profile by making a New password. That is what I did when I did a new checkout because I had updated to SVN 8610 during SF's time of trouble. And that commit and subsequent update were not saved by SF. Their saving of data stopped at our 8609 version. I don't know Why I needed to change passwords but it worked.

JosEPh
 
I would suggest that you go to your Sourceforge account and edit your profile by making a New password. That is what I did when I did a new checkout because I had updated to SVN 8610 during SF's time of trouble. And that commit and subsequent update were not saved by SF. Their saving of data stopped at our 8609 version. I don't know Why I needed to change passwords but it worked.

JosEPh

I'll give it a try.
 
@DLL Modders:
Assistance needed!

I have a minidump that shows a crash at the last line of the following:
Code:
// Returns true if attack was made...
bool CvSelectionGroup::groupAttack(int iX, int iY, int iFlags, bool& bFailedAlreadyFighting)
{
	PROFILE_FUNC();

/************************************************************************************************/
/* DCM                                     04/19/09                                Johny Smith  */
/************************************************************************************************/
	// Dale - SA: Stack Attack START
	if (GC.isDCM_STACK_ATTACK())
	{
		return groupStackAttack(iX, iY, iFlags, bFailedAlreadyFighting);
	}
	// Dale - SA: Stack Attack END
/************************************************************************************************/
/* DCM                                     END                                                  */
/************************************************************************************************/

/************************************************************************************************/
/* RevolutionDCM                               04/19/09                           Glider1       */
/************************************************************************************************/
	// RevolutionDCM - attack support
	CvPlot* pOrigPlot = plot();
	CLLNode<IDInfo>* pUnitNode;
	CvUnit* pLoopUnit;
	CvPlot* pDestPlot = GC.getMapINLINE().plotINLINE(iX, iY);
	// RevolutionDCM - end
/************************************************************************************************/
/* RevolutionDCM                               END                                Glider1       */
/************************************************************************************************/

	if (iFlags & MOVE_THROUGH_ENEMY)
	{
		if (generatePath(plot(), pDestPlot, iFlags))
		{
			pDestPlot = getPathFirstPlot();
		}
	}


	FAssertMsg(pDestPlot != NULL, "DestPlot is not assigned a valid value");

	bool bStack = (isHuman() && ((getDomainType() == DOMAIN_AIR) || GET_PLAYER(getOwnerINLINE()).isOption(PLAYEROPTION_STACK_ATTACK)));
    
	bool bAttack = false;
	bFailedAlreadyFighting = false;

	if (getNumUnits() > 0)
	{
		if ((getDomainType() == DOMAIN_AIR) || (stepDistance(getX(), getY(), pDestPlot->getX_INLINE(), pDestPlot->getY_INLINE()) == 1))
		{
The wierd thing is that pDestPlot is coming up as -1 x and -1 y. This is happening, apparently, because the call is made at the last line here:
Code:
bool CvSelectionGroup::continueMission(int iSteps)
{
	PROFILE_FUNC();

	CvUnit* pTargetUnit;
	bool bDone;
	bool bAction;
	bool bFailed;
	CLLNode<MissionData>* headQueueNode = headMissionQueueNode();

	FAssert(!isBusy());
	FAssert(headQueueNode != NULL);
	FAssert(getOwnerINLINE() != NO_PLAYER);

	if (getActivityType() == ACTIVITY_AWAKE)
	{
		return false;
	}

	FAssert(getActivityType() == ACTIVITY_MISSION);

	if (headQueueNode == NULL)
	{
		// just in case...
		setActivityType(ACTIVITY_AWAKE);
		return false;
	}

	bDone = false;
	bAction = false;
	bFailed = false;

	if (headQueueNode->m_data.iPushTurn == GC.getGameINLINE().getGameTurn() || (headQueueNode->m_data.iFlags & MOVE_THROUGH_ENEMY))
	{
		if (headQueueNode->m_data.eMissionType == MISSION_MOVE_TO && canAllMove())
		{
			bool bFailedAlreadyFighting;
			if (groupAttack(headQueueNode->m_data.iData1, headQueueNode->m_data.iData2, headQueueNode->m_data.iFlags, bFailedAlreadyFighting))
			{
And where headQueueNode is defined in this line:

CLLNode<MissionData>* headQueueNode = headMissionQueueNode();

headMissionQueueNode() is coming up as getElapsedGameTurns(void) when you hover over it in the minidump debug mode.

Exceedingly odd and highly common to get this crash. Any ideas why this may be happening where headMissionQueueNode() somehow refers to getElapsedGameTurns(void)? The last time I saw something like this a clean compile was the trick to keeping it from taking place. This is happening on a clean compile.

Again... very odd. May also explain some other strange stuff taking place.

Ok, made a breakthrough or two here tonight but it's still strange. I protected the code from a crash here by making the unit with any kind of move command wake up if its moving to an x or y of -1 (invalid location). What this did was create some oddness but it did 3 interesting things.

1st, it protected against the crash successfully.
2nd, the unit wakes up but it makes it hard to select any units ... they're frozen in a woken state and even selecting other units can only allow a brief selection of the units before the selection of those units is lost. However, I COULD still successfully select a unit by selecting it from the city screen. Once selecting the frozen units, I could wake them and pass their turns and once all frozen units were passed, the red button became available (otherwise it was stuck on a green button with no unit selected!)
3rd, it pointed out the units causing trouble. So far it's purely, strangely enough, FEMALE MISSIONARIES! So there's a specific problem with female missionaries somewhere and I haven't looked deeply yet but I haven't discovered why they cause problems. They're the only units in C2C not using the default unit type for their unitclass so perhaps that has something to do with creating a problem with function references somehow. This could suggest that the problem is in the coding for unit class-unit type references, not the unit xml itself.


I found another odd problem that the code was handling ok but was still wrong in improvement processing but that's a different issue entirely I believe.
 
3rd, it pointed out the units causing trouble. So far it's purely, strangely enough, FEMALE MISSIONARIES! So there's a specific problem with female missionaries somewhere and I haven't looked deeply yet but I haven't discovered why they cause problems. They're the only units in C2C not using the default unit type for their unitclass so perhaps that has something to do with creating a problem with function references somehow. This could suggest that the problem is in the coding for unit class-unit type references, not the unit xml itself.

I made some changed to the Python code for female missionaries a week or two ago. I was fed up with them not going to the rally point of the city if it had one. I added the following code:-
Code:
				else:
					rallyPlot = city.getRallyPlot()
					[COLOR="Red"][B]if not (rallyPlot == None):[/B][/COLOR]
						pFemaleUnit.getGroup().pushMission(MissionTypes.MISSION_MOVE_TO, rallyPlot.getX(), rallyPlot.getY(), 0, False, True, MissionAITypes.NO_MISSIONAI, pFemaleUnit.plot(), pFemaleUnit)

However in game they still seem to be trying to move to a rally point when there is none! Perhaps I have the wrong test? They are moving to the rally point if there is one. I could check the actual plot is not (-1, -1) instead of None...

edit It should probably be
Code:
					rallyPlot = city.getRallyPlot()
					[B][COLOR="Red"]if rallyPlot.getX() > -1 and rallyPlot.getY() > -1:[/COLOR][/B]
						pFemaleUnit.getGroup().pushMission(MissionTypes.MISSION_MOVE_TO, rallyPlot.getX(), rallyPlot.getY(), 0, False, True, MissionAITypes.NO_MISSIONAI, pFemaleUnit.plot(), pFemaleUnit)

edit 2 I have tested that change and everything works better. Can someone put the attached on the SVN in Python/DancingHoskuld
 
@DH,

So the password reset didn't work?

If it didn't then 1 last suggestion and I'm out of ideas; switch the ssh+svn: to https: for the url.

EDIT: Python file committed to SVN.
JosEPh
 
If i have an animal send to my capital city then the option "Add the tale to your cultural heritage" (This option works only with some animals like the aurochs) should give a cultural and sience boot but displays as commerce and cultural boost. Bug?
 
@DH,

So the password reset didn't work?

If it didn't then 1 last suggestion and I'm out of ideas; switch the ssh+svn: to https: for the url.

EDIT: Python file committed to SVN.
JosEPh

I have not had chance. The specialist keeps sending me off for more tests rather than getting on with the surgery. I am going to my GP today to find out why.

If i have an animal send to my capital city then the option "Add the tale to your cultural heritage" (This option works only with some animals like the aurochs) should give a cultural and sience boot but displays as commerce and cultural boost. Bug?

Different animals should provide different results but from that option but they should all be giving culture with some of them providing commerce depending on buildings in the city. I was going to check all those in the last review and make them scale with map size and game speed but did not get to most of them.
 
I made some changed to the Python code for female missionaries a week or two ago. I was fed up with them not going to the rally point of the city if it had one. I added the following code:-
Code:
				else:
					rallyPlot = city.getRallyPlot()
					[COLOR="Red"][B]if not (rallyPlot == None):[/B][/COLOR]
						pFemaleUnit.getGroup().pushMission(MissionTypes.MISSION_MOVE_TO, rallyPlot.getX(), rallyPlot.getY(), 0, False, True, MissionAITypes.NO_MISSIONAI, pFemaleUnit.plot(), pFemaleUnit)

However in game they still seem to be trying to move to a rally point when there is none! Perhaps I have the wrong test? They are moving to the rally point if there is one. I could check the actual plot is not (-1, -1) instead of None...

edit It should probably be
Code:
					rallyPlot = city.getRallyPlot()
					[B][COLOR="Red"]if rallyPlot.getX() > -1 and rallyPlot.getY() > -1:[/COLOR][/B]
						pFemaleUnit.getGroup().pushMission(MissionTypes.MISSION_MOVE_TO, rallyPlot.getX(), rallyPlot.getY(), 0, False, True, MissionAITypes.NO_MISSIONAI, pFemaleUnit.plot(), pFemaleUnit)

edit 2 I have tested that change and everything works better. Can someone put the attached on the SVN in Python/DancingHoskuld
Cool!

Great debugging teamwork! However, I must ask... why is it necessary to give the female missionaries any python based AI at all? Isn't it enough to give them the missionary AI?
 
Cool!

Great debugging teamwork! However, I must ask... why is it necessary to give the female missionaries any python based AI at all? Isn't it enough to give them the missionary AI?

You don't build female missionaries, you sometimes get them instead of male ones. Which means removing the male one and placing a female one. This is done in python. When you do the placement you need to give it the orders that the male one had as well as the missionary AI; IE automate them if the automate missionary option is on and send them to the city rally point if it has one.

My mistake was in assuming that the code that returned the rally point would return a null plot rather than an illegal plot which is what it actually does.
 
Experiencing a great increase in EoT processing since updating from SVN 8616. Current SVN used is 8657. EoT has increased to over 7-10 minutes from ~ 2 min or less with SVN 8616.

Edit: Has stabilized at ~2-3 minutes for EoT. Last night (8/28/15) had a CTD After EoT After pop up window for Great Artist Apelles was closed (clicked Close button and instantly to desktop). Had desktop Error pop up:
Failed to allocate video memory Please try reducing graphics settings
File \main\Civilization4\SDKs\Gamebryo2_0\CoreLibs\NiDX9Renderer\NiDX(SourceTextureData.cpp, Line:321.

Was able to continue by loading Autosave.

@alberts2 or T-brd, either of you guys checking in here for CTD reports?


JosEPh
 
Minidump attached for above post CTD after GA pop up for Apelles closed.

JosEPh
 
Experiencing a great increase in EoT processing since updating from SVN 8616. Current SVN used is 8657. EoT has increased to over 7-10 minutes from ~ 2 min or less with SVN 8616.

Edit: Has stabilized at ~2-3 minutes for EoT. Last night (8/28/15) had a CTD After EoT After pop up window for Great Artist Apelles was closed (clicked Close button and instantly to desktop). Had desktop Error pop up:
Failed to allocate video memory Please try reducing graphics settings
File \main\Civilization4\SDKs\Gamebryo2_0\CoreLibs\NiDX9Renderer\NiDX(SourceTextureData.cpp, Line:321.

Was able to continue by loading Autosave.

@alberts2 or T-brd, either of you guys checking in here for CTD reports?


JosEPh

Minidump attached for above post CTD after GA pop up for Apelles closed.

JosEPh

Thanks for the mini... should be easier to work with that since you have local file differences. If the turn times came back down a bit but not as low as it was, that tells me that what I tried to do to re-optimize after 'fixing' game rules with buildups did work to an extent but I'll have to keep looking for more ways to optimize. I figure there probably is some.
 
Both of those minidumps have 0 size. This means maf.

I've isolated what may be a fix but it's going to be tough to make sure of that.

Then again if it's a memory leak from a bad graphic that's not something I can resolve but to fix the graphic may do so easily.
 
In the combat odds mouseover, defender retreat %age appears to be taken out of defeat odds rather than victory odds. Eg. ambusher attacks explorer, odds are shown as 53% victory, 0% defeat, 7.8% retreat, 46.1% defender retreat. Whereas the victory odds should be considerably lower because of the defender retreat, whereas the defeat odds are above 40%
 
Back
Top Bottom