Version 0.36 Discussion Thread

[jdog5000]

You can always get the latest stable release here at CFC or sourceforge. Development versions can also be checked out from sourceforge.

Version 0.36 fixes a bunch of bugs found by the community with BTS and the unofficial patch, including immunity to collateral damage, spread culture espionage mission, and civs refusing to switch to Emancipation instead of out of it.

Better BTS AI v0.36 Changelog
_________________________

Spoiler :

Bugfix
- Fixed bug in player closeness calculations causing the AI to be blind to its actual proximity to other players
- Fixed bug with needed defenders where the AI would choose to defend a recently captured holy city less than a normal city
- Fixed bug causing player ID to be used in place of actual attitude when checking for denials in bonus, civic, and religion trading
- Fixed bug in paradrop code causing AI to avoid paradropping onto terrain bonuses under certain circumstances
- Fixed bug in AI denial of switching civics when in Emancipation
- Fixed bug introduced in unofficial patch causing immunity to collateral damage
- Fixed bug with espionage mission to spread culture to an enemy city
- Fixed bug causing combat promotions to be counted twice for aircraft

War strategy AI
- Modified how closeness is used for determining who to attack, different settings for regular and Aggressive AI
- Created new function CvTeamAI::AI_calculateBonusWarValue so AI will consider declaring war for resources, weighted towards resources AI doesn't have and plots that are more easily captured
- Modified city attack targetting by terrain bonuses to consider how important bonus is to AI

City AI
- AI will now more likely fill empty transports when enagaged in transcontinental war, making reinforcements and second waves on invasions more likely
- When doing invasions, AI will now be more likely to have cities with free air experience fill vacancies on carriers
- When doing invasions, AI will now have cities with high production or free sea experience more often fill needs for aircraft carriers
- When doing invasions, if AI has at least 50% of its possible missile capacity it will no longer always build missiles

Espionage AI
- Blocked out places for future changes

Naval AI
- Modified bombard behavior. Priority remains on supporting player's ground troops, if none then consider supporting other troops with common enemy and spreading out stacks to increase reach of blockade.
- Modified and expanded Solver's changes to retreat from city/fort AI to be more specialized for various unit AI types, only move if there's a real threat
- Increased city danger threshold so enemy ships do not runaway so easily
- Damaged ships will stay in city unless city is highly threatened

Air AI
- Modified and expanded Solver's changes to retreat from city/fort AI to be more specialized for various unit AI types, only move if there's a real threat
- Increased city danger threshold so enemy aircraft do not retreat so easily
- Attack planes in endangered cities will now more likely to airstrike attackers
- Improved code for defense planes in endangered cities so they stay to defend longer and either airstrike or patrol
- Improved efficiency of danger threshold check for ships and planes
- Improved code for moving planes to offensive or defensive bases to take city threat into account
- AI bombers will no longer consider basing in undefended forts even if the fort is unthreatened
- AI bombers will now consider moving to a city with two defenders (down from requiring 3), change made because of added threat logic and should allow AI to now use almost all of its cities as airbases
- Fixed bug introduced in Unofficial Patch 0.19 causing bombers to skip their turns whenever an interceptor was around

Barbarian AI
- Barb ships will now often blockade cities for a few turns before moving on if they have no nearby targets
- Barb ships trapped by ice or around 1-tile islands are now removed so more can spawn

General 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)
- Partial implementation of a new A* solver for determining closeness, does not yet affect calculations

Combat Mechanics
- Blocked out location for potential changes to air combat

Debug
- Added SDK and adapted python code from AIAutoPlay mod to faciliate testing
- Modified debug mode output to show relevant information for these developments
- Added string to lower right flag help text showing Better BTS AI version number currently running
- Added SDK and adapted python code from ChangePlayer mod to facilitate testing

Better BTS AI also includes Solver & Dresden's unofficial 3.17 patch version 0.19.1.

