Unofficial Patch for 3.19

That sounds like reasonable logic to me, equalizing the hammer opportunity between game speeds basically. So the odds of spread would scale as:

X out of (10000 * FeatureProductionPercent)/100

Works for me.

A similar adjustment can be made for the appearance of resources on mined hills. Presently, you'll get a lot more resources from mined tiles on marathon speed than on normal speed during the length of a game.

Hugely more important is a similar adjustment to the chances that some random diplomatic effects occur. The most important one is the chance to declare war. Presently, the chance to declare war each turn is exactly the same at marathon speed as it is on normal speed. Because a certain period of the game (say medieval times) typically takes 3 times as many turns on marathon speed, this means that the chance to declare war during that period is far larger at marathon speed. Dividing the odds to declare war each turn by 3 on marathon game speed would balance things (approximately).

For those who like a mathematical approach:
Spoiler :
If p are the odds to declare war each turn, then the odds to declare war during a marathon speed game turn would become p/3 if the above made adjustment is made.
I want to show that the odds that an AI declares war during three marathon turns is close to the odds that an AI declares war during a single normal game turn if the above suggested adjustment is made.
The odds that an AI declare war during three marathon turns is 1 - (1-p/3)^3 and the odds that an AI declares war during a single normal game turn is p.

1-(1-p/3)^3 = p - (p^2)/3 + (p^3)/9 which converges to p for small p as
lim p->0 [p - (p^2)/3 + (p^3)/9]/p =1

So it would balance things as long as the odds to declare war per turn are small which is mostly true as far a I know.

Example for odds of war declaration of 1% per turn or p=0.01:

Odds per turn at normal speed: 1%
Odds at non-adjusted marathon speed odds per 3 turns: 2.97%
Odds at adjusted marathon speed odds per 3 turns: 0.997%


The failure of Firaxis to balance the war declarations of the various game speeds is the reason that marathon players often complain that the AI is predictable in its war declarations and that it is too aggressive. It makes sense that an AI that has a small chance to declare war each turn will eventually declare war when enough turns have passed. This might not happen during a normal game speed game, but it will happen almost surely during a marathon game.

There are other elements of the AI diplomacy which haven't been scaled to game speed. I'm not sure which ones, but all of them should be scaled. This will reduce the predictable result that at marathon game speed an AI will eventually do something even though the odds per turn are small.

I myself play at epic game speed which suffers far less from these non-scaled game elements, but still has a slightly different balance than normal game speed. I would like it if the marathon game players can also enjoy a more balanced game with less weird war declarations.
 
It seems another problem with the code I posted above for extra building health/happiness is that it calls changeBuildingBadHealth/Happiness() as if the value it stores should be positive. Looking at the other code in CvCity, these values are negative, the lower the number the more :yuck: there is from buildings.
 
CvPlayer::canTradeItem()
Spoiler :
Code:
    case TRADE_CIVIC:
        [COLOR="Red"]if (!(GET_TEAM(getTeam()).isHuman()))[/COLOR]
        {
            if (GET_PLAYER(eWhoTo).isCivic((CivicTypes)(item.m_iData)))
            {
                if (canDoCivics((CivicTypes)(item.m_iData)) && !isCivic((CivicTypes)(item.m_iData)))
                {
                    if (canRevolution(NULL))
                    {
                        return true;
                    }
                }
            }
        }
        break;

    case TRADE_RELIGION:
        [COLOR="Red"]if (!(GET_TEAM(getTeam()).isHuman()))[/COLOR]
        {
            if (GET_PLAYER(eWhoTo).getStateReligion() == ((ReligionTypes)(item.m_iData)))
            {
                if (canConvert((ReligionTypes)(item.m_iData)))
                {
                    return true;
                }
            }
        }
        break;
