Civ4 BTS v3.19 Patch

[Ninja2]

Okay, thanks for clearing that up, EF. I'm at work right now, so I can't get the patch... but I'm guessing they included the complete source files again?

As I recall, what I did last time was to use 3.17 as a base (i.e, the new sources, this time I will start with 3.19 obviously), applied the first available BetterAI that's compatible, and then I proceeded to add all the dll-comp's again. I guess there's not really any other way. Sigh.

 

[J-man]

Great! Totally unexpected. I love the barrage fix. I hope no new bugs are introduced?

 

[EmperorFool]

Others have reported that BUG works fine with the patch, and I didn't see anything so far to tell me different. I have been too busy porting BULL to 3.19 to do thorough testing yet.

I would say you're good to upgrade, and if anything does break I'll work as quickly as possible to fix it.

 

[Shurdus]

Great! Totally unexpected. I love the barrage fix. I hope no new bugs are introduced?

IN time I am confident we can find some...

In the end Firaxis can test all the want, but all that testing will be done ten times over by the community in a couple of days.

 

[Shurdus]

Others have reported that BUG works fine with the patch, and I didn't see anything so far to tell me different. I have been too busy porting BULL to 3.19 to do thorough testing yet.

I would say you're good to upgrade, and if anything does break I'll work as quickly as possible to fix it.

Thanks for the quick reply!

And I have no clue what BULL is but good luck with that! I will let you know if I can find anything with BUG 3.6 and the 3.19 patch.

 

[fabwed]

Hey, thx for the patch.

Well the Tk-Tk2 tag is pretty weired I gues u guys forgot to clean something in ur trials.

BTW its impossible now to ad someone to the budylist. This will spoil all the passworded games by time.

 

[jessiecat]

I installed the 3.19 patch and now can't run any version of RFC or mods of RFC. Luckily I used system restore and got it back to where it was yesterday. I caution anybody who upgrades to 3.19. RFC won't work with it.

 

[EmperorFool]

Turn 122 running BUG 3.6 and BULL patched to 3.19--no problems so far.

 

[r_rolo1]

A word about overflow gold:

I tested it a little and it seems to be constricted to the first build method ( chop/whip/regular build) of the building/unit that brings the build to 1 turn of completion. This means that multiple chops/whip in the same turn will most likely not give overflow gold. Can someone confirm this?

 

[Shurdus]

It does still overflow gold yet it is limited now to the cost of the building, as DaveMtW - or whatever the end of the name is - confirmed in another thread. So you can still get gold but not hundreds any more.

 

[r_rolo1]

Not exactly. I whipped a pro wall with stone and chopped 10 forests in the same turn and got exactly 0 gold overflow. It is not as simple and Dave said......

OTOH the "chariot in IW cap with all the possible modifiers for military builds in" is working as expected

 

[strategyonly]

hopefully it got rid of the gamefont.tga

I agree here, i dont like the current gamefont.tga also.

Apparently I don't need the CD with the new patch anymore. Woo-hoo. The BTS disc was basically a full time resident of one of my CD drives. No more.

Dang, i really really really like this, I wore out my Warlords CD, and cant use it anymore, to many scratches its now corrupt.

Based solely on looking over the changelog, I would bet that Python-only-based mods will work fine with 3.19 without any changes. The only Python change I see is the unremoval of the GLANCE tab, and that has no effect on mods. I also don't see any features that would require changing the SDK's Python API.
As for DLL-based mods, they will clearly need to be updated by their authors since the API between the EXE and DLL have changed.
I'll make an official post about BUG once I've had a chance to test it with the patch. My unofficial guess is that it will work fine as-is.

Yeah i am making a python only mod and patched to 3.19, and played a saved game with NO problem whatsoever, YEAH.

 

[Lexad]

Not exactly. I whipped a pro wall with stone and chopped 10 forests in the same turn and got exactly 0 gold overflow. It is not as simple and Dave said......

Same here:
http://forums.civfanatics.com//showpost.php?p=8163096&postcount=132

 

[PieceOfMind]

So overflow now appears to be limited to the build cost of the unit/building and anything over that is lost - not converted to gold. Chop even one forest into partially completed scout and you'll probably lose hammers. This means MM is back.

I just chopped about 250 into a scout and got exactly 22 for my next build, the cost of the scout (Epic speed).

 

[JujuLautre]

That's really strange, because that's not what is mentioned in the OP.

Build-specific production modifiers are no longer counted for overflow gold calculations

I could be correct, but for me, this is the implementation that was used in the unofficial patch, that is reduce the overflow gold to 1x multiplier when there was more initially. Is it not ?

 

[PieceOfMind]

maybe one needs to have currency before it works. I'll go check.

Nope, it appears even with Currency no overflow gold at all. Trying the same with a granary, 0 gold. If the granary costs 90 and you're an expansive leader, the overflow hammers are cut down to 45.

 

[Caboose]

"- Collateral damage modifiers, collateral damage immunity, and air defense modifiers, multiply instead of add."

What does this mean in practice?

 

[r_rolo1]

@Piece of Mind

You don't need currency. I already tested it in the chariot in HE city scenario

 

[PieceOfMind]

OTOH the "chariot in IW cap with all the possible modifiers for military builds in" is working as expected

What is "working as expected"? Getting 0 gold overflow I assume. It seems to work exactly the same way for the HE city. Note if the build following has a hammer multiplier, the overflown hammers do go through those modifiers.

 

[VoiceOfUnreason]

It looks to me as though someone lost track of where the overflow is capped, and therefore the gold overflow is being compared to the wrong thing. In other words, at the point where iProductionGold is calculated, iOverflow is capped, but iMaxOverflowForGold is still huge, and therefore the difference is negative.

Also of note - there are three duplicate variations of this code, depending on whether the city is training a unit, constructing a building, or creating a project. All share the same calculation.

(From CvCity.cpp)

iProductionNeeded = getProductionNeeded(eTrainUnit);

// max overflow is the value of the item produced (to eliminate prebuild exploits)
iOverflow = getUnitProduction(eTrainUnit) - iProductionNeeded;
int iMaxOverflow = std::max(iProductionNeeded, getCurrentProductionDifference(false, false));
int iMaxOverflowForGold = std::max(iProductionNeeded, getProductionDifference(getProductionNeeded(), getProduction(), 0, isFoodProduction(), false));
[b]iOverflow = std::min(iMaxOverflow, iOverflow);[/b]
if (iOverflow > 0)
{
	changeOverflowProduction(iOverflow, getProductionModifier(eTrainUnit));
}
setUnitProduction(eTrainUnit, 0);

int iProductionGold = std::max(0, [b]iOverflow - iMaxOverflowForGold[/b]) * GC.getDefineINT("MAXED_UNIT_GOLD_PERCENT") / 100;