The main open questions for the next version are:

- how to change AI espionage point spending so it is more proactive

- how to change combat mechanics for air battles to make combat experience more important in establishing air superiority

- investigating issues with AP/UN voting

 

[Dresden]

Oooh update. Nice. I have a couple of comments from looking at the changelog and code. (Haven't been able to test it yet myself)

including immunity to collateral damage,

It looks like only half the fix was applied.

11597 				int iModifier = getUnitInfo().getCollateralDamage() > 0 ? (100 + getExtraCollateralDamage()) : getExtraCollateralDamage();
11598 				/********************************************************************************/
11599 				/**		BETTER_BTS_AI_MOD						8/16/08		DanF5771 & jdog5000	*/
11600 				/**																				*/
11601 				/**		Bugfix																	*/
11602 				/********************************************************************************/
11603 				//iModifier -= pBestUnit->getCollateralDamageProtection();
11604 				iModifier *= (100 - pBestUnit->getCollateralDamageProtection());
11605 				iModifier /= 100;
11606 				/********************************************************************************/
11607 				/**		BETTER_BTS_AI_MOD						END								*/
11608 				/********************************************************************************/
11609 
11610 				if (pCity != NULL)
11611 				{
11612 					//iModifier += pCity->getAirModifier();
11613 					iModifier *= (100 + pCity->getAirModifier()) / 100;
11614 				}

That second iModifier assignment on line 11613 needs the same fix applied. The one on lines 11604/11605 is for things like Drill promos; the one on 11613 is for things like the Bunker and both had the same problem in Solver 0.19.

spread culture espionage mission

I noticed your fix was slightly different than mine. You changed the divisor from 10000 to 100 while I changed the changeCultureTimes100() calls to changeCulture(). The difference is pretty minor but I was curious how the plot culture reacted in your tests. Your method will "front-load" the culture a little bit more, by which I mean it'll add more during the loop when the plots are being updated and then less on the final call at the end to reach the same total. After my tests, there was some concern that the plot culture gains might be a little too good so I wanted to make sure it doesn't get any worse with this method. The difference may very well be too small to matter but it's something I'm sensitive to. Along those same lines, now that a wider audience gets to try out this change, tests might show that we might need to scale back the plot culture by lowering iNumTurnsApplied. So that's something to keep an eye on.

 

[Pep]

I've done several modifications to this mod to include:

• new unit orders
• new mass efects to existing orders
• standard movement behaviour changes
• new game options
• bug fixes

You can download it from:
http://forums.civfanatics.com/showthread.php?t=287729

The new orders and options are interface enhancements beyond Better BTS AI scope, but if you like, you can take a look to the bug fixes to include them in a new version of Better BTS AI:
http://forums.civfanatics.com/showthread.php?t=286855
http://forums.civfanatics.com/showthread.php?t=286367

I have a question for you, jdog5000. Which C++ environment do you use to compile Better BTS AI?. I'm currently using:

• Code::Blocks v8.02
• Microsoft Visual C++ Toolkit 2003
• Microsoft Platform SDK for Windows Server 2003 SP1

I have noticed my linked dll is bigger than yours. It takes me about 15 minutes to recompile it in a Q6600 processor, and it only uses one of the four cores (at 100%) to compile it. Do you know how to enable multithread compilation?

 

[jdog5000]

@Dresden:

Thanks for double-checking things! I think the only difference for the culture methods is rounding ... CvCity::changeCulture multiplies the change amount by 100 and calls the same CvCity::setCultureTimes100 function. Dividing by 10000 and then multiplying by 100 just drops the fractions of culture point compared to just dividing by 100.

@Pep:

I'm fortunate to have access to MS Visual Studio 2003 (what Firaxis used...). I've also used Visual Studio Express 2005 with good results. The size of the DLL doesn't much matter, it's just how thorough the optimization routine is (and whether you're invoking it ... usually -O2 or something).

I don't know about multicore support ... VS 2003 doesn't seem to do it at least by default, but there weren't as many multi-core machines back then either.

 

[DanF5771]

Hi guys! Have you encountered any worrying side effects after your fix of the self-closeness bug in CvPlayerAI.cpp::AI_playerCloseness()? Is there still a discussion going on about that?
While working through AI_doWar to understand what's going on when the AI decides to change war plans, I also found that the self-closeness causes instant paranoia after first contact, which makes the AIs drop the strategy Peace and favor Dagger instead--this might provoke earlier DoWs. So have you experienced longer periods of peace in the beginning of the game with your fix?

Another minor(?) bug I found in CvPlayerAI::AI_getStrategyHash() might also be interesting for your AI pimping :
Here bHasMobileAntiair and bHasMobileArtillery are set to true if the AI can build Destroyers in their capital. What I've seen so far is that this leads to:
a) inconsistencies for coastal/land-locked capitals
b) if the strongest offensive unit currently available has >1 moves (Cavalry and no Artillery, Tanks) which means FastMoves is a valid strategy, LandBlitz becomes valid too
c) LandBlitz is likely to prevent AirBlitz, even when the AI can build Bombers
d) LandBlitz halves the AircraftNeed in CvCityAI::AI_chooseProduction() and has furthermore a major effect in this statement:
airUnitTypes.push_back(std::make_pair(UNITAI_DEFENSE_AIR, bLandBlitz ? 100 : 100))
Overall I doubt Destroyers are the weapon of choice for a Blitzkrieg on large landmasses. So I think there should also be a check for the unit's domain implemented.

