Unofficial BTS 3.13 patch

Second, I gave India (colony) some workers, but they didn't turn into fast workers, their UU.
From what I remember, when a gift is similar to a civ's UU, the unit will become the UU equivalent.

other way around. if i gift you my UU, it stays my UU even for you. that sounds weird, but you know what i mean i hope. i'm washington and i give hatty a navy seal, it stays a navy seal for her, it doesn't revert to a marine. but if she gives me a marine, it doesn't turn into a navy seal.

if you pop a warrior from a hut and you're HC, that'll turn into a quechua. and if you're gandhi or asoka, captured workers (and ones popped from huts) turn into fast workers.
 
Ok, this is the list I'm looking at for the next release...

- Extended spy ejection protection to Great Spies
- Upgrading units no longer causes you to fail events requiring the existence of that unit
- AI Civs under Theocracy will no longer accept gifted Missionaries of non-state religion unless going for a cultural victory
- Units withdrawing from combat will be removed from selection group (thanks Moctezuma)
- Combat Odds window displays Attacker and Defender names
- When bumping naval units from cities, preference will be given to water tiles
- Naval/Air units are no longer bumped from cities when forming a Colony

Are there any other outstanding bugs that I was planning on fixing? I have a horrible memory, and don't feel like re-reading the last 20+ pages to check.

Bh
 
- AI Civs under Theocracy will no longer accept gifted Missionaries of non-state religion unless going for a cultural victory

Does this mean I'll be able to determine the AI's strategy (if they're in Theocracy) by attempting to gift them a missionary? :)
 
In case you want to change the start location normalization* at all, here is what I would recommend:

In CvGame::normalizeAddFoodBonuses(), there is a definite bug where it is trying to ensure you have
-A food resource
-In addition, another food resource, or a tile with >=3 food, or a resource tile with >=2 food.
However when it is looking at what you already have, it mistakenly counts a food resource in both categories.

To fix this, in CvGame::normalizeAddFoodBonuses(), at the inside of the first loop, replace:
Code:
if (pLoopPlot->isWater())
{
	iFoodBonus += 2;
}
else
{
	iFoodBonus += 3;
}
with
Code:
if (pLoopPlot->isWater())
{
	iFoodBonus += 2;
}
else
{
	iFoodBonus += 3;
}
//undo overcounting of existing food bonuses
if (pLoopPlot->calculateBestNatureYield(YIELD_FOOD, GET_PLAYER((PlayerTypes)iI).getTeam()) >= 2)
{
	iGoodNatureTileCount--;
}

I would recommend fixing this: it's obvious what the code is supposed to do (but doesn't), and it would improve the game.


Second, in CvGame::normalizeAddExtras(), it places forest before placing resources. This inevitably covers all land tiles with forest, thus preventing the placement of additional resources. In an unmodded game (with forests and without "normalizing" resources that can be placed in those forests), the resource placement code is guaranteed to be unable to add land resources like it wants to. It's a clear mistake; however, it is not completely clear what the best way is to fix it.

I think the best fix is to move the forest-adding code to below the resource-placing code. Here is why:
-I am guessing that the all the code was intended to be able to help your position. So, something should be done to allow placing of land resources, as there is code to place land resources.
-There was an intentional change in the code to make the forests placed 100% of the time instead of based on a die roll. I think it's better to keep this property if possible.
-Based on regenerating the map many, many times, there are very few starts that get bumped past the 80% threshold by placing resources. Even with this change, the vast majority of starts that have resources added to them because they are below 80% will also have the remaining plots filled with forests, and will still be significantly below 80% of the best value. This means that the change in ordering of the forest code and the resource code will have little functional difference other than preventing the situation where the forests block the resources.

