#7 on that list is frickin' vital.
Solver's unofficial BtS 3.17 patch
- Thread starter Solver
- Start date
My view on the damaged AI-fighter use discussion:
If fighter is damaged, then chance to have fighter heal instead of do mission equals twice the percentage of damage (85% strength -> 30% chance of healing for this turn). Should only apply if there are enemy fighters about ... if only bombers or airships, then reduce healing chance to equal damage%.
My biggest complaint about AI aircraft use is I never see them build any bombers, and I never see fighters do anything but fly intercept. If they don't use them offensively, where is my incentive to put mine on intercept?
Noble/Huge/Marathon. Sometimes I allow (or even help) the AI to get flight & radio (occasionally they do it on their own, of course).
If fighter is damaged, then chance to have fighter heal instead of do mission equals twice the percentage of damage (85% strength -> 30% chance of healing for this turn). Should only apply if there are enemy fighters about ... if only bombers or airships, then reduce healing chance to equal damage%.
My biggest complaint about AI aircraft use is I never see them build any bombers, and I never see fighters do anything but fly intercept. If they don't use them offensively, where is my incentive to put mine on intercept?
Noble/Huge/Marathon. Sometimes I allow (or even help) the AI to get flight & radio (occasionally they do it on their own, of course).
Minor Annoyance
Deity
I got an event like that but it was for march and gunpower units, and I'm pretty sure I got it on all of them whether they were build before or later.
Edit: About the missionary gifting. I like the idea of just not allowing missionaries to be gifted. The only reason to gift a missionary to someone rather than use it on their city yourself is if you can't because of theocracy.
Solver are you able to include some of the the fixes from the Better BTS AI mod? I understand you've been consulting with the authors but I'm not sure what you and them plan to do about sharing the bug fixes. In particular the following two bugfixes are not in your patch:
- Fixed bug in player closeness calculations causing the AI to be blind to its actual proximity to other players (CvPlayerAI::AI_playerCloseness, used Option A from Unofficial Patch discussion thread)
- Fixed bug with needed defenders where the AI would choose to defend a recently captured holy city less than a normal city
The player closeness one is a big bug and I'd prefer using the Better BTS patch at the moment because it is fixed in that one. But I'm also keen to try out some of the later fixes in your patch too - I like the idea that GP are not settled if city is under threat.
As for the discussion about fighters healing, I think bombers should be allowed to attempt their bombing runs in the presence of enemy interceptors even if they are damaged - just not critically damaged. I do this reguarly and it seems (this is only heresay) they are not any more likely to get shot down than full health bombers. So I usually keep using bombers until they drop below about 60% health. Most of the time when bombers are intercepted they are only damaged anyway, not shot down.
I would however avoid using ordinary bombers at all when there are jet fighters around.
Remember too that fighters etc. have a range so I'm not sure exactly how efficient it is to calculate if a particular tile to bomb is outside the range of all enemy interceptors and SAMs. SAMs have a range of 1 which I assume means they can intercept in adjacent tiles too? I'm not entirely sure about the mechanics.
- Fixed bug in player closeness calculations causing the AI to be blind to its actual proximity to other players (CvPlayerAI::AI_playerCloseness, used Option A from Unofficial Patch discussion thread)
- Fixed bug with needed defenders where the AI would choose to defend a recently captured holy city less than a normal city
The player closeness one is a big bug and I'd prefer using the Better BTS patch at the moment because it is fixed in that one. But I'm also keen to try out some of the later fixes in your patch too - I like the idea that GP are not settled if city is under threat.
As for the discussion about fighters healing, I think bombers should be allowed to attempt their bombing runs in the presence of enemy interceptors even if they are damaged - just not critically damaged. I do this reguarly and it seems (this is only heresay) they are not any more likely to get shot down than full health bombers. So I usually keep using bombers until they drop below about 60% health. Most of the time when bombers are intercepted they are only damaged anyway, not shot down.
I would however avoid using ordinary bombers at all when there are jet fighters around.
Remember too that fighters etc. have a range so I'm not sure exactly how efficient it is to calculate if a particular tile to bomb is outside the range of all enemy interceptors and SAMs. SAMs have a range of 1 which I assume means they can intercept in adjacent tiles too? I'm not entirely sure about the mechanics.
Hi Solver. It would be helpful to the discussion if you specified which ones you want to include (so we don't have to flag our support of a won cause) and which ones you don't (so we can ask why and possibly see it from your side).
In the meanwhile...
...I feel #8 is the most important fix, but #1, #3, #4, #5, and #7 seems to be uncontroversial improvements that begs for inclusion too...
r_rolo1
King of myself
@Everest
Spoiler more theo discussion stuff :
DanF5771
Emperor
- Joined
- Feb 21, 2008
- Messages
- 1,194
Collateral Damage, again:
There are two ways to adjust the resulting HPs taken away from stack defenders via CollDmg according to the properties of the attacker:
1. Modify the attacker's strength before applying the long established non-linear core formula (which should not be changed).
2. Modify the result of the core formula.
The relevant properties of the attacker are:
A) its native Collateral Damage (current XML-values: 100 for all siege units and bombers, 50 for Cho-Ko-Nus and Battleships/Missile Cruisers, 0 for armored units)
B) the Barrage promotions (XML-values: 20, 30, 50)
In 3.13 both A) and B) were factored in via version 1 -- before the core formula.
This caused problems discussed at length in the 14pages thread "Is Barrage broken?". The major complaints were the lack of transparency and consistency, since the promotions had not the described and expected effect or no effect at all.
The reason is that the core formula works with integers which makes going route 1 very unfavorable (prime example BarrageI on Trebs: floor(4*1.2)=4).
So Firaxis considered route 1 for B) the promotions a bug and fixed it in 3.17 where they now modify the result of the core formula (route 2).
Result: Transparency + consistency achieved, Barrage promotions broken for Tanks.
This naturally poses the question: Why not fix this for A) the native CollDmg too?
Lets look at A), there are again two ways to interpret this property:
i) The attacker can only use a fraction of its fire power to collaterally damage stack defenders.
Consider a modded Tank that starts with a little native CollDmg of 20%, then this interpretation would mean the Tank loads its gun with boulders, since it would effectively represent a Catapult (floor(28*0.2)=5).
ii) The attacker damages a fraction of the stack defenders using its whole fire power.
1 Unit in Civ represents not one single soldier but a company/battalion, for simplicity let's assume 100 individual soldiers.
So this interpretation would let the Tank fire not boulders but its grenades or whatever which would only be able to damage 20 of these 100 soldiers, thus A) would be better described as a spread factor.
i) means route 1 with all the bad rounding issues whereas ii) means route 2.
My suggested code chooses route 2 for A) and B) which further increases consistency + transparency with regard to the according values in the XML-file:
Consider BarrageII Battleships, A=50 & B=50 means one would expect that the Barrage promotions would effectively make them strength 40 artillery.
But this is not the case when going route 1 for A) and route 2 for B) not only because of the rounding problems but mainly due to the non-linear core formula, they will come out even stronger.
Ok so for me route 2 for both A) and B) appears to be the most straightforward version, however it lowers CollDmg for Cho-Ko-Nus and Battleships (all units with A<100) compared to 3.13.
Provided the developers determined the XML-value of 50 to achieve perfect balance for their role in the game, then going route 2 would require to change A) for these units to a value of 70 in the XML.
Here the non-linearity prevents to achieve totally equal results, but A=70 leads to identity when fighting contemporary units with equal strength.
Cho-Ko-Nu vs Longbow:
3.13: 7 HPs
route 2, A=50: 5 HPs
route 2, A=70: 7 HPs
@ Solver:
So I found my code in version 0.17, cool!
Since you decided to go route 2 (did you really intend that?) which has iCollateralStrength = baseCombatStr() without the *collateralDamage() in your first line, this will render the exit check following this assignment effectless as well as the later conditional assignment of iCollateralStrength = baseCombatStr() / 2;.
Sorry English is not my first language, I hope I could nevertheless make my thoughts on this rather knotty subject somewhat comprehensible.
There are two ways to adjust the resulting HPs taken away from stack defenders via CollDmg according to the properties of the attacker:
1. Modify the attacker's strength before applying the long established non-linear core formula (which should not be changed).
2. Modify the result of the core formula.
The relevant properties of the attacker are:
A) its native Collateral Damage (current XML-values: 100 for all siege units and bombers, 50 for Cho-Ko-Nus and Battleships/Missile Cruisers, 0 for armored units)
B) the Barrage promotions (XML-values: 20, 30, 50)
In 3.13 both A) and B) were factored in via version 1 -- before the core formula.
This caused problems discussed at length in the 14pages thread "Is Barrage broken?". The major complaints were the lack of transparency and consistency, since the promotions had not the described and expected effect or no effect at all.
The reason is that the core formula works with integers which makes going route 1 very unfavorable (prime example BarrageI on Trebs: floor(4*1.2)=4).
So Firaxis considered route 1 for B) the promotions a bug and fixed it in 3.17 where they now modify the result of the core formula (route 2).
Result: Transparency + consistency achieved, Barrage promotions broken for Tanks.
This naturally poses the question: Why not fix this for A) the native CollDmg too?
Lets look at A), there are again two ways to interpret this property:
i) The attacker can only use a fraction of its fire power to collaterally damage stack defenders.
Consider a modded Tank that starts with a little native CollDmg of 20%, then this interpretation would mean the Tank loads its gun with boulders, since it would effectively represent a Catapult (floor(28*0.2)=5).
ii) The attacker damages a fraction of the stack defenders using its whole fire power.
1 Unit in Civ represents not one single soldier but a company/battalion, for simplicity let's assume 100 individual soldiers.
So this interpretation would let the Tank fire not boulders but its grenades or whatever which would only be able to damage 20 of these 100 soldiers, thus A) would be better described as a spread factor.
i) means route 1 with all the bad rounding issues whereas ii) means route 2.
My suggested code chooses route 2 for A) and B) which further increases consistency + transparency with regard to the according values in the XML-file:
Consider BarrageII Battleships, A=50 & B=50 means one would expect that the Barrage promotions would effectively make them strength 40 artillery.
But this is not the case when going route 1 for A) and route 2 for B) not only because of the rounding problems but mainly due to the non-linear core formula, they will come out even stronger.
Ok so for me route 2 for both A) and B) appears to be the most straightforward version, however it lowers CollDmg for Cho-Ko-Nus and Battleships (all units with A<100) compared to 3.13.
Provided the developers determined the XML-value of 50 to achieve perfect balance for their role in the game, then going route 2 would require to change A) for these units to a value of 70 in the XML.
Here the non-linearity prevents to achieve totally equal results, but A=70 leads to identity when fighting contemporary units with equal strength.
Cho-Ko-Nu vs Longbow:
3.13: 7 HPs
route 2, A=50: 5 HPs
route 2, A=70: 7 HPs
@ Solver:
So I found my code in version 0.17, cool!
Since you decided to go route 2 (did you really intend that?) which has iCollateralStrength = baseCombatStr() without the *collateralDamage() in your first line, this will render the exit check following this assignment effectless as well as the later conditional assignment of iCollateralStrength = baseCombatStr() / 2;.
Sorry English is not my first language, I hope I could nevertheless make my thoughts on this rather knotty subject somewhat comprehensible.
I'm in touch with the authors. We have similar goals to improve the AI, but their mod can afford more experimental changes than I can at the moment. Specifically,
This is a good thing to fix but the fix itself leads to rather complex consequences. The Better BtS AI guys haven't fully tested the results yet. I'll definitely want to include their fix as soon as its consequences are better understood.
I have included a fix for this bug.
Hi Solver. It would be helpful to the discussion if you specified which ones you want to include (so we don't have to flag our support of a won cause) and which ones you don't (so we can ask why and possibly see it from your side).
In the meanwhile...
...I feel #8 is the most important fix, but #1, #3, #4, #5, and #7 seems to be uncontroversial improvements that begs for inclusion too...
Generally speaking, the fixes from Bhruic's list will probably have to wait a bit longer. I'd need to look at Bhruic's code for it, no point redoing it myself, but I don't have 3.13 code to compare against at the moment. I actually like the changes after further consideration, though I do not want to include #6. That isn't how Theocracy was supposed to work, and that had also been discussed internally.
I didn't like #5 initially but now I figure it's a good change. The description of #7 is too vague. If that's a fix for the excessive forestation issue, good, I want to fix that. It's the exact changes that matter here.
EDIT: Oh and Dan, I have changed that stuff again. I went back to re-add *collateralDamage() to the initial formula to be closer to how it all was originally done. Which probably means that iModifier should again start at 100 with the extra damage added on later. Really, gotta run the maths on this myself.
I have finished a large epic-speed game with the setting on and I've not seen any adverse effects. I did notice that there were no ridiculous wars declared over the water where one civ never properly attacked the other. Of the 4 to 5 AI to AI war declarations they were all neighbouring civs (it was unfortunately a "relatively" peaceful game overall because of the geography).
I'm not really sure what the complex consequences of the change are but I guess for now I'll respect that decision. However assuming it is eventually shown to be an overall positive change you'd incorporate it into this patch wouldn't you?
It just seems such a significant bug discovery that something (whichever of the available options I don't mind) needs to be done about it.
Oh I didn't notice this in the changelog. Will this be in the next update or have you included it already without mention?
Thanks for putting the time and effort in for this patch by the way!
Did you make a typo with those numbers? You don't want to include #5 but you figure it's a good change in the next paragraph?
r_rolo1
King of myself
By context I would say that the first #5 is in fact #6 ( reference to Theo change in last Bh patch)
And Solver, #7 refers indeed to the forest spam bug ( I remember the discussion ) , and Given the reference to SevenSpirits, I would say that the code Bh used is the one that Seven Spirits posted in Bh thread in here and here,
And Solver, #7 refers indeed to the forest spam bug ( I remember the discussion ) , and Given the reference to SevenSpirits, I would say that the code Bh used is the one that Seven Spirits posted in Bh thread in here and here,
PieceofMind,
I'm a moron. That first #5 was meant to be #6, edited and fixed.
The defender bug should be in the changelog. Ah, there it is: "Fixed AI defender bug for newly captured cities."
As for AI player closeness, don't worry. We're on the same page, I also think it's a very important thing to fix so I will definitely be including it. But the AI war declaration code is quite complex, it's still possible there there are negative consequences to it. For example, testing needs to ensure that the fix doesn't mean that the AI would never declare on a faraway civ, so you can't be assured of never being invaded if you're on a separate landmass. I'm following the situation
With collateral, I am currently considering the following after running some Python simulations (relevant parts only):
According to Python, for non-native collateral units it'd result in lower damage than 3.13 but not obscenely low. The complex condition for the initial value of iModifier will allow it to stay at 100 + extra damage for siege units, while the second part seems okay so far for non-native collateral units.
I'm a moron. That first #5 was meant to be #6, edited and fixed.
The defender bug should be in the changelog. Ah, there it is: "Fixed AI defender bug for newly captured cities."
As for AI player closeness, don't worry. We're on the same page, I also think it's a very important thing to fix so I will definitely be including it. But the AI war declaration code is quite complex, it's still possible there there are negative consequences to it. For example, testing needs to ensure that the fix doesn't mean that the AI would never declare on a faraway civ, so you can't be assured of never being invaded if you're on a separate landmass. I'm following the situation
With collateral, I am currently considering the following after running some Python simulations (relevant parts only):
Code:
iCollateralStrength = ((((getDomainType() == DOMAIN_AIR) ? airBaseCombatStr() : baseCombatStr()) * collateralDamage()) / 100);
if (iCollateralStrength == 0 && getExtraCollateralDamage() == 0)
{
return;
}
if (iCollateralStrength == 0)
{
iCollateralStrength = baseCombatStr() / 2;
}
iStrengthFactor = ((iCollateralStrength + iTheirStrength + 1) / 2);
iCollateralDamage = (GC.getDefineINT("COLLATERAL_COMBAT_DAMAGE") * (iCollateralStrength + iStrengthFactor)) / (iTheirStrength + iStrengthFactor);
int iModifier = getUnitInfo().getCollateralDamage() > 0 ? (100 + getExtraCollateralDamage()) : (iCollateralStrength * getExtraCollateralDamage() / 10);
iModifier *= (100 - pBestUnit->getCollateralDamageProtection()) / 100;
if (pCity != NULL)
{
iModifier *= (100 + pCity->getAirModifier()) / 100;
}According to Python, for non-native collateral units it'd result in lower damage than 3.13 but not obscenely low. The complex condition for the initial value of iModifier will allow it to stay at 100 + extra damage for siege units, while the second part seems okay so far for non-native collateral units.
Roland Johansen
Deity
Note that trying to approximate the damage output that barrage tanks did in 3.13 isn't the right goal to achieve. The effect of barrage promotions were specifically changed in 3.17 so that they more closely do what the civilopedia description says they do.
In 3.13 a barrage 3 artillery didn't do double the damage of an unpromoted artillery like you would expect (+100% collateral damage), but it did something like 50% extra damage. This weird behaviour is due to the non-linear effect of strength on the collateral damage and the barrage promotion was applied to the strength of the collateral damage attack instead of adding the damage to the normal collateral damage of the unit.
So in 3.17, artillery do normal damage when unpromoted, 120% of normal damage when promoted with barrage I, 150% of normal damage when promoted with barrage II and 200% of normal damage when promoted with barrage III.
For consistency and so that the promotion does what you'd expect, unpromoted tanks should do 0% of normal collateral damage, barrage I tanks should do 20% of normal collateral damage, barrage II tanks should do 50% of normal collateral damage and barrage III tanks should do 100% of normal collateral damage (where normal collateral damage is equal to a collateral damage attack with the strength score of the unit). That is what you would expect that the promotion does. It means that a barrage III tank does twice the collateral damage of a barrage II tank, exactly like you would expect.
If you apply the barrage promotion directly to the strength of the unit, then the barrage promotions won't do what the civilopedia says they do. The behaviour of the barrage promotions will not be intuitive.
It can never be really intuitive with non-native collateral units. If Barrage I gives you 20% more collateral damage, 20% more of 0 is still 0, and Tanks have an inherent collateral value of 0. Yuck. One of the reasons why Barrage promotions do not belong on armored units.
My simulations suggest, though, that it would now work linearly as expected. Tank vs. a Longbow, if Tank has
20% extra collateral: damage is 4
40% collateral: damage 8
80% collateral: damage 16
My simulations suggest, though, that it would now work linearly as expected. Tank vs. a Longbow, if Tank has
20% extra collateral: damage is 4
40% collateral: damage 8
80% collateral: damage 16
Solver,
By the way, is the Glance screen re-enabled in this patch? If not can you please include that? Cheers
Ah silly me. Didn't realise that was the same bug.
Though I mentioned this in the Better BTS AI thread already, there was one overseas attack on me but it was pretty underwhelming. I could post the replay file if you wanted to see an example of the game flow with that change (this was v0.1 of their patch).As for AI player closeness, don't worry. We're on the same page, I also think it's a very important thing to fix so I will definitely be including it. But the AI war declaration code is quite complex, it's still possible there there are negative consequences to it. For example, testing needs to ensure that the fix doesn't mean that the AI would never declare on a faraway civ, so you can't be assured of never being invaded if you're on a separate landmass. I'm following the situation
By the way, is the Glance screen re-enabled in this patch? If not can you please include that? Cheers
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.
r_rolo1
King of myself
I would say to resurrect it ( after all it is just commented out ). No one is forced to look at it anyway....
Refar
Deity
- Joined
- Apr 10, 2005
- Messages
- 4,608
I think with the new "Worst Enemy" display in the mouseover info, we could live without...
The glance screen of course had more information than just this, but the most vital thing was to know who hates who... At least it was to me.
EDIT: R_Rolo is of course right, about it does not harm anybody if it's resurrected.
Just don't feel that missing it now is as much of a loss as it was before.
The glance screen of course had more information than just this, but the most vital thing was to know who hates who... At least it was to me.
EDIT: R_Rolo is of course right, about it does not harm anybody if it's resurrected.
Just don't feel that missing it now is as much of a loss as it was before.
Similar threads