This means that human player can not request teammate AI to convert religion or civic.
Because GET_TEAM(getTeam()).isHuman() returns true when the team includes a human player even if the human is eWhoTo player self.
I wonder this behavior and believe that it should be
Code:
if (!(GET_TEAM(getTeam()).isHuman()) [COLOR="Red"]|| (getTeam() == GET_PLAYER(eWhoTo).getTeam()[/COLOR])
.

How do you think?
 
This would mean you could bribe your own AI teammates but still be unable to bribe other human players' teammates. I agree that this makes sense. The question is whether or not this is deemed a bug fix or new feature.
 
The failure of Firaxis to balance the war declarations of the various game speeds is the reason that marathon players often complain that the AI is predictable in its war declarations and that it is too aggressive. It makes sense that an AI that has a small chance to declare war each turn will eventually declare war when enough turns have passed. This might not happen during a normal game speed game, but it will happen almost surely during a marathon game.

Hold on, with the changes that you suggest, wouldn't you then see the same amount of wars in a marathon as in a normal speed game? Or am I misunderstanding you?

Currently I am playing marathon, and I like the fact that by the time you hit mid-game there have been several different wars. The marathon game is longer, and I think it's good that that is reflected in the amount that goes on in a game. Marathon games would be dull if you had on average as many ways as in a normal speed game.
 
Hold on, with the changes that you suggest, wouldn't you then see the same amount of wars in a marathon as in a normal speed game? Or am I misunderstanding you?

No that's what I'm getting at. Marathon are stretched out normal games with more decision points and relatively faster movement due to the greater amount of turns.

In marathon, you'd get a similar number of wars, but they would be of greater length each.

The main problem with the current setup is that war will almost always happen even between civilisations that like eachother (pleased neighbours who almost never declare war at pleased). Even a small chance of war will inevitably lead to a war declaration after the dice have been rolled enough times. And due to the far greater amount of turns, the dice are rolled far more often.
I've seen multiple complaints about the predictability of a war declaration in marathon games.

By the way, the aggressive AI option is a good one if you want more wars in your games. That option was created to get more wars and aggression during your games.
 
Ok I see what you mean, but I prefer it as it is, and would hesitate to describe the current situation as in any way a bug. There are too few wars in normal games, and I like marathon for increasing the brutality. There is more time to mull over grievances between players and more wars in general. I don't think having the same amount of wars, but having them of increased duration, is a good solution. With movement speed at marathon implemented as it is, you can accomplish as much in n turns of fighting as you could on normal speed.

By the way, the aggressive AI option is a good one if you want more wars in your games. That option was created to get more wars and aggression during your games.

Again I disagree. All I have heard about aggressive AI suggests that the AI increased unit building just makes it easier to out-tech them, if you survive the first few turns. That's not what I want, I like normal AI behaviour but a longer game with more bitter rivalries and wars of revenge. Unlike normal speed, marathon wars seem to be more realistic in that at least before the mid-late game, a war is concluded with the loss of one or two cities, which is a blow but recoverable from, while on normal if the tide turns against you you are probably out of the game.
 
I think that Roland ( very unlike what he usually does ) did not explained well what he meant. Besides the fact that there are a lot of other things that should scale with speed and they don't, especially events, but not only , the fact is that warfare in epic, marathon and quick is neither independent or fully regulated by the speed you are using. Yes, like he said, war checks ( and demands ) are turn based , but the war prep period ( the "hands full" status ) is speed scaled. So we have a very anomalous situation where in slower speeds the Ai is more eager in average to think on warring, but will take the same ( in proportion ) time to prepare themselfes to war ( same to quick speed, just the other way around ). And for what I assume on reading your text, you are not oposed to scale the war checks with speed, you are just oposed to make it by Normal speed standarts ;)
 
Ok I see what you mean, but I prefer it as it is, and would hesitate to describe the current situation as in any way a bug. There are too few wars in normal games, and I like marathon for increasing the brutality. There is more time to mull over grievances between players and more wars in general. I don't think having the same amount of wars, but having them of increased duration, is a good solution. With movement speed at marathon implemented as it is, you can accomplish as much in n turns of fighting as you could on normal speed.



Again I disagree. All I have heard about aggressive AI suggests that the AI increased unit building just makes it easier to out-tech them, if you survive the first few turns. That's not what I want, I like normal AI behaviour but a longer game with more bitter rivalries and wars of revenge. Unlike normal speed, marathon wars seem to be more realistic in that at least before the mid-late game, a war is concluded with the loss of one or two cities, which is a blow but recoverable from, while on normal if the tide turns against you you are probably out of the game.

The negative comments which you've read about aggressive AI are from the days that Beyond the Sword was just released and was very buggy. I personally have more trouble with the aggressive AI on immortal level on huge maps on epic speed than the normal AI under similar settings. They won't tech slowly under such settings. The aggressive AI option might hurt the AI's at low difficulty levels, but the AI can easily support the bigger army at the higher levels without really hurting its research speed.

I do understand your preference for a more warlike game, but I've also read many comments about players who really hate the predictability with which the AI will eventually declare war on anyone they don't love at marathon speed. It reduces the value of relations to good or not-good. The finer differences between the various levels of not good aren't that important anymore for war declarations as they will eventually occur after enough rolls of the dice.

But I won't argue any further as I'm not arguing this point for my own games as I don't play on marathon speed. You may argue with other players who really dislike this consequence of the marathon setting. It's not a personal issue of mine.
 
Suggestion for a small audio improvement for supermarkets and coal plants:

Replace AS2D_BUILD_GROCER by AS2D_BUILD_SUPERMARKET
Add tag AS2D_BUILD_PLANTCOAL to coal plants

The sounds and xml are already done by Firaxis but somehow they forgot to change/add it for these city improvements :lol:

In Civ4BuildingInfos.xml there's a reference for the Hanging Gardens: AS2D_BUILD_HANGGARDENS, also properly defined in Audio2DScripts.xml and AudioDefines.xml but the wav seems to be missing (or am I looking in all the wrong places :confused:)
 
I found a new bug. When a building gives a negative defense against spies, it still says "Helps thwart enemy spies." I got a screenshot for it.

View attachment 232980

This is an issue with CvGameTextMgr. Here's the fix:

Code:
/*************************************************************************************************/
/** Afforess	Unofficial Patch         31/10/09                                                */
/**                                                                                              */
/**                                                                                              */
/*************************************************************************************************/
	if (kBuilding.getEspionageDefenseModifier() != 0)
	{
		if (kBuilding.getEspionageDefenseModifier() > 0)
		{
			szBuffer.append(NEWLINE);
			szBuffer.append(gDLL->getText("TXT_KEY_BUILDING_ESPIONAGE_DEFENSE_MOD", kBuilding.getEspionageDefenseModifier()));

			szBuffer.append(NEWLINE);
			szBuffer.append(gDLL->getText("TXT_KEY_UNIT_EXPOSE_SPIES"));
		}
		if (kBuilding.getEspionageDefenseModifier() < 0)
		{
			szBuffer.append(NEWLINE);
			szBuffer.append(gDLL->getText("TXT_KEY_BUILDING_ESPIONAGE_DEFENSE_MOD", kBuilding.getEspionageDefenseModifier()));
		}
	}
/*************************************************************************************************/
/** Afforess                                                                                     */
/*************************************************************************************************/

Too bad this didn't make the release...
 
Had a bug reported in LoR by PieceOfMind. When capturing a city he got contact with a civ that he could not see a unit for. A user reported this was default BtS behavior, where when capturing a city for a brief moment you have vision over some of the cultural view of the city (the inner ring). Tested this report, and it, indeed is a bug in BtS. Reports can be found here:

PieceOfMind's original bug report -picture in post to visually represent the bug
User expenation of bug's behavior

Attaching a save where the bug is reproduced (simply capture the city to the south of the chariot). Save is for default BtS 3.19, no modifications.
 
Interesting ... fun one.

Well I assume this is from Vanilla. And given that it hasn't been reported or complained about in the 5 years of the game's existence, and it doesn't really cause any issues, I think it would be fine to ignore. But since it was reported to me, and I could reproduce it, I figured I'd just forward the report and let you or EF decide if you really want to bother with fixing it. I'm sure no one will complain either way.
 
I'm certainly not complaining. ;)

Still, as happens with some bugs, is it possible that investigating further could reveal another similar and perhaps more serious bug?
 
Seeing PieceOfMind makes me wonder: would you consider the rounding of trade routes which makes some multiplier buildings completely useless in some circumstances as a bug ? If so, worthy to be corrected here ?
 
Seeing PieceOfMind makes me wonder: would you consider the rounding of trade routes which makes some multiplier buildings completely useless in some circumstances as a bug ? If so, worthy to be corrected here ?

Well, based on some of the discussion EmperorFool provided in the PIG Mod thread, I'd say it's not any more unusual than rounded off hammers or food not being counted. For example, on large maps the food corps can take several food resources that provide no benefit (because of rounding) yet still subtract their fees from your city.

25% hammer bonuses in the early game like forges or Organised Religion only work to their fullest when your base hammers (including overflow and chopping) are a multiple of 4.

Fractional trade routes having a small rounding problem is no bigger a problem than the above IMO. It just looks more confusing on the interface.

As my opinion goes on other issues that are similar to this, the issue is with the game's documentation.

Having said that, I think it's pretty inconsistent and buglike gameplay that a forge in a city with 3 base hammers will do nothing, yet work at nearly the full 25% bonus in a city that has only 1 hammer and uses whipping almost exclusively for its production.

I'm not sure it's within the scope of the Unofficial Patch project, to be honest.
 
Top Bottom