To implement this change, you just need to cut and paste a block of code. Here is the block in question:
Spoiler :
Code:
				shuffleArray(aiShuffle, NUM_CITY_PLOTS, getMapRand());

				for (iJ = 0; iJ < NUM_CITY_PLOTS; iJ++)
				{
					if (GET_PLAYER((PlayerTypes)iI).AI_foundValue(pStartingPlot->getX_INLINE(), pStartingPlot->getY_INLINE(), -1, true) >= iTargetValue)
					{
						break;
					}
					
					{
						pLoopPlot = plotCity(pStartingPlot->getX_INLINE(), pStartingPlot->getY_INLINE(), aiShuffle[iJ]);

						if (pLoopPlot != NULL)
						{
							if (pLoopPlot != pStartingPlot)
							{
								if (pLoopPlot->getBonusType() == NO_BONUS)
								{
									if (pLoopPlot->getFeatureType() == NO_FEATURE)
									{
										for (iK = 0; iK < GC.getNumFeatureInfos(); iK++)
										{
											if ((GC.getFeatureInfo((FeatureTypes)iK).getYieldChange(YIELD_FOOD) + GC.getFeatureInfo((FeatureTypes)iK).getYieldChange(YIELD_PRODUCTION)) > 0)
											{
												if (pLoopPlot->canHaveFeature((FeatureTypes)iK))
												{
													pLoopPlot->setFeatureType((FeatureTypes)iK);
													iCount++;
													break;
												}
											}
										}
									}
									
									iFeatureCount += (pLoopPlot->getFeatureType() != NO_FEATURE) ? 1 : 0;
								}
							}
						}
					}
				}

It's near the beginning of CvGame::normalizeAddExtras(). It starts with the first mention in that function of shuffleArray.

There are three loops in the function preceded by shuffleArray. The second one is for resources and the third for hills. Paste the indicated code after either the second or the third such loop.

Note that the code I mentioned is preceded by
int iFeatureCount = 0;
Leave that line where it is and (trust me) it will all work out. There's another reference to iFeatureCount in the function but it is conveniently unreachable (and inconsequential).

I think this is a worthy change, and it's the best, least intrusive, and simplest change that can fix the overforestation problem. However it is really a subjective thing so you might choose not to do it.

There are a couple other bugs in the start location code but they have practically no effect and are not worth fixing.

*For background, see http://forums.civfanatics.com/showthread.php?t=252429
 
Lads, where should this be downloaded to? Which folder should it go in?

Replace the DLL in "Sid Meier's Civilization 4\Beyond the Swords\Assets" with the one by Bhruic. (This is also explained in greater detail in the readme included with the download.)

or

Install it as a mod as explained here by ori.

or

Use the *link removed - see below for current version* to automate the process.
 
Bh you should probably include the instructions to install as a mod, in your readme. Just a thought.

Wodan
 
Is the "AI prioritizing using bombardment units first (instead of close to last) when attacking with a stack of units" within the pervue of this patch?
 
Is the "AI prioritizing using bombardment units first (instead of close to last) when attacking with a stack of units" within the pervue of this patch?

As far as I can observe, they do. But they have serious trouble doing this when using an amphibious attack. I guess they don't see the various cargo loads of units as one stack and don't use the artillery type units from the various ships before using the other units from the various ships.
 
In CvGame::normalizeAddFoodBonuses(), there is a definite bug where it is trying to ensure you have
-A food resource
-In addition, another food resource, or a tile with >=3 food, or a resource tile with >=2 food.
However when it is looking at what you already have, it mistakenly counts a food resource in both categories.

I would recommend fixing this: it's obvious what the code is supposed to do (but doesn't), and it would improve the game.

I don't consider this a bug at all. IMO, it's working correctly. That routine is designed to ensure that you have at least one food resource (or two seafood resources) in your BFC. If that food resource happens to not be on grasslands or better (ie, minimum +2 food), then it'll try to make sure there are at least two food resources. Decreasing the iGoodNatureTileCount like you recommend would actually break that, and cause it to always attempt at least 2 food resources, unless there was a floodplains. Now you can argue that starting cities should always have at least 2 food resources, but while that may make a persuasive argument, it doesn't invalidate the current system.

