Unofficial Patch for 3.19

EmperorFool · Feb 22, 2010

Fuyu said:
Forts in neutral land can't be used as channels either.

Yeah, this I actually can recall seeing for my own eyes, and I assume the same is true of forts as airbases.

Ninja2 · Feb 22, 2010

Oh, sorry, I confused the "bug" spotted by NotSoGood with his Route Bombing modcomp.

PieceOfMind · Feb 25, 2010

Do note, the thread I started concerning forts is not 100% comprehensive but as near to it as I could manage. Looking back, the where Fuyu quoted me saying "Obviously...", it looks very unobvious to me what I meant by that. I'm fairly sure CG/CR promotions work on neutral forts but it wouldn't hurt to do a very quick and simple WB test of that to clear it up.

Anyway, if the suggestion is being retracted I guess it doesn't matter anymore.

Fimbulvetr · Feb 25, 2010

Yes the promotions work and the fort gives defense. It doesn't work as airbase or channel though, and defending an unowned tile will not matter to the current AI. So bombing it is useless, at least that was my reasoning.

edit: that reasoning works only for singleplayer though. In a war between human players it would still make a lot of sense to make forts (that contain units of players you are at war with) destroyable by air bombardment because a human definitely can use chokepoints for his own advantage. So maybe not completely retracted, just not all that important.

Afforess · Mar 11, 2010

I don't know if this is willful by Firaxis, or just a silly mistake, but in CyInfoInterface1, it skips "isOnlyDefensive".

Firaxis code:

Code:

.def("isNoBadGoodies", &CvUnitInfo::isNoBadGoodies, "bool ()")
.def("isNoCapture", &CvUnitInfo::isNoCapture, "bool ()")

Correct Code:

Code:

.def("isNoBadGoodies", &CvUnitInfo::isNoBadGoodies, "bool ()")
.def("isOnlyDefensive", &CvUnitInfo::isOnlyDefensive, "bool ()")
.def("isNoCapture", &CvUnitInfo::isNoCapture, "bool ()")

It caused me a fair bit of confusion as to why I was getting python exceptions until I finally dug around and noticed they excluded it.

denev · Mar 11, 2010

CvCityAI::AI_calculateCulturePressure()

Code:

	if ((iTempValue > 80) && (pLoopPlot->getOwnerINLINE() == [COLOR="Red"]getID()[/COLOR]))

It should be

Code:

	if ((iTempValue > 80) && (pLoopPlot->getOwnerINLINE() == [COLOR="Blue"]getOwnerINLINE()[/COLOR]))

CvCityAI::AI_playerCloseness()

Code:

