Solver's unofficial BtS 3.17 patch

I vote to restore Glance. Of course, I'll just do it on my own if it's not included, but there may be noobs out there who don't even know it exists (or, indeed, how to restore it,) and I'd prefer to give them the option of using it or ignoring it.

As for it being buggy, is there any interest on someone fixing it? (I.e., obviously not me, because I don't know where to even begin attacking the problem...not least of which b/c I'm not sure why it's buggy. I hadn't noticed any problems, other than it being a little hard to grasp at first.)

Spoiler for my last volley on missionaries!:

Spoiler :


Since Solver has apparently clarified with Firaxis that it is intended that civs running theo be able to spread non-state religions at their own discretion, that more or less satisfies me as far as the non-state religion argument goes. (Though I may make it into a rules variant mod component myself later on.)

I still believe that it is wise to ban gifting of missionaries pending the development of an AI "smart" enough to know when to use or disband those gifted missionaries. No sense in letting an exploit exist. This is, after all, how Firaxis "solved" the problem with corporate execs (simply re-establishing the corp. exec cap,) so I'm not sure why they didn't include the missionary gifting fix, too. Both they and Solver apparently disagree with me on this, so that's pretty much it for this issue altogether. (I may dig up Bhruic's fix and include it in my own mod later, as well.)

 
The description of #7 is too vague. If that's a fix for the excessive forestation issue, good, I want to fix that.

No it's not. Bhruic acknowledged in a post to me that it still didn't prevent all the Forest from being created. It only added more resources to the BFC, especially food.
 
^~But giving more food to a BFC normally makes the forest spam far less likely ;)
Is that true?

Or, does the food make the situation of forest spam less undesirable?

Wodan
 
That would be nice.

As for the Glance screen, anyone else thinks I should reenable it? I know this was a popular request with 3.13. The screen is still quite bugged, but can be easily resurrected if there's demand for it.

I'll post the replay in the other thread with a few notes.

Glance screen... I think even though you have the worst enemy notification now there are still instances where you need to be able to read the diplo modifiers more closely. I'll generally try to start trades with a block of AIs who are friendly enough with each other that a few bad events etc. in the future will not turn them into enemies. You can easily avoid the worst enemy trade penalty now, but it's possible to fall into a situation where you're trading with two people whose relationship deteriorates to the point where one of them asks you to cancel deals - the point one should never reach!

Regardless of how useful it is, I don't see how it hurts to have acessible information presented in a more tabulated manner. I would of course argue it's useful because you can very quickly see all the relations of a particular civ just by reading along a column or row.
 
Dear Mr. Multitasking-Solver: :)
Code:
int iModifier = getUnitInfo().getCollateralDamage() > 0 ? (100 + getExtraCollateralDamage()) : (iCollateralStrength * getExtraCollateralDamage() / 10);
This lets the attacker's baseCombatStr() influence the CollDmg TWICE and will therefore destroy consistency.

I'm glad that Roland Johansen reworded the straightforwardness of the route 2 approach with the Barrage Tank examples. This IS completely intuitive, one only needs to recognize that a unit's native CollDmg and its Barrage promotion work additively with both relating to the unit's baseCombatStr.

So I believe that with the small XML-tweaks for Cho-Ko-Nus and Battleships my proposed code should make everybody happy. Also no need to remove Barrage promo line from Tanks.

When you find the time to delve into the maths to find an alternative solution you should also take the later calculation of iMaxDamage into consideration as this will also be influenced by the attacker's/defender's strength ratio.
 
@Wodan

Forest spam is one of the last steps of the "beautification" algorythim and normally only kicks in when the start is food poor. 3.13 ( and AFAIK 3.17 ) code makes that forest spam enters before the step that puts more food resources, making it impossible ( you can't wheat were a forest already is ... the exception is seafood . That is why most BtS starts vary between superseafood start and superforest spam ).

All this is discussed in Bh thread , from post 1304 on
 
I'm not a big fan of just making the starting locations better. In that sense I'd say the map generator is working well. The forestation issue needs to be fixed though.
 
The problem is that the forest spammed starting locations are pretty food poor and if you simply remove the forests , they will be very dreadful places.

I think that SevenSpirits idea is the best path.
 
Dear Mr. Multitasking-Solver: :)
Code:
int iModifier = getUnitInfo().getCollateralDamage() > 0 ? (100 + getExtraCollateralDamage()) : (iCollateralStrength * getExtraCollateralDamage() / 10);
This lets the attacker's baseCombatStr() influence the CollDmg TWICE and will therefore destroy consistency.