I think this is a worthy change, and it's the best, least intrusive, and simplest change that can fix the overforestation problem. However it is really a subjective thing so you might choose not to do it.

Yeah, it is rather subjective. Even describing it as a "problem" may be incorrect. While having resources is nice, having lots of forests gives you good opportunities for Wonder-chopping early game. Still, I think it's a valid change to make. What I think I'll do is re-implement the random factor so that it doesn't cover every tile on the first run-through. Then I'll add a second forest (well, "+food or +production" feature) loop after it's done the other tile improvements. That should give a "best of both worlds" scenario.

There are a couple other bugs in the start location code but they have practically no effect and are not worth fixing.

Well, any bug is worth fixing just in case it has consquences that aren't predicted.

Bh
 
I don't consider this a bug at all. IMO, it's working correctly. That routine is designed to ensure that you have at least one food resource (or two seafood resources) in your BFC. If that food resource happens to not be on grasslands or better (ie, minimum +2 food), then it'll try to make sure there are at least two food resources. Decreasing the iGoodNatureTileCount like you recommend would actually break that, and cause it to always attempt at least 2 food resources, unless there was a floodplains. Now you can argue that starting cities should always have at least 2 food resources, but while that may make a persuasive argument, it doesn't invalidate the current system.

Hm, I see your point. I'd still call it a bug because of this difference:

If before normalization you have a food resource, you will end up with one.
If before normalization you don't have a food resource, you will end up with two.

That seems kind of backwards to me.

What I think I'll do is re-implement the random factor so that it doesn't cover every tile on the first run-through. Then I'll add a second forest (well, "+food or +production" feature) loop after it's done the other tile improvements. That should give a "best of both worlds" scenario.

That's what I've done for myself. :) Honestly though, the difference between this and what I posted will be miniscule.

If you want me to provide fixes for the other bugs, I can.
 
Hm, I see your point. I'd still call it a bug because of this difference:

If before normalization you have a food resource, you will end up with one.
If before normalization you don't have a food resource, you will end up with two.

That seems kind of backwards to me.

The normalization routine will only add 2 food resources if (a) you have no tiles with 3+ food, and (b) you have no other resources in the BFC that have 2+ food.

But yes, I realize that the first part can effectively count the same resource twice, which it doesn't do for the second part. So I guess I'll make that change (well, a similar one).

That's what I've done for myself. :) Honestly though, the difference between this and what I posted will be miniscule.

In some cases, yes. But I still favour a starting location with a decent number of forests to chop. If the "forest add" section was moved to after the "resource add" section, it might not get called at all. This way they'll be some trees added first, to ensure decent chop potential.

If you want me to provide fixes for the other bugs, I can.

That'd save me some time, for sure.

Bh
 
After 2 colonial games I've noticed the AIs don't upgrade some infantry to SAM infantry like in vanilla and warlords.
Until mechs my airforce had totally freedom. Not fun,this should be changed.

@KMC
You're right about gifting a UU, but I'm not totally convinced about the other way around.
I'll try it in a non-BTS game.
 
OK, here are the other bugs. They are in CvGame::normalizeAddExtras(). That function has five main loops, which I'll name.

L1: Just calculates the best and worst starting location values.

L2: Adds forests.

L3: Counts ocean food, coast food, land food, and water tiles.

L4: Adds resources.

L5: Adds hills.


1st Bug:

In L3, instead of counting water tiles in the BFC, it counts all 20 tiles. Later on this will imply that bLandBias is always true instead of only being true if more than half the BFC tiles are water.