int CvCityAI::AI_playerCloseness(PlayerTypes eIndex, int iMaxDistance)
{
	FAssert(GET_PLAYER(eIndex).isAlive());
	FAssert(eIndex != [COLOR="Red"]getID()[/COLOR]);

It should be

Code:

int CvCityAI::AI_playerCloseness(PlayerTypes eIndex, int iMaxDistance)
{
	FAssert(GET_PLAYER(eIndex).isAlive());
	FAssert(eIndex != [COLOR="Blue"]getOwnerINLINE()[/COLOR]);

jdog5000 · Mar 17, 2010

Thanks Afforess & denev, will be included in 1.5 (should be out soon).

denev · Apr 11, 2010

CvPlayerAI::AI_foundValue()

Code:

	//iClaimThreshold is the culture required to pop the 2nd borders.
	int iClaimThreshold = GC.getGameINLINE().getCultureThreshold((CultureLevelTypes)(std::min(2, (GC.getNumCultureLevelInfos() - 1))));
	iClaimThreshold = std::max(1, iClaimThreshold);
	iClaimThreshold *= (std::max(100, iGreed));
	[COLOR="Red"]iClaimThreshold /= 100;[/COLOR]

Red line is missing.
iClaimThreshold is too big.

Liquidated · Apr 19, 2010

Not sure if this all was covered but a search never brought it up so going to illustrate what may or may not be a bug...

When placing a lumber mill on a riverside tile, 1 commerce is supposedly added. This works for tiles where an entire side of the tile is river, but not on diagonals which are otherwise considered riverside by the game.

A quick screen shot of this in action.

Both worked tiles are milled forests marked fresh water. Not sure if this is a bug or intended.

Cheers!
-Liq

EmperorFool · Apr 19, 2010

I suspect that is intended because there is probably a specific check in the code. isRiver() would return true for the diagonal case, so there must be code that checks for the corner case. I'd have to look at the code to be absolutely sure, though. I can do that tonight if I remember.

Fimbulvetr · Apr 19, 2010

It might be confusing at first but seems to be intentional. river does not equal riverside .. or something like that.

Elkad · Apr 22, 2010

Fuyu said:
It might be confusing at first but seems to be intentional. river does not equal riverside .. or something like that.

Since you can't build watermills on corners, seems likely it's using the same check as that to add the extra commerce.

r_rolo1 · Apr 25, 2010

Elkad said:
Since you can't build watermills on corners, seems likely it's using the same check as that to add the extra commerce.

Using jdog words in a older thread in this forum:

jdog5000 said:
Lumbermills and preserves set the XML tag RiverSideYieldChange, where the "RiverSide" phrasing is also what Firaxis used to limit where watermills can be placed. So, it appears Firaxis did this intentionally ... there is no RiverYieldChange tag for improvements like there is for terrain.

The Civilopedia phrasing (English at least) is that these improvements give an extra commerce when "next to a river" while grassland/plains/etc give +1C when "adjacent to a river". They're clearly trying to differentiate between the two cases, but it is quite ambiguous. It's better than the watermill phrasing though, which simply says it "Requires river"!

As for the rationale for why lumbermills and preserves would generate extra commerce "next to" a river, it seems to me to be the same as why unforested grasslands would - proximity to the river increases traffic. I agree coherency there would fit better logically, but it's been this way since the beginning and changing it would be kind of a pain.

This looks intentional indeed, but the engrish :lol:

Firaxis used in here is definitely prone to cause confusion...

EmperorFool · Apr 25, 2010

I doubt anyone scrutinized the choice between "adjacent" and "next to" at Firaxis, especially since the definition for adjacent is listed as

close to, lying near
next to, adjoining

If anything it's common to use different phrases so as to cut down on repetition.

The coding, however, is likely intentional given that there are two separate XML tags.

DaveMcW · Apr 25, 2010

The current code forces players to make a choice between riverside lumbermills/preserves and riverside watermills.

If you could get full benefit from forests on the corners, it would lead to the boring strategy of "always forest the river corners, always watermill the riverside".

jsbrigo · Apr 27, 2010

please can you add these italian localization bugfixes?

Code:

Civ IV BtS - Italian

Official patch 3.19

Unofficial patch 1.40

-------------
buglist & fix
-------------

Dir Beyond the Sword\Assets\XML\Text
File CIV4GameText_Events_BTS.xml

      <Tag>TXT_KEY_EVENTTRIGGER_MOTOR_OIL</Tag>
2637  <Italian> remove 'chemists'

      <Tag>TXT_KEY_EVENTTRIGGER_DISSIDENT_PRIEST</Tag>
6544  <Italian> change 'Amun-Re' to 'Amon-Ra'

      <Tag>TXT_KEY_EVENT_DISSIDENT_PRIEST</Tag>
6552  <Italian> change 'Amun-Re' to 'Amon-Ra'

      <Tag>TXT_KEY_EVENT_DISSIDENT_PRIEST_1</Tag>
6560  <Italian> change 'Amun-Re' to 'Amon-Ra'



<!-- Copyright jsbrigo 2010 -->

r_rolo1 · Apr 29, 2010

DaveMcW said:
The current code forces players to make a choice between riverside lumbermills/preserves and riverside watermills.

If you could get full benefit from forests on the corners, it would lead to the boring strategy of "always forest the river corners, always watermill the riverside".

That argument would only holds if you either started in a almost fully forested world ( say, Arboria ) or if you can plant forests

. Otherwise the choice is never that one, but if I should cut those trees or not

Afforess · Apr 30, 2010

Allright, I have a bueatiful Double-WTF I just found. When anyone on your TEAM gets a great person, or a great general, everyone on the TEAM's threshold for the next one increases. Despite the fact that these are handled on a player-by-player basis. But wait, that's not TRWTF (the real WTF).

This is:

Code:

void CvPlayer::createGreatPeople(UnitTypes eGreatPersonUnit, bool bIncrementThreshold, bool bIncrementExperience, int iX, int iY)
{
	CvUnit* pGreatPeopleUnit = initUnit(eGreatPersonUnit, iX, iY);
	if (NULL == pGreatPeopleUnit)
	{
		FAssert(false);
		return;
	}

	if (bIncrementThreshold)
	{
		incrementGreatPeopleCreated();

		changeGreatPeopleThresholdModifier(GC.getDefineINT("GREAT_PEOPLE_THRESHOLD_INCREASE") * ((getGreatPeopleCreated() / 10) + 1));

		 for (int iI = 0; iI < MAX_PLAYERS; iI++)
		{
			if (GET_PLAYER((PlayerTypes)iI).getTeam() == getTeam())
			{
				GET_PLAYER((PlayerTypes)iI).changeGreatPeopleThresholdModifier(GC.getDefineINT("GREAT_PEOPLE_THRESHOLD_INCREASE_TEAM") * ((getGreatPeopleCreated() / 10) + 1));
			 }
		}
	} 

	if (bIncrementExperience)
	{
		incrementGreatGeneralsCreated();

		changeGreatGeneralsThresholdModifier(GC.getDefineINT("GREAT_GENERALS_THRESHOLD_INCREASE") * ((getGreatGeneralsCreated() / 10) + 1));

		for (int iI = 0; iI < MAX_PLAYERS; iI++)
		{
			if (GET_PLAYER((PlayerTypes)iI).getTeam() == getTeam())
			{
				GET_PLAYER((PlayerTypes)iI).changeGreatGeneralsThresholdModifier(GC.getDefineINT("GREAT_GENERALS_THRESHOLD_INCREASE_TEAM") * ((getGreatGeneralsCreated() / 10) + 1));
			 }
		}
	}

Spoiler Hint :

Now this is a double wammy. I had some users complaining to me that when they played co-op, when one person got a GP, it was harder for both of them. I don't agree with Firaxis's decision to make it affect team-mates, but whatever. However this implementation is not synchronous. Your threshold will be increased 2x, but teammates only 1x. Even if this is intentional, it wastes CPU time, because you call a function twice. Also, why no "isAlive" checks? Should we really be messing with dead players?

EmperorFool · Apr 30, 2010

Notice that there are two constants in play here: one applied to the player and a separate team value applied to everyone on the team, including the player.

jdog5000 · May 1, 2010

Yeah, and there are two different global define values being referenced (though they are both 50 in XML). It seems to be intentional, as in single player the second GP is supposed to cost twice as much, so the 50 + 50 gets you 100% increase in cost. Your teammate would see a 50% increase.

The good thing is though that with those two separate XML variables you can easily tweak this however you want, turning down the teammate effect if you want without any SDK changes needed.

One thing that is interesting:

Code:

changeGreatPeopleThresholdModifier(GC.getDefineINT("GREAT_PEOPLE_THRESHOLD_INCREASE") * ([B](getGreatPeopleCreated() / 10) [/B]+ 1));

Once you pass 10 great people, the cost boost becomes +200% of the cost of the first GP each time. I didn't know that.

Unofficial Patch for 3.19

Deity

Great Engineer

Drill IV Defender

Emperor

The White Wizard

Warlord

Revolutionary

Warlord

Goofed Up on Cough Syrup!

Deity

Emperor

Emperor

King of myself

Deity

Deity

Chieftain

King of myself

The White Wizard

Deity

Revolutionary

Similar threads