Keep up the good work.

 

[jdog5000]

The correction to the self-closeness bug has proven to be quite good in terms of picking civs to attack, there isn't really an discussion going on that anymore.

Player/team closeness is only used in a couple of places other than picking war victims, both are in AI_getStrategyHash like you point out. The "Peace" strategy is not implemented at all, it has no effect on AI decisions what so ever.

I hadn't noticed the indirect effect of closeness on the use of "Dagger", thanks for bringing that up. I think this is actually a positive effect though, here's why: Dagger only works in early eras (up to 2 or 3 depending on random variable), so iParanoia will be >= 0 so long as there's one other civ with a city near the player's territory to which the player is < Pleased. With the bug fix the AI will now only run dagger when it has a potential victim nearby. Dagger negatively affects growth and research at the expense of military build-up, I think putting off dagger when there's no nearby target is the intended behavior.

As for the bHasMobileAntiair and bHasMobileArtillery issue you were looking at, I don't think it's actually a bug ... there's a check for what UNITAIs the unit can run and all the UNITAI types that are acceptable only apply to land units. It's an easy thing to miss, but in this case Firaxis' code seems fine to me. Keep hunting around though!

 

[DanF5771]

Dagger negatively affects growth and research at the expense of military build-up, I think putting off dagger when there's no nearby target is the intended behavior.

I agree and think the unnecessary unit spamming might partially be responsible for those ultra early DoWs on Deity level. Daggers don't oppose a war when they are in financial trouble and care less about friends. The many units combined with a low focus on growth will increase the HighUnitSpendingPercentage dramatically and this will in turn make TotalWars muuuuch more likely (Factor 10+!).

As for the bHasMobileAntiair and bHasMobileArtillery issue you were looking at, I don't think it's actually a bug ... there's a check for what UNITAIs the unit can run and all the UNITAI types that are acceptable only apply to land units. It's an easy thing to miss, but in this case Firaxis' code seems fine to me. Keep hunting around though!

I wasn't concerned about the UNITAIs but more about what kind of units the cities choose to produce. LandBlitz lowers the AircraftNeed by 50% and if it prevents AirBlitz by 67%. I noticed quite a few threads that complained about the AI's lack of a focus on Air units in the late game, so I thought it might be related to the wrong LandBlitz strategy...
Plus a fix is very easy and would erase the inconsistency for coastal vs land-locked capitals.

 

