Repeat Build Mode

[OrionVeteran]

If you hold down the [ALT]-Key and click on a unit the city will build that unit indefinitely. An asterisk next to the unit in the city queue indicates the city is in Repeat Build Mode for that unit.

What I need to know is how to verify that a city is in repeat build mode. Is there an SDK function out there to determine if a city is currently in repeat build mode?

 

[platyping]

In python, you can check the orderdata.
bSave True means repeat.

 

[OrionVeteran]

For the SDK, the line in red below does not work and I am not sure how to fix it.

bool CvCity::isRepeatProductionUnit() const
{
	CLLNode<OrderData>* pOrderNode = headOrderQueueNode();
	
	if (pOrderNode != NULL)
	{
		if (pOrderNode->m_data.eOrderType == ORDER_TRAIN)
		{
			[COLOR="Red"][B]if (pOrderNode->m_data.bSave)[/B][/COLOR]			
			{
				return true;
			}
		}
	}
	return false;
}

 

[Nightinggale]

if (bFinish && pOrderNode->m_data.bSave)
{
	pushOrder(pOrderNode->m_data.eOrderType, pOrderNode->m_data.iData1, pOrderNode->m_data.iData2, true, false, true);
}

This code is from CvCity:opOrder(). It sure does look like bSave is the indicator for repeated production.

The only thing I can think of is to use the debugger to figure out which of the if statements it considers false.

If you don't like/know how to use the debugger, you can always add

FAssert(false, "A");

Naming the asserts A, B, C.... will tell you which lines are accessed and you will not have to use the debugger.

Do remember to play in window mode if you use either debugger or asserts. Having the screen freeze in full screen mode is no fun.

 

[OrionVeteran]

The only thing I can think of is to use the debugger to figure out which of the if statements it considers false.

The line highlighted in red is where the failure occurs. If that line is excluded, then the function returns true.

 

[Archid]

Just for debugging purposes I would have a look at the m_data.iData1 (UnitType) & m_data.iDate2 (UnitAIType) values and ensure that they are valid and that at iData1 is not -1 (NO_UNIT).

The pushOrder(...) code should be checking that these are valid before it actually adds the item to the queue, but its worth checking as the code itself looks ok.

 

[OrionVeteran]

Just for debugging purposes I would have a look at the m_data.iData1 (UnitType) & m_data.iDate2 (UnitAIType) values and ensure that they are valid and that at iData1 is not -1 (NO_UNIT).

The pushOrder(...) code should be checking that these are valid before it actually adds the item to the queue, but its worth checking as the code itself looks ok.

Adding the following line worked!

if (pOrderNode->m_data.iData1 != NO_UNIT)

Thanks for the suggestion.

 

[Archid]

You look to have a bug further back in the food chain where some code is pushing an invalid queue order item. I would try and find that now as you have a solution for a symptom of a problem and not the problem itself.

The code in pushOrder will by-pass the check for a valid iData1 if bForce is set. You could put an assertion at the start of the method to catch this scenario:

FAssertMsg(iData1 != -1, "Invalid queue item");

If you then run in debug mode you can break when the assertion fails and see what the call stack is. That might give you an idea of where the real problem lies.