Solver's unofficial BtS 3.17 patch

There are two bugs that we've fixed in the Better BTS AI mod which would probably be appropriate for your efforts as well. First, the easy one:

In CvCityAI::AI_neededDefenders the AI will decide it doesn't need as many defenders if a recently captured city either does not have a wonder or is a holy city. Clearly this is meant to be no wonder and not a holy city.

The second bug is definitely a bug, but creating the right fix is not so simple. In CvPlayerAI::AI_playerCloseness the AI is meant to determine how close its cities are to another player's cities. Instead, it compares how close the other player's cities are to the other player's cities. This is essentially the self-closeness for the other player and is always > 0 if the player has a city, even if they're on the other side of the world.

Correcting that loop is easy enough, but it has serious ripple effects. Closeness is intended to have a very strong effect on war decisions in BTS as the code in CvTeamAI::AI_startWarVal attests. If closeness is zero, the value the AI assigns to that particular victim is / 4. Without the above fix, closeness is never zero since it's actually the other player's self-closeness so in effect this fix opens up new AI behavior which (until the last week or so) has never been tested. We've got several tweaks to adjust this behavior in the Better BTS AI mod ... if you choose to include this fix I would highly recommend adding the tweaks to CvTeamAI::AI_startWarVal as from our testing they produce good results.

We also have some changes in CvCityAI::AI_cachePlayerCloseness, a small one dealing with populations and larger ones which are still in progress to better handle coastal cities and cities on other nearby islands. Both of these fix some quirks in AI behavior which don't really make sense but could not be classified as bugs (as I mentioned, the second fix isn't complete yet). See the discussions here (called Fix C) and here for better descriptions.

There's also a change in CvCityAI::AI_chooseProduction to reduce galley/transport overproduction.

The full change list for Better BTS AI v 0.1:
_________

- 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
- Modified how closeness is used for determining who to attack, different settings for regular and Aggressive AI
- Modified city closeness calculations to use population from both cities, not just pop of the other city
- Created functions for determining when cities share the same water area (lake, ocean)
- Lowered demand for transports when either in a land war or when the civ can only build galleys
- Partial implementation of a new A* solver for determining closeness, does not yet affect calculations
- Modified debug mode output to show relevant information for these developments

Anyway, thanks for again spearheading the unofficial patch efforts! I'll let you know if we find any other real bugs in the AI code during our developments and will certainly fold your fixes in.
 
Yeah I'd seriously give the changes a look at Solver. I think the Better BTS AI seems to return the entire behaviour of warfare back to how I imagine it was intended with regional and border warfare more dominant especially in the middle ages, with very few nonsensical war declarations now. What a great achievement the AI is once you fix the "bug" regarding the closeness calculation and include the ripple effect changes as Jdog has discovered are necessary.

The only real immediate "balance" issue I *think* is needed is that once a border war has been declared in the middle ages, the offensive city attack strength of stacks are a little down on what they should be but only on aggressive ai. On aggessive/monarch, the AI border war stacks seem to succeed less often than on standard settings. It's almost like on aggressive ai, the border war should be postponed until an extra attacker is included for the proposed stack. On standard it seems to be good at least on Monarch.

It is very cool now the BTS AI. Much more colour in the game from my humble perspective and a pity it didn't make it in time for the 3.17 patch. Yakk and Jdog only found the bug what ten days ago!

That's not to say that there isn't a lot more "improvements" that could be added under the Better BTS AI side of things. the AI does do a lot of "dogpiling" on poor innocent little civs and it would be nice to see other types of war plans emerging like pre-calculated cascading wars but at least now it makes sense a lot more often and there are some nice cascading effects anyway...

Cheers.
 
Solver, alexman mentioned that his idea of fixing the barrage bug was to remove the Barrage promo our of armored units.... IMHO that is not a good idea, because it doesn't solve the ships problem with that. Or barrage is going to be a siege only promo? :(
 
When checking if an event can be triggered, and looking for the unit that can trigger the event, the method PickTriggerUnit (in CvPlayer.cpp) has an error; it loops all the units using the LoopUnit variable, but when returning the value it uses another variable, that is never used and is always null. As a conclusion, the event is never triggered.
More work for Solver ;)
 
Hi Solver,

Could you fix the "forest-spam" bug that's been around forever, please? I pointed it out to Bhruic some time ago, and he said he was already aware of it, and I also submitted it to Firaxis, but it's still not fixed....

In the normalizeAddExtras function in CvGame.cpp, there's an "if" clause that's been commented out, causing many start locations to be forested on every single non-resource tile in the fat cross that can support a forest. In vanilla and Warlords, this clause was in effect, such that start locations would receive a modest, random number of added forests; plus the variable iCount is not used anywhere else; to me, it's clear that commenting out this line in BtS was inadvertent.

Compute a threshold for starting location quality at 80% of the best starting location.
For each civ, if it is below that threshold
__iCount = 0
__For each plot in the fat cross
____//If SorenRandNum test based on iCount
____If plot does not have a bonus resource, and isn't the center plot
______Add a forest if possible
______iCount++
____}
__}

There's a second bug just below it, too:
__iWaterCount = 0
__for each plot in the fat cross
____iWaterCount++
____if isWater()
______check for water resources
____else
______check for land resources
____}
__bLandBias = (iWaterCount > MAX_NUM_TILES/2)
__Add resources to tiles that can support them, until value > the 80% threshold established earlier, or until (2*waterResources + 3*landResources) >= 12
}

