Dancing Hoskuld
Deity
That happens because StrategyOnly forgets to put the new civilizations in the python file Python/EntryPoints/CvCultureLinkInterface.py.
Single Player bugs and crashes - After the 13th of August 2013
- Thread starter Dancing Hoskuld
- Start date
That happens because StrategyOnly forgets to put the new civilizations in the python file Python/EntryPoints/CvCultureLinkInterface.py.
Yes, it works better the way it is implemented now. I was concerned not by values of combat modifiers per se but only by the fact that percentages was changing a little while combat modifiers remained the same.
Glad that issue with GG fixed, will test it.
God-Emperor
Deity
Unless the combat mod has seriously altered how this is done, and I'm pretty sure this has not changed, this is not correct.
That 100% modifier is applied to that defender by dividing the defenders strength by 1 + modifier (where 100% = 1.00). In this case it is therefore divided by 1 + 1 = 2, so the defender is strength 500.
After combining all the modifiers on the defender:
Defender has net positive modifier means multiply its strength by 1 + modifier.
Defender has net negative modifier means divide its strength by 1 - modifier.
This is why it works out a bit different when both have modifiers, but it is the same when only one is getting them (like your example). If attacker gets modifier A and defender gets modifier D you might want to apply them as
BaseStrA * (1 + A) vs. BAseStrD * (1 +D)
but using just BaseStrA and then using BaseStrD * (1 + D) / (1 + A) is identical in ratio between the two. The question is, how is this different than doing what it does where most of "A" (everything except the basic modifier from the iCombatPercent in the promotion info) is subtracted from "D" and then it is applied as mentioned. The answer to that is that is is not very different in a lot of cases - in fact, it is identical in your example where D is 0 and A is 1.
Description of early withdrawal on stone throwers states "Starts withdraw at 80% HP lost". But they often withdraw with almost full HP, why? Just now stone thrower flew combat with viper with 0.9 strength.
Maybe it is the other way around and withdraw start at 80% HP _remained_? But in any case it was 89 hp.
Maybe it is the other way around and withdraw start at 80% HP _remained_? But in any case it was 89 hp.
Attachments
strategyonly
C2C Supreme Commander
Fixed in new SVN. thx for info.
strategyonly
C2C Supreme Commander
Has anyone else have this happen to him/her recently, ALL and i mean ALL of my "options" are GONE
Not even the default ones are there??????? I just noticed when i took over a city and there was no assimilation for that civ?
Now when i load that same game its SAYS i have the options (pic2) but then poof as soon as the game is IN-PLAY, GONE
Not even the default ones are there??????? I just noticed when i took over a city and there was no assimilation for that civ?
Now when i load that same game its SAYS i have the options (pic2) but then poof as soon as the game is IN-PLAY, GONE
Has anyone else have this happen to him/her recently, ALL and i mean ALL of my "options" are GONE
I'm sure there are still here. They don't show up though because of python exception. Guess you have python exceptions popups turned off in config.
strategyonly
C2C Supreme Commander
Nope UNLESS this error is causing it??
Traceback (most recent call last):
File "CvScreensInterface", line 1310, in handleInput
File "CvVictoryScreen", line 2056, in handleInput
File "CvVictoryScreen", line 849, in showGameSettingsScreen
AttributeError: type object 'CvPythonExtensions.GameOptionTypes' has no attribute 'NUM_GAMEOPTION_TYPES'
ERR: Python function handleInput failed, module CvScreensInterface
Yes, this error is the cause. I reported it at http://forums.civfanatics.com/showpost.php?p=12744715&postcount=190 and Stormwind reported it today in this thread.
God-Emperor
Deity
I expect it is that it attempts to withdraw if a round of combat would put it below, and possibly at, 80% remaining (not taken).
Since the first hit it took caused 11 damage, another would probably cause it 11 (or maybe slightly less since damage taken during combat now affects this, but it is apparently at least 9) which would push it below 80. A withdraw attempt comes at the end of a round and if you withdraw you don't take the damage from that round, which is how the regular "not early" version keeps your unit alive: instead of taking the damage which would put it at 0 or lower it withdraws.
No, I believe my original contention was correct. The problem is this code (from CvUnit::maxCombatStr()), and the code immediately after it which treats modifiers for combatInfos similarly, which I have omitted for brevity:
Code:
// only compute comparisions if we are the defender with a known attacker
if (!bAttackingUnknownDefender)
{
FAssertMsg(pAttacker != this, "pAttacker is not expected to be equal with this");
iExtraModifier = unitClassDefenseModifier(pAttacker->getUnitClassType());
iTempModifier += iExtraModifier;
if (pCombatDetails != NULL)
{
pCombatDetails->iClassDefenseModifier = iExtraModifier;
}
iExtraModifier = -pAttacker->unitClassAttackModifier(getUnitClassType());
iTempModifier += iExtraModifier;
if (pCombatDetails != NULL)
{
pCombatDetails->iClassAttackModifier = iExtraModifier;
}God-Emperor
Deity
It is adding the defender's modifiers and subtracting the attacker's modifiers to get a net modifier for the defender. Now go look at how the modifiers are applied in the actual current strength calculation in CvUnit::maxCombatStr (which is scaled in currCombatStr based on current hit points to get the value actually used in the combat) and you will find this:
Code:
if (iModifier > 0)
{
iCombat = (baseCombatStr() * (iModifier + 100));
}
else
{
iCombat = ((baseCombatStr() * 10000) / (100 - iModifier));
}That is pretty much the last thing done in there other than some data storage and it is that iComabt value which it returns as the max combat strength.
True. That makes my calculation of the effect of the error incorrect, and explains why we don;t see HUGE distortions. However consider this:
Attacker has +100% general mods, and +100% vs the defenders combat class
Defender has +100% general modifiers
Correct calculation:
Attacker has 200% mod, defender has 100%, so 3a vs 2d (1.5 X base a/d)
Actual calculation:
Attacker has 100% mod (the general mod), defender has 0 (100 general, -100 from attacker applied negatively to the defender), 2a vs d (2.0 X base a/d)
That's still a pretty big error. It only work out correctly if ALL modifiers are either attack or defense mods.
God-Emperor
Deity
It depends on what you mean by "correctly". This is the way that Civ4 has always done it and it was apparently done on purpose. But BtS does not normally get anywhere near the modifier totals that C2C can, which increases the difference between what it does and what you might expect.
So it is true that is is not giving the same results as applying all the attackers bonuses to the attacker an all the defenders bonuses to the defender, or the equivalent of applying them both to the defender but independently (as Dstr * ( 1 + Dmod) / (1 + Amod)). But this does not make it an error if it was what was intended.
If only one of the two gets a modifier it is clearly the same in either case. It only matters when both get modifiers (and the attacker's modifiers are not the one type that get applied to the attacker). In your example it doesn't matter which way the 100% bonus is applied since 6 vs 1000 and 3 vs 500 are equivalent, they are both 166 2/3 to 1 ratios in favor of the strong one (leaving the weak one with identical practically 0 chances of winning in either case).
You might want to see how a few other cases work out to see why it was done that way. What effect would it have to "correct" the calculations vs. the way it is done now for some city raider macemen attacking city defense archers with a few variations like the macemen having one more promotion than the defenders, or two more, or one less, and the city still having 10% defense or being on a hill (which is a big bonus for the archers) in each case?
Two basic examples:
Assume both attacker and defender are strength 10.
1) Defender has 10% more bonus than attacker, with 30% vs. 20%
10 * 1.3 / 1.2 = 10.83 defender strength ("corrected" way)
vs.
10 * 1.1 = 11 defender strength (existing way)
So in this case the existing way is better for the defender.
2) Attacker has 10% more bonus than defender, also 30% vs. 20%:
10 * 1.2 / 1.3 = 9.23 defender strength ("corrected" way)
vs
10 / 1.1 = 9.09 defender strength (existing way)
So in this case the existing way is better for the attacker.
Based on these two examples (so not exactly a complete examination), it looks like for the existing way actually magnifies the benefits for the one with the higher bonus, at least for these sorts of cases.
Since in BtS the defender often has higher bonuses due to terrain, features, and fortification it looks to me like it is set up so that the defender will normally have a small increase to their advantage from this. But if you can get your attacker promoted enough to get a higher modifier than the defender's then the modifier advantage will flip to being magnified for the attacker.
By 'correctly' I meant 'in accordance of what one would naively expect based on the description of it being an attacker modifier'. Since it shows up in the pedia and in the combat details hover (at least on its own line, NOT in the aggregate strength displayed [which makes this hover text self-inconsistent]) as a bonus for the attacker, listed in precisely the same manner as other bonuses, it is reasonably to expect it to have a similar effect.
However, now we've got to the bottom of it all, I must admit I don't really feel very motivated to do anything about it!
Similar threads
- Sticky
- Sticky