[jdog5000]

I wasn't concerned about the UNITAIs but more about what kind of units the cities choose to produce. LandBlitz lowers the AircraftNeed by 50% and if it prevents AirBlitz by 67%. I noticed quite a few threads that complained about the AI's lack of a focus on Air units in the late game, so I thought it might be related to the wrong LandBlitz strategy...
Plus a fix is very easy and would erase the inconsistency for coastal vs land-locked capitals.

I understood the potential bug you were seeing as bHasMobileAntiair or bHasMobileArtillery being set if a civ's capital can build destroyers ... but this is not the case because:

for (iI = 0; iI < GC.getNumUnitClassInfos(); iI++)
{
	eLoopUnit = ((UnitTypes)(GC.getCivilizationInfo(getCivilizationType()).getCivilizationUnits(iI)));
	
	if (NO_UNIT != eLoopUnit)
	{
		if (getCapitalCity() != NULL)
		{
			if (getCapitalCity()->canTrain(eLoopUnit))
			{
				CvUnitInfo& kLoopUnit = GC.getUnitInfo(eLoopUnit);
				bool bIsUU = (GC.getUnitClassInfo((UnitClassTypes)iI).getDefaultUnitIndex()) != (GC.getCivilizationInfo(getCivilizationType()).getCivilizationUnits(iI));
				if [B](kLoopUnit.getUnitAIType(UNITAI_RESERVE) || kLoopUnit.getUnitAIType(UNITAI_ATTACK_CITY)
					|| kLoopUnit.getUnitAIType(UNITAI_COUNTER) || kLoopUnit.getUnitAIType(UNITAI_PILLAGE))[/B]
				{

Only units that use one of those UNITAIs can cause the bHasMobileAntiair or bHasMobileArtillery flag to be set. Destroyers and other sea units have _SEA type UNITAIs, so they will never cause the flags to set which influence the choice of land vs air blitz.

There is no issue with landlocked vs coastal capitols that I can see.

 

[DanF5771]

Sorry, but no. The indentation in this section of the code of AI_getStrategyHash is rather messy and misleading--it took me a while to figure out what is going on.
The restriction to the UnitAIs RESERVE, ATTACK_CITY, COUNTER and PILLAGE is only used for the fast-vs-slow check for offensive land units. Both the LandBlitz and AirBlitz check are outside of that block which actually only makes sense for AirBlitz and Bombers (only UNITAI_ATTACK_AIR) as MobilSAMs (UNITAI_COUNTER, UNITAI_CITY_COUNTER, UNITAI_CITY_SPECIAL) and MobileArty (UNITAI_ATTACK_CITY, UNITAI_COLLATERAL) could/should be taken into account within the block too to set the respective flags. But outside of it and due to the missing domain check now Destroyers become the perfect LandBlitz units (if the capital is coastal and can build them plus the strongest offensive unit currently available is a fast mover [Cav before Arty or Tanks]).

 

[jdog5000]

Ah, you're right ... nasty indents there.

Changes have been checked in to sourceforge.

 

[Ninja2]

I know that 0.37 is out -- I haven't updated to it yet -- but I don't think has been adressed:

Using autoplay, I was looking the AI do the first 100 turns. One thing which struck me, was that immediately after founding city number 2 (which was guarded by the accompanying warrior), the city AI, at size 1, decides to build a settler. On completing the settler, it then built an axeman (the defending warrior was upgraded to an axeman). Only on completing the new axeman would the settler leave the city with its escort. Obviously, it would make a lot more sense if it had built the escort FIRST, while the city grew to size 2, and THEN built a settler.

What do you think? Not a bug, but certainly not smart decisions by the AI either.

 

[Cybah]

you will notice the advisor will often give you the advise to build a settler first. ;-) there is a different mechanism imo.

the advise to build a settler appears - or the AI will build a settler - when it seems that you/the AI have/has not enough land compared with the other players. I think, there is no "escort" AI which works together with a "settler building" - AI.

 

[Ninja2]

I know there's no escort AI for land units. But settlers don't go around unescorted, that's why I wrote it like so. Regardless, it is always a poor decision to build a settler from a size 1 city, and then have that settler wait for the size 1 city to build an escort.

 

[phungus420]

Unless something has been changed, the build adviser is different then what the AI's build orders. If you enable cheat code, and press ctr + z, you can see what the AI is building, and it does not build settlers first. I've never checked it on diety though, you could check that, but on levels below diety it always builds a worker then a unit first, always.

 

[Ninja2]

Unless something has been changed, the build adviser is different then what the AI's build orders. If you enable cheat code, and press ctr + z, you can see what the AI is building, and it does not build settlers first. I've never checked it on diety though, you could check that, but on levels below diety it always builds a worker then a unit first, always.

I think this was on noble or prince. This didn't happen in the capital, mind you, it happened in the second city founded.

 

[Yakk]

Without the settler, it is hard to store the state that a unit should be escorting a settler that isn't yet built...

That would be interesting however. Route potential escorts to cities that are building settlers on an "escort" mission that sits around and waits for the settler to be finished, then the settler searches the current city for an ungrouped escort unit and poaches it.

 

[Dresden]

The correction to the self-closeness bug has proven to be quite good in terms of picking civs to attack, there isn't really an discussion going on that anymore.

I'm finally going to add this fix into the Unofficial Patch so I want to make sure I do it right. Is CvPlayerAI::AI_playerCloseness() the only thing which needs to be changed or are adjustments needed too?

 

[glider1]

@Dresdon
There are other changes regarding player closeness (not many). I can assist if Jdog is not around. Do you realise that Better BTS AI is at version 0.37?

Good idea to add the fix to the unofficial patch. I have not seen one single complaint and it has had rounded approval.

Cheers.

 

[Dresden]

@Dresdon
There are other changes regarding player closeness (not many). I can assist if Jdog is not around. Do you realise that Better BTS AI is at version 0.37?

Good idea to add the fix to the unofficial patch. I have not seen one single complaint and it has had rounded approval.

Cheers.

If you could detail the other changes needed that'd be fine. I do realise there's a newer version of BetterAI (and I copied the CvPlayerAI::AI_playerCloseness() changes from the current SVN) but since the player closeness fix was introduced in this version and the very important "has proven to be quite good" quote from jdog was in this topic, it seemed sensible to continue the discussion here.

 

[glider1]

@Dresdon
Just a bit of history on the player closeness bug. It was the BUG that started the whole Better BTS project in essense. The bug was found one week before BTS 3.17 was released. You will find the very meat of the discussion about the bug find in Bhruic's 3.13 patch forums.

Ok as far as I remember, the critical changes required for the closeness bug fix are:
CvTeamAI::AI_startWarVal - Team closeness has to be adjusted for the corrected closeness calculation.
CvPlayerAI::AI_playerCloseness - This is the very heart of the bug find itself.

There is a related adjustment to the closeness calculation that is not absolutely required but is advisable. Jdog notes it in the readme for Better than BTS as:
General AI: "Modified city closeness calculations to use population from both cities, not just pop of the other city"

You will find that fix at:
CvCityAI::AI_cachePlayerCloseness
// Weight by population of both cities, not just pop of other city

You will see the before equation commented out and the Better BTS change after it. Basically it alters the weights for intercity closeness. It is not technically part of the closeness bug fix itself. If you want a detailed read on all this, go back to the Bhruic patch 3.13 forum and search for "playercloseness" or the like. Jdog and Yakk branched off to the Better BTS forum after concluding work on this bug.

Thanks for your continuing efforts on the unofficial patch. It is great work.
Cheers.