iWaterCount++ clearly belongs inside the isWater() test. As written, iWaterCount will always add up to MAX_NUM_TILES - 1, and bLandBias will always be true. bLandBias exists to encourage addition of land resources to water-heavy capitals.

thanks for your attention,
lilnev
 
Solver,

I'd like to submit something to you for consideration for your unofficial patch. While not a bug per se, this is something that has bugged me (no pun intended) since the release of BtS.

In BtS, Firaxis added the feature to the civilopedia that when you click on a unit, you are shown the UU's that that unit is replaced by. For instance, if you click on Axeman, you will see Replaced by Vulture and Replaced by Phalanx with links to jump to those respective entries. It's a nice enhancement, but for some reason they didn't extend this over to the UB's as well. I am a newb coder, but I was able to edit CvGameTextMgr.cpp and extend this to UB's very easily.

If Firaxis didn't include this for the UU's, then I wouldn't even be bringing it up here. However, because they did do it for the UU's, it seems like an oversight that they didn't do it for the UB's. I can't think of a reason they would have made this distinction on purpose.

Anyways, if you need the fix, PM me, but I figured it out in about 5-10 minutes and it should be apparent to you quickly how to fix if you want to add it.

Cheers,
ripple01
 
ViterboKnight said:
When checking if an event can be triggered, and looking for the unit that can trigger the event, the method PickTriggerUnit (in CvPlayer.cpp) has an error; it loops all the units using the LoopUnit variable, but when returning the value it uses another variable, that is never used and is always null. As a conclusion, the event is never triggered.
More work for Solver ;)
Dunno where you got that quote, or what VK is referring to. I looked at the code.
pUnit = apUnits[iChosen]; And the method PickTriggerUnit returns pUnit.
 
Thanks for the reports everyone, I will be looking at that batch later.

About the worst enemy spoiler info thing - I'll be looking into it, but a save is still good if anyone has it. I can't easily recreate the behaviour.

About better BtS AI - I will certainly be looking at what you guys did with AI estimation of closeness for wars. AI improvements are something I want to have in this patch and if I actually stop sucking I'll include some of my own, hopefully. I'm pretty conservative, though, and don't want to include stuff that is too experimental, this patch is almost intended as mainstream, but I look forward to woking with better BtS AI.

PieceofMind, that issue probably isn't relevant. If I understand correctly, 3.17 only changed the capitulation stuff, not things about peaceful vassalage.

Methos, nope, I won't be including comments in the code to highlight where my changes are. If using Windows, I recommend the WinMerge tool.

Given that there are some questions about how to install, should I maybe also create an installer for this thing?
 
Hi Solver!

When it comes to replacing roads with railroads, is it possible to get the workers on auto-trade networking to prioritise connecting cities with each other, rather than railroading to resources that already have roads and thus are already connected? I mean what difference does the railroad do to a rice farm? It is much better to get improved troops transportation capabilities asap, IMO.

Ciao!
 
my workers in official 3.17 have build fort on the oil resource (i didn't have combustion yet), does your patch fix that? :>
 
Given that there are some questions about how to install, should I maybe also create an installer for this thing?
I'd rather leave it as-is sans installer. I'm sure the modding community would like to know exactly what is included with the patch and what is going where, then the "magic" installer mysteriously dumping stuff Lord knows where.

Either leave it as-is, or perhaps offer both an installer and a non-installer version.
 
my workers in official 3.17 have build fort on the oil resource (i didn't have combustion yet), does your patch fix that? :>

They did that in 3.13 as well, there is nothing buggy about it. You won't have access to oil until you reserach combustion. AFAIK, automated workers always build forts over resources outside the BFC.
 
Oranges is correct.

Another question to the lot of you: what to do with Tanks and Barrage? The current implementation makes Barrage work again, but it does quite little damage. Basically, the possibilities are:

1. Leave as is now. You can promote Tanks with Barrage and they'll do collateral damage, though very little of it. I don't much like it - the amount of damage is so low that you'd be better off grabbing another promotion instead.

2. Increase collateral damage by Barrage-promoted Tanks. Make it less than contemporary siege weapons but certainly not as poor as Classial era siege. I'm not a big fan of this either, Tanks are already plenty powerful.

3. Remove access to the Barrage line of promotions for armored units. They're powerful enough even without that ability, and we have Mobile artillery units to serve as fast moving collateral damage doers. My code fix would still allow people to mod in units without collateral damage that can get access to working Barrage promotions - this is pretty much what I would lean towards.
 
Any chance that the AI can be 'taught' to actually blockade? Right now they might do it for a turn or two but the AI ships seem very ADHD and just wander off or bombard cities that will never be attacked.

The whole blockade feature is extremely well done for BtS and really encourages you to build a navy, but if the AI is incapable of using it properly (which it seems to be at the moment) then its just another advantage that human players get that the AIs dont share.

I had some hopes that after all this time the 'official' patch would tweak the AI to fix this. But unfortunately, it appears that this has not been addressed. Any chance the 'unofficial' patch could eventually cover this?

Thanks for all your effort!
 
Honestly, I don't see why ships should do collateral damage. Gives a purpose to Subs & the Missile Cruiser, plus theres Carriers and (Jet) Fighters. I certainly wont miss Ship/Tanks collateral damage. Theres enough ways to nerf a stack.

Unless missiles aren't doing collateral damage either... ?
 
Top Bottom