Here is the relevant code:
Code:
iWaterCount++;
if (pLoopPlot->isWater())
{
	...
To fix the bug, move "iWaterCount++;" inside the test for whether the plot is water.

Note: It is theoretically possible that bugs 2-4 are not actually bugs but are actually a weird feature. I will explain this possibility after saying what they are.

2nd Bug:

In L4 - search for "(bLandBias" - there is the following if statement:
Code:
if (bLandBias && !(pLoopPlot->isWater()) && pLoopPlot->getBonusType() != NO_BONUS)

What it's trying to do is notice situations where you have many water tiles, and where you are looking at a land tile that the main code failed to place a resource on because of a feature (forest). The idea is to maybe remove the forest in this case, and try again.

To fix it, replace the "!= NO_BONUS" with "== NO_BONUS".


3rd Bug:

Within the aforementioned if statement, there is this code:
Code:
pLoopPlot->setFeatureType(NO_FEATURE);
if (getSorenRandNum(2, "Clear feature do add bonus") == 0)
{
	...

What it does is remove the feature, then if the random test succeeds try to place a resource there. It seems pretty likely that the removal of the feature is meant to happen inside the test, and this is another mistake like the one in the first bug.

Fix: move "pLoopPlot->setFeatureType(NO_FEATURE);" inside the if block.


4th Bug:

This requires a bit of background. In the first section of L4, where it is trying to add resources normally, there is this code:
Code:
pLoopPlot->setBonusType((BonusTypes)iK);
iCount++;
iCoastFoodCount += bCoast ? 1 : 0;
iOceanFoodCount += bOcean ? 1 : 0;
iOtherCount += !(bCoast || bOcean) ? 1 : 0;
break;
But in the second loop - which only applies to land tiles - there is this code:
Code:
pLoopPlot->setBonusType((BonusTypes)iK);
iCount++;
iCoastFoodCount += bCoast ? 1 : 0;
iOceanFoodCount += bOcean ? 1 : 0;
break;
It's the same except it's missing the line "iOtherCount += !(bCoast || bOcean) ? 1 : 0;" which it should not be missing; in fact, that line is the only one of the three lines like it that could apply on a land tile. Without this change, it will not count resources that it placed this way.

Fix: make the inside of the second loop look like the inside of the first loop by adding that line.


OK, now it is possible that what I called bugs 2-4 are actually how it is supposed to work. Here's what that would mean in a normal game:

The second part of L4, which only triggers on a land plot in a city which is more than half water, is supposed to do this instead:
-If we successfully placed a resource on a land plot with a forest (we have to have placed it, because the whole pair of resource-adding blocks is in an if statement which tests that there is no resource there),
-If our city is more than half water and has 3+ seafood,
-Then remove that forest
-And based on a die roll, sometimes replace the resource (fur or deer - which also implies this is a tundra forest) with a different resource.

I consider this a possibility because it simultaneously explains the test for a resource (bug 2) and the lack of incrementing the placed resources count (bug 4). However, as a feature, it doesn't make much sense. With default XML and start era all it does is kill tundra forests and then maybe replace the fur or deer with something else that lives in the tundra. (It also messes up iCount which, to be fair, is never used.)

I think it makes a lot more sense as "we don't want to place only water resources but the outlook isn't good because we have more than half water tiles, have already placed 3 water resources, and we are unable to place a resource on this tile without removing the forest".
 
About the city normalise city code.

I've often heard that this code can add rivers which cause so called river desert tiles which aren't improved with floodplains. These tiles cannot arise in any other way during the world creation phase. Personally, I think it was purely an oversight. The programmers simply forgot about the adding of floodplains during the normalisation phase.

After 2 colonial games I've noticed the AIs don't upgrade some infantry to SAM infantry like in vanilla and warlords.
Until mechs my airforce had totally freedom. Not fun,this should be changed.

The problem is that sam infantry is not strictly better than normal infantry. Normal infantry has a higher strength rating and a bonus against gunpowder units. This means that infantry is better against every unit except airplanes and is much superior against gunpowder units.

The only way to really defend against airplanes successfully is by having airplanes yourself.

There is one AI failure that I can see for Sam Infantry and Mobile Sam. These units seem to often use the strength upgrades which are fairly useless for them. They should often take the interception upgrade. These units are build to intercept airplanes, not to be the prime city defender. The strength upgrade would of course be useful against helicopters, but still the interception upgrade should be used more often.

For instance, Mobile Sam has a 50% chance to intercept planes meaning that it will not intercept 50% of the attacking planes. If the same unit has 2 interception upgrades, then it would intercept 80$ of the planes and only 20% could succesfully bombard the city. The unit would be far more effecient at intercepting planes which is its primary job. Mechanised infantry is far better at city defence.
 
The second part of L4, which only triggers on a land plot in a city which is more than half water, is supposed to do this instead:
-If we successfully placed a resource on a land plot with a forest (we have to have placed it, because the whole pair of resource-adding blocks is in an if statement which tests that there is no resource there),
-If our city is more than half water and has 3+ seafood,
-Then remove that forest
-And based on a die roll, sometimes replace the resource (fur or deer - which also implies this is a tundra forest) with a different resource.

I consider this a possibility because it simultaneously explains the test for a resource (bug 2) and the lack of incrementing the placed resources count (bug 4). However, as a feature, it doesn't make much sense. With default XML and start era all it does is kill tundra forests and then maybe replace the fur or deer with something else that lives in the tundra. (It also messes up iCount which, to be fair, is never used.)

I'm not sure what's making you talk about tundra tiles? I mean, certainly tundra tiles would be just as effected, but any other tile seems a valid target as well.

As for the theoretical explanation, I agree, it doesn't make any sense. Although your example of Fur doesn't fit - it's only considering adding resources that add food/production, Fur only adds commerce.

Actually, after looking into it further, it's very clearly a bug. In order to add a resource, it calls either:
Code:
CvMapGenerator::GetInstance().canPlaceBonusAt(((BonusTypes)iK), pLoopPlot->getX(), pLoopPlot->getY(), bIgnoreLatitude)
or
Code:
pLoopPlot->canHaveBonus(((BonusTypes)iK), bIgnoreLatitude)
The first function actually calls the second function as well, so both of them use CvPlot::canHaveBonus()

But CvPlot::canHaveBonus() has:
Code:
if (getBonusType() != NO_BONUS)
{
	return false;
}
Therefore it's always going to return false if there is already a resource on the tile. And while the loop removes the feature from the tile, it never removes an existing resource. So that loop can never add a resource as it's currently coded.

Bh
 
Everyone needs to be running the same version. You won't be able to play online with someone who hasn't installed this patch.

However, what you can do is set the patch up as a mod, and play that way. It won't interfere with your online play.

Bh
Then why did it work for me?
 
Either you haven't installed it properly, everyone else was using the same version, or you've installed it as a mod.

Otherwise you'll get OOS errors when playing - assuming it lets you start at all.

Bh
 
I know I installed it properly because I can see :culture: in building popups, and I didn't install it as a mod.
Wait a minute... one person did go OOS, and I think his name said *MOD* in front of it in the Staging Room. He must have been the only person without the patch!
Apparently it's very popular.
 
Actually, after looking into it further, it's very clearly a bug. In order to add a resource, it calls either...
Good call! :)

I'm not sure what's making you talk about tundra tiles? I mean, certainly tundra tiles would be just as effected, but any other tile seems a valid target as well.
I was thinking deer and fur only exist in tundra. I guess fur can also appear on snow. Now that you mention it I have seen fur on plains but according to the XML that isn't supposed to happen.

Deer and Fur are the only forest-friendly resources (other than Silk and Spices, which are untradeable in the ancient era) that are marked as "normalizing" resources in the XML.

I brought it up because if there were other forest-placeable resources you might want to replace with better ones, it could make sense. But with only deer and fur...

Although your example of Fur doesn't fit - it's only considering adding resources that add food/production, Fur only adds commerce.
Are you sure? I thought that the first time I looked but I haven't been able to see that anywhere again. The only thing I see is a check that the food change and the production change are both non-negative.
 
Top Bottom