I'm not seeing that... for a non-native collateral unit, modifier will be iCollateralStrength * extra coll / 10. iCollateralStrength depends on baseCombatStr, being half of it for non-native units, but extra collateral damage is just dependent on the number of barrage promotions and isn't dependent on baseCombatStr. Or? I will be trying out this code in-game to see what the effect is.

Forgot about iMaxDamage, though, gee.
 
The problem is that the forest spammed starting locations are pretty food poor and if you simply remove the forests , they will be very dreadful places.

I think that SevenSpirits idea is the best path.

Well, if I understand correctly, the forests get added because there isn't enough land food to start with. If SevenSpirits adjusted that through adjusting food distribution, that's good. Anyway, I'll need the code from BH's patch, so it's gonna take a while :D
 
I'm not seeing that... for a non-native collateral unit, modifier will be iCollateralStrength * extra coll / 10. iCollateralStrength depends on baseCombatStr, being half of it for non-native units, but extra collateral damage is just dependent on the number of barrage promotions and isn't dependent on baseCombatStr. Or?

baseCombatStr will of course influence the initial iCollateralDamage directly through the core formula and then a second time through the iModifier. My feeling tells me that this is not good in terms of consistency.:confused:
 
Solver,

Well, if I understand correctly, the forests get added because there isn't enough land food to start with. If SevenSpirits adjusted that through adjusting food distribution, that's good. Anyway, I'll need the code from BH's patch, so it's gonna take a while

No I think the actual bug (issue) was that the forests were being added before the food was added to boost the value of the capital. For this reason, it adds far too many forests, and then afterwards if the start was too poor still no food could be added anymore either.

ie. the bug was that the order was not completely logical. The reasoning you just gave is what they intended and is intuitive, though it is not what happened in practise.

I'm not sure exactly how the code works but I'm pretty sure it was well established that the intended behaviour of the algorithm was not what was happening.
 
baseCombatStr will of course influence the initial iCollateralDamage directly through the core formula and then a second time through the iModifier. My feeling tells me that this is not good in terms of consistency.:confused:

This entire discussion is about handling inconsistent situations. Normally, units that have native collateral damage can get Barrage promotions. That works fine, the formula is nice and consistent. But we're dealing with units that have no collateral damage but have Barrage... it's already inconsistent with the rest of the game.

It isn't exactly beautiful, but I do like the numbers this latest approach gives for non-native collateral units, so I'll run some more tests. Don't exactly want to spend more time on this than on everything else ;)
 
Well, if I understand correctly, the forests get added because there isn't enough land food to start with. If SevenSpirits adjusted that through adjusting food distribution, that's good. Anyway, I'll need the code from BH's patch, so it's gonna take a while :D
From what I understand from SevenSpirits code and description quoted below, that is the case ( spoilered quotes ... pretty big stuff ;) )
Spoiler :
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

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".
 
This entire discussion is about handling inconsistent situations. Normally, units that have native collateral damage can get Barrage promotions. That works fine, the formula is nice and consistent. But we're dealing with units that have no collateral damage but have Barrage... it's already inconsistent with the rest of the game.

Well to me it's a matter of interpretation, additive Barrage promotions that allow the Tank to splash fractions of bystanding stack defenders with its native fire power makes perfectly sense in my eyes.

Don't exactly want to spend more time on this than on everything else ;)

I most certainly understand. So just a quick counter-example:

A modded (degraded) Catapult (Str 5) with no native CollDmg but BarrageII will have
iModifier = (iCollateralStrength * getExtraCollateralDamage() / 10) = 10. [iCollateralStrength = floor(5/2);]

Splashing an Axeman (also Str 5) will take away
floor(6 * 10/100) = 0 HPs :cry:
if my quick math is not faulty
 
Yeah, but if it's such a weak unit with no native collateral, why should it do collateral to a unit of equal strength? It's a contrived example, too :)
 
Yeah, but if it's such a weak unit with no native collateral, why should it do collateral to a unit of equal strength? It's a contrived example, too :)

It would also not be able to scratch an Archer and just take 1 HP away from a Warrior, whereas a degraded BII Mobile Artillery vs a Paratrooper would give:
iModifier = (iCollateralStrength * getExtraCollateralDamage() / 10) = 13*50/10 = 65 and thus take floor(7*65/100) = 4 HPs away. ==> no consistency :(
 
@ CivCorpse, hardly. I got the +Shock for Axemen event. None of my warriors that upgraded got the promotion. All my units that I built did. Is the warrior that upgraded to an axeman somehow inferior to one that was never a warrior? I don't think so.

Oh, I thought you meant the other way around. That since axemen got the shock promotion, then macemen should get it too. I stand corrected
 
Top Bottom