Unofficial Patch for 3.19

Yes, no doubt that should be

Code:
if (iSpreadExternalValue [B][COLOR="Red"]==[/COLOR][/B] 0)

Otherwise a) it overwrites iSpreadExternalValue's existing value and b) never passes the if() test to return 0.

What that whole block you posted says (after the above fix) in English is "If we have more cities with the corporation than we have cities (i.e. all our cities have the corporation), zero out the value for internal spread (nowhere to spread). In addition, if the value for external spread has already been found to be zero, return zero for the total value of building executives for this corporation."
 
I've also added the following at the bottom of CvPlot::setFeatureType():

Code:
		if (getFeatureType() == NO_FEATURE)
		{
			if (getImprovementType() != NO_IMPROVEMENT)
			{
				if (GC.getImprovementInfo(getImprovementType()).isRequiresFeature())
				{
					setImprovementType(NO_IMPROVEMENT);
				}
			}
		}
		//
		// Mongoose FeatureDamageFix BEGIN
		//
		else if (GC.getFeatureInfo(getFeatureType()).getTurnDamage() > 0)
		{
			CLLNode<IDInfo>* pUnitNode;
			CvUnit* pLoopUnit;
			pUnitNode = headUnitNode();
			while (pUnitNode != NULL)
			{
				pLoopUnit = ::getUnit(pUnitNode->m_data);
				pUnitNode = nextUnitNode(pUnitNode);
				pLoopUnit->getGroup()->clearMissionQueue();
				pLoopUnit->getGroup()->setActivityType(ACTIVITY_AWAKE);
			}
		}
		//
		// Mongoose FeatureDamageFix END
		//
	}
}

This gives humans, and especially AIs, a chance to re-evaluate their activity due to both the turnover damage they will have just taken from the newly-grown feature, and the reduction in healing there on future turns if they were in the middle of a heal mission/activity. This is primarily so AIs do not stupidly let their ships just sit in high-damage ocean storms and sink several turns later in my mod when they can easily move out, but is also useful for standard land features like Jungle and Fallout.
 
I don't see how that would be useful. Features can't grow if there is a unit on the tile, so setFeatureType should never be called when a unit is on a tile (excepting random events & worker clearing).
 
Features can't grow if there is a unit on the tile, so setFeatureType should never be called when a unit is on a tile (excepting random events & worker clearing).

Ah yes, I forgot about that (stupid) vanilla rule heh. I took it out in my mod a long time ago, so didn't think to consider it when posting.

That being said, yes it will still apply for random events that... umm... spawn a Tornado or something lol... Okay fine, it's useless in vanilla, but a mod might still benefit. Feel free to not use this one JDog, though adding it is harmless! :p
 
I have posted this message in the bug forum about the wrong units seemingly being used in combat when selecting all units of a particular type. Any chance you could take a quick look at it and see if it is a bug?

I am using the latest version of your unofficial patch.

Thanks.
 
I hesitate to suggest this fix since I haven't explored any further ramifications, but I think it should be fairly safe.

The problem is that CvCityAI::AI_updateBestYield() is called before CvCity::doCulture(). On the turn that a city's borders expand to allow more worked plots, the cached best yield values are not updated. Rather, they are updated before the borders expand, so the new plots won't be considered until the following turn.

In the normal game this probably only affects the player: automated workers won't act optimally, and if the player selects a worker near the city that expanded, they will not see recommendation circles on the new plots. The problem rights itself at the end of their turn.

I noticed it because I added a feature to BULL that highlights all of the plots around the selected city with different colors based on whether they are being worked and/or can be improved. I could solve it by calling AI_updateBestYield() every time you select a city bar, but I'd rather fix the root problem.

My fix is trivial and looks innocuous enough: call AI_updateBestYield() in CvCity::setCultureLevel() whenever it changes from the previous value.

Code:
void CvCity::setCultureLevel(CultureLevelTypes eNewValue, bool bUpdatePlotGroups)
{
	...

	if (eOldValue != eNewValue)
	{
		...

		if (GC.getGameINLINE().isFinalInitialized())
		{
			...

/************************************************************************************************/
/* UNOFFICIAL_PATCH                       08/08/10                              EmperorFool     */
/*                                                                                              */
/* Bugfix, already called by AI_doTurn()                                                        */
/************************************************************************************************/
			AI_updateBestBuild();
/************************************************************************************************/
/* UNOFFICIAL_PATCH                        END                                                  */
/************************************************************************************************/
		}
	}
}

It might even belong outside of that last if regarding isFinalInitialized(). That is just a guard to protect from displaying the border pop message.
 
GravityWave: if whatever mod you are using has LeadFromBehind in it, GG are supposed to stay behind. The odds shouldn't lie though. It's a bug if you're using pure UP 1.60.

EF: I'd place it at the very end of the if (eOldValue != eNewVlaue) block, outside the isFinalised one.

My own bug report: badHealth() is counting ExtraBuildingBadHealth twice, once as part of totalBadBuildingHealth, then again seperately.
Code:
int CvCity::badHealth(bool bNoAngry, int iExtra) const
{
	[COLOR="DimGray"](...)[/COLOR]
	iHealth = totalBadBuildingHealth();
	if (iHealth < 0)
	{
		iTotalHealth += iHealth;
	}

	[COLOR="DimGray"](...)[/COLOR]

[B][COLOR="Red"]	iHealth = getExtraBuildingBadHealth();
	if (iHealth < 0)
	{
		iTotalHealth += iHealth;
	}[/COLOR][/B]
	[COLOR="Green"]// ^ needs to be removed ^[/COLOR]
	[COLOR="DimGray"](...)[/COLOR]
}
 
GravityWave: if whatever mod you are using has LeadFromBehind in it, GG are supposed to stay behind. The odds shouldn't lie though. It's a bug if you're using pure UP 1.60.

I'm not using any mod, but if your unable to replicate it with the save I posted then I will have a look at reinstalling Civ and testing it again.
 
hey quick question - does this unofficial patch add in the 50 players capability that 3.17's unofficial had?
 
Am I correct that 1.5 is the latest release? Also there don't seem to be any commits to the trunk since 1.5. Am I missing something? I'm pretty frazzled this weekend trying to get the BUG + BULL releases done and may have erred.
 
Can you please tag r34 as "1.6" when you get a chance? That appears to be the last change that went into the release.
 
It's a mismatch between the "TXT_KEY_CIVIC_NON_STATE_REL_HAPPINESS_NO_STATE" <Text> element and the code. When the civic has a state religion, the code doesn't pass in the # and type of happy/unhappy the civic produces, but the <Text> expects them. The fix is trivial...

It's a long time since this was posted but could somebody tell me where this fix should be done. Is this Python or SDK? I'm totally new in this and have just started to look at Python but could not do anything if it's SDK.

Thanks.
 
@isenchine - The fix goes in the C++ DLL (SDK)--not Python. But if you install the Unofficial Patch, you'll get the fix.
 
Thanks EmperorFool. My problem so far is I can't merge DLL (if I understand it correctly) and I still have to decide which change for the game I want most - this unofficial patch or any other mod component.
 
If you aren't making any DLL changes yourself, you should be able to use the UP's DLL and merge the Python changes into your mod.
 
Yes, I started to copy/paste some python changes and XML is not a problem. What tool would you advise me to use with the DLL?
 
If you just want to use the UP DLL, use Windows Explorer to copy and paste it into your mod's Assets folder. ;)

If you want to modify your own DLL, you'll need to set up compiling with Visual C++ Toolkit 2003. There is a guide in the tutorials forum that explains how to do this more advanced task.
 
Thank you, EmperorFool. I meant modify the DLL so I'll give it a try with Visual C++ Toolkit 2003.
 
I had a weird issue when choosing what to research: when I tried to research machinery or some such, it researched pottery instead, even though I'm certain I should have been able to research it. No matter what I did, it tried to research some earlier thing instead.

Perhaps that has been resolved in this patch, and I should merely start a new game. (I patched the game with this only after running into that bug.) If so, someone please tell me as much.
 
Top Bottom