Unofficial BTS 3.13 patch

Go make that argument in the poll thread. ;) (That's actually a very valid point, and had I thought of it prior to making the change, I wouldn't have - in fact, it might be enough to make me re-reverse my decision).

Bh
 
Go make that argument in the poll thread. ;) (That's actually a very valid point, and had I thought of it prior to making the change, I wouldn't have - in fact, it might be enough to make me re-reverse my decision).

Bh

By reading the civilopedia, it says under sp, corporation has no effect. It should mean both domestic and foreign branchs, if it give any income for foreign branchs, we can safely say its a bug.

If you want use china as an example to justify anything about corporation, you will get the exact opposite answer. If you look at the brief post ww2 china history, you will see that under mao's communism, people gets prosecuted to death if they found a multi national corp in china.

If you want to use mordern china as an example. please get the facts straight, CHINA OF TODAY HAS COMMUNISM IN ITS NAME ONLY, the actual way china functions today has nothing to do with communism. Since the early 80s after mao's death under the rule of deng xiaoping, china started the gradual change towards a kind of controlled capitalism.
 
About the multiplayer bug that i mention afew post behinds, okay it works, the only time doesnt work when playin an scenario but I dont know if thatz the way has to be
 
Not sure if this has been covered, I didn't see any mention of it. But it seems that if a hostile unit attacks one of your own units, and workers are nearby, the workers will not wake up. So basically attacking onto a tile, you can ninja some workers.

Does that make sense?
 
Go make that argument in the poll thread. ;) (That's actually a very valid point, and had I thought of it prior to making the change, I wouldn't have - in fact, it might be enough to make me re-reverse my decision).

Bh

In case you need further motiviation to re-reverse your decision, how about the fact that you COULD found a HQ in State Property in 3.02? So taking the stance of "unintended side effect until declared in a changelog or included in a stable patch by Firaxis," I'd say allowing HQ founding in State Property is our best shot at unaltered gameplay. I think your patch will retain the most appeal if it stays true to unaltered gameplay. Who cares what the prevailing opinion is on what "should" happen? Someone can mod that. You're all about unaltered gameplay here, right? Or more specifically, unaltered-intention gameplay, since everything else you've fixed is technically part of vanilla but obviously an unintended 3.13-introduced bug. The Civilopedia entries on corporation have said the same thing since 3.02.
 
Well, you're going to either have to move or rename the original dll (recommended), or you will have to overwrite the existing file. Either way, if the game works and you're sure you placed Bhruic's file in the correct directory, it's active. :)

You are right, it does indeed. I can tell because trading is now somewhat rational.

Thanks!

Breunor
 
Here is a small mistake in the 3.13 dll code I noticed.

I had noticed in a game that the governor worked a cottage with 9 turns to hamlet over one with 6 turns to hamlet. It seemed like it doesn't discern between the two.

I looked in CvCityAI.cpp in the function AI_plotValue.

Code:
	if ((eCurrentImprovement != NO_IMPROVEMENT) && (GC.getImprovementInfo(pPlot->getImprovementType()).getImprovementUpgrade() != NO_IMPROVEMENT))
	{
		iValue += 200;
		int iUpgradeTime = (GC.getGameINLINE().getImprovementUpgradeTime(eCurrentImprovement));
		if (iUpgradeTime > 0) //assert this?
		{
			int iUpgradePenalty = (100 * (iUpgradeTime - pPlot->getUpgradeProgress()));
			[b]iUpgradePenalty *= (iTotalDiff * 5);[/b]
			iUpgradePenalty /= max(1, GC.getGameSpeedInfo(GC.getGame().getGameSpeedType()).getImprovementPercent());
			iValue -= iUpgradePenalty;
		}		
	}

The bolded line is the funky one. The local variable iTotalDiff is ALWAYS zero - it's just never set to anything anywhere. The result is that the entire block of code I quoted doesn't do anything at all past the iValue += 200; line.

That code that doesn't do anything because of the mistake is the only code that looks at the upgrade time. The result is that the AI/governor can't tell the difference between a cottage with one turn left, and one with all of its turns left.

Now, I am not sure what is a good way to fix this. It is not perfectly clear to me how much other things tend to be valued at. A first glance puts the value of one commerce at 6, though I am not sure how much this gets scaled. The low values could make it hard to make adding the turns left to the value hard, because you don't want a hamlet with 20 turns left to be valued less than a cottage with one turn left.

Do you think this is fixable without scaling the entire valuation system?

By the way, I diffed it and that entire section, as well as everything referring to iTotalDiff, was unchanged by 3.13. So this bug was there before as well.
 
Not sure if this has been covered, I didn't see any mention of it. But it seems that if a hostile unit attacks one of your own units, and workers are nearby, the workers will not wake up. So basically attacking onto a tile, you can ninja some workers.

Does that make sense?

Not so much. :)

You need to be a little clearer about who has to do what. Can you give a more specific example? Or a screenshot?

Bh
 
The bolded line is the funky one. The local variable iTotalDiff is ALWAYS zero - it's just never set to anything anywhere. The result is that the entire block of code I quoted doesn't do anything at all past the iValue += 200; line.

You're absolutely correct. I can only assume that iTotalDiff is designed to be the sum of all iYieldDiff values. The only problem with that is that the greater the iYieldDiff values, the greater iTotalDiff is going to be. And the greater it is, the more it will take away from iValue. Effectively meaning that it'll value squares that are more developed less than it values ones that aren't. That seems somewhat backwards.

Looking at the facts however: Currently, the system will properly choose a more developed tile over a less developed one (ie, a Hamlet over a Cottage). Therefore, the system works, barring the "time left". So if we make a change that does nothing except adjust for time left, it should never run into a situation where it would prefer the Hamlet over the Cottage. In fact, the change could be extremely minor, and it should be enough to make the difference (because for all intents and purposes, two cottages on the same base square type should have identical plot values).

Therefore, I believe simply doing a:
iValue -= pPlot->getUpgradeTimeLeft(eCurrentImprovement, NO_PLAYER);
should suffice.

(good catch btw :goodjob:)

edit: Yup, that seems to work. Tried a variety of situations, it'd always take the most developed square first (Town->Village->Hamlet->Cottage), and if it had to take something of which there was duplicates, it would always take the one that has less turns remaining.

Bh
 
Update:
  • Amount of time worked taken into consideration by city plot selection (thanks SevenSpirits)
  • The Vassal of a Capitulating Civ is freed before peace treaty

The second one may need some explaining. Let's say you are at war with another Civ who has a Vassal. You manage to beat down the Master Civ to the point where it will Capitulate to you. Prior to this patch, what would happen is (in this order) the Master and Vassal would both gain peace with you. The Master would then Capitulate to you, which would free the Vassal. The problem with this was the order. Consider another case where you are at war with a Master and a Vassal, and the Vassal breaks away. Do you automatically gain peace with the Vassal? No, you continue to be at war with the Master and the Vassal.

The same should be true in the original case - the Master is Capitulating to you, not the Vassal. The Vassal shouldn't get "free" peace just because his ex-Master is becoming a Vassal - you should continue to be at war with the Vassal. That is what the patch does, it frees the Vassal from the Master before the peace treaty is signed.

Bh
 
Cool! I tested it a bit too, and also with tiles on rivers. It still always prefers a the tile with the +1 commerce, regardless of the turns remaining or level of the cottage. I think that at least covers all the problems it could conceivably cause with cottages.
 
Not so much. :)

You need to be a little clearer about who has to do what. Can you give a more specific example? Or a screenshot?

Bh

Thought so. :sad:
This is a very makeshift screenshot to show what I mean. If these workers are to start building a farm, and the barbarian attacks my axe and wins, my workers will continue working on the farm and not wake up so I can move them.

Barbug.JPG


So if I don't have any active units that turn, then I won't even have the option to move my workers.
 
This vassal thing patch is way cool! :goodjob:

Please think yout other things about vassals, and if there is consensus,
those should be done - lets make Civ even greater

(not to MOD, just to iron out original intentions)
 
Sorry to reiterate but the Fireaxis silence is definitely not classy,on the other side Bhruic & friends are releasing goldenpieces and therefore I suggest them to release an own patch and request Fireaxis a solid contribute.

Why don't you make a poll about that ? I think Firaxis still have to learn how to manage games & customers relationships ,assuming Bhrucic is not an hidden Fireaxians...;)

BTW Bhruic why did you choose such a nick ?
 
[...]So if I don't have any active units that turn, then I won't even have the option to move my workers.
Same problem occured with healing units, at least up to 3.02.

A change would definetively make sense.
 
I had noticed in a game that the governor worked a cottage with 9 turns to hamlet over one with 6 turns to hamlet. It seemed like it doesn't discern between the two.

Awesome catch, SevenSpirits, and thanks for the fix, Bhruic!! I have been frustrated about this since Vanilla and never imagined it would be fixed. Every time my cities would suffer temporary unhappiness, I would have to go back and shift the citizens from cottages with 14 turns left to cottages with 1 turn left. No more-- yay!!
 
Depends on your definition of "affect". It's going to warn that you are using different versions of files. But since it's purely a display issue, it shouldn't actually cause any game problems.

Bh

SO the reason for me getting all those "error" messages is because I have the Glance tab back and they don't. Thanks for that explaination, I was wondering why I was getting those issues.
 
Update:
  • Amount of time worked taken into consideration by city plot selection (thanks SevenSpirits)
  • The Vassal of a Capitulating Civ is freed before peace treaty
The second one may need some explaining. Let's say you are at war with another Civ who has a Vassal. You manage to beat down the Master Civ to the point where it will Capitulate to you. Prior to this patch, what would happen is (in this order) the Master and Vassal would both gain peace with you. The Master would then Capitulate to you, which would free the Vassal. The problem with this was the order. Consider another case where you are at war with a Master and a Vassal, and the Vassal breaks away. Do you automatically gain peace with the Vassal? No, you continue to be at war with the Master and the Vassal.

The same should be true in the original case - the Master is Capitulating to you, not the Vassal. The Vassal shouldn't get "free" peace just because his ex-Master is becoming a Vassal - you should continue to be at war with the Vassal. That is what the patch does, it frees the Vassal from the Master before the peace treaty is signed.

Bh

I followed this fixes thread and have been satisfied by its success. But with the modified behaviour of capitulating civs and vassals I am a little bit disappointed. I believe there are different opinions out here how a vassal should behave when its master capitulates. But as long as this is not agreed it should behave like Fireaxis implemented it. Any other opinions here?
 
But as long as this is not agreed it should behave like Fireaxis implemented it. Any other opinions here?

I agree. I'd prefer to have a nice Unaltered Gameplay mod that simply fixes the things Firaxis messed up in 3.13. I'm certainly not averse to an Altered Gameplay version as well. (Bhruic, would it be too much to ask for you to have two parallel versions, one Unaltered and one Altered?) Of course Solver's well-loved patch was Altered Gameplay, but I think 3.13 is different in that it has loads of obvious mistakes and bugs. Solver's was more of a "Better AI" sort of thing. I think SG, HOF, BUG mod, etc. would appreciate a pure Unaltered Gameplay version that simply fixes the bugs. Then everyone else can have an Altered Gameplay version that fixes bugs PLUS the stuff we like better another way.
 
Back
Top Bottom