Specific Bug Reports

[phungus420]

This save is for the current version of LoR available on the SVN. When you press enter the AI leads it's city assault with it's Melee units, then finishes up the attack with it's battering rams, which is the reverse order in which it should do it. I realize this is a modded example, but it pertains to basic AI judgement. The AI should initiate city assaults with units that cannot capture or that cannot kill units, and should then finish up with it's main attacking units that can both capture cities and kill units.

There is actually quite a bit of behavior that goes wrong with the AI that is highlighted with LoR, some of which will effect basic BtS. Mainly is the AI's selection of a unit that it attaches a warlord to if it decides to attach a Warlord rather then settle the great general. The AI still commonly picks units that cannot kill units, this should not occur. It's possible to just remove the Leadership promotion from siege units, but this isn't the prefered aproach, just putting in a check to make sure that a unit can do 100% damage (ie it can kill a unit) would be good enough to stop this. Also in LoR it's common for the AI to get a Great General and attach it to a random catapult, when a legendary unit that's fully 2 strength higher, plus some free promotions, and various other bonuses are right there just asking to be led by a warlord. Please take a look at AI GG logic, and add some improvements to the unit selection process the AI goes through when it decides to attach a warlord.

Also the AI will spend hundreds of hammers on a legendary unit, then have it wander off and die alone in enemy territory; it also does this with high level units in general in BtS. Is there any way to add in some high value unit protection logic so that high value units are kept in stacks, and do not lead assaults if other decent attackers are present?

 

[Afforess]

Is there any way to add in some high value unit protection logic so that high value units are kept in stacks, and do not lead assaults if other decent attackers are present?

Yes, the AI simply doesn't recognize the need to protect level 5+ units, and is hurt when facing other humans who do. I would love to see the AI be a bit more protective about units.

 

[jdog5000]

This save is for the current version of LoR available on the SVN. When you press enter the AI leads it's city assault with it's Melee units, then finishes up the attack with it's battering rams, which is the reverse order in which it should do it. I realize this is a modded example, but it pertains to basic AI judgement. The AI should initiate city assaults with units that cannot capture or that cannot kill units, and should then finish up with it's main attacking units that can both capture cities and kill units.

The AI does boost the sacrifice value of units which have a combat limit below 100 by 50%, so it should send them in first when attacking tough cities. I raised this a little bit.

Are the rams particularly weak or something? What other special properties do they have?

There is actually quite a bit of behavior that goes wrong with the AI that is highlighted with LoR, some of which will effect basic BtS. Mainly is the AI's selection of a unit that it attaches a warlord to if it decides to attach a Warlord rather then settle the great general. The AI still commonly picks units that cannot kill units, this should not occur. It's possible to just remove the Leadership promotion from siege units, but this isn't the prefered aproach, just putting in a check to make sure that a unit can do 100% damage (ie it can kill a unit) would be good enough to stop this. Also in LoR it's common for the AI to get a Great General and attach it to a random catapult, when a legendary unit that's fully 2 strength higher, plus some free promotions, and various other bonuses are right there just asking to be led by a warlord. Please take a look at AI GG logic, and add some improvements to the unit selection process the AI goes through when it decides to attach a warlord.

Also the AI will spend hundreds of hammers on a legendary unit, then have it wander off and die alone in enemy territory; it also does this with high level units in general in BtS. Is there any way to add in some high value unit protection logic so that high value units are kept in stacks, and do not lead assaults if other decent attackers are present?

Lead from Behind in version 1.00 should help keep generals/legends/experienced/healer units much more protected by the AI.

I've just made it so that that units with combat limits are less valued by Great Generals.

However, when on offense the AI general will always choose an ATTACK_CITY unit to lead. In fact, that might be the key for what you want to see with legend units ... what UNITAI are you giving them now? It sounds like ATTACK from what you've written. If you want the legend units to just be used in large attack stacks, then they should definitely by ATTACK_CITY.

 

[phungus420]

However, when on offense the AI general will always choose an ATTACK_CITY unit to lead. In fact, that might be the key for what you want to see with legend units ... what UNITAI are you giving them now? It sounds like ATTACK from what you've written. If you want the legend units to just be used in large attack stacks, then they should definitely by ATTACK_CITY.

They have different AI types depending on their roles. I really do not want to make them all AI_ATTACK_CITY units, some are much better as counter units. Where is the general attachment code, perhaps I could write a simple and quick override that forces the AI to attach any great general it gets to Legendary units; that's only useful for LoR though, and wouldn't make sense in general. The requirement that a unit by AI_ATTACK_CITY doesn't really work in default BtS though, because the AI will attach warlords to Catapults, something it should not do. I think it would just be better to stop having the AI attach warlords to units that cannot kill units in general.

The AI does boost the sacrifice value of units which have a combat limit below 100 by 50%, so it should send them in first when attacking tough cities. I raised this a little bit.

Are the rams particularly weak or something? What other special properties do they have?

Yes, they are weak, though they get bonuses from attacking cities. The other major point is that they only do 50% max damage so even though they are week they have decent survival odds, my guess is the AI doesn't take this into account?

 

[Afforess]

They have different AI types depending on their roles. I really do not want to make them all AI_ATTACK_CITY units, some are much better as counter units. Where is the general attachment code, perhaps I could write a simple and quick override that forces the AI to attach any great general it gets to Legendary units; that's only useful for LoR though, and wouldn't make sense in general. The requirement that a unit by AI_ATTACK_CITY doesn't really work in default BtS though, because the AI will attach warlords to Catapults, something it should not do. I think it would just be better to stop having the AI attach warlords to units that cannot kill units in general.

No, it would be useful other mods too, World Units are in BTS, just never used. A check for a World Unit that has above average strength is worth it.

 

[jdog5000]

They have different AI types depending on their roles. I really do not want to make them all AI_ATTACK_CITY units, some are much better as counter units. Where is the general attachment code, perhaps I could write a simple and quick override that forces the AI to attach any great general it gets to Legendary units; that's only useful for LoR though, and wouldn't make sense in general. The requirement that a unit by AI_ATTACK_CITY doesn't really work in default BtS though, because the AI will attach warlords to Catapults, something it should not do. I think it would just be better to stop having the AI attach warlords to units that cannot kill units in general.

I've changed the code in CvUnitAI::AI_lead so that generals will always consider units with MaxGlobalInstances set, and they will also ignore siege units. We'll see how it goes.

Yes, they are weak, though they get bonuses from attacking cities. The other major point is that they only do 50% max damage so even though they are week they have decent survival odds, my guess is the AI doesn't take this into account?

Correct, the AI did not consider survival odds from low combat limits, there was just the blanket 50% boost for having a combat limit less than 100. I've changed this just now as well, so your rams should attack first in the future.

 

[phungus420]

Cool. Looking over the changes to CvUnitAI::AI_lead I think it might be good to add an extra multiplayer value at the end of the function for a units that have a max global instances of 1 (I'd go as far as multiplying the value by 2 straight across, that way a 2 strength unit that's a world wonder will have a value of a 4 strength regular unit, which will likely make sense due to multipliers and such on these types of units); I also think it would be a good idea to add an increased value for high XP units that have not lost their XP from upgrading already; currently a level 1 maceman has the same value in the code as a level 10 maceman unit with full XP; and a level 10 maceman with full XP would be valued less then a level 1 grenadier with no XP. This in effect nullifies one of the biggest advantages of using a GG for the AI, that is the ability to upgrade for free while keeping the XP of a high level unit.

I'd like to merge this into LoR's source, and not sure when you'll get around to merging in the new BBAI code to RevDCM. So what function did you improve to get the AI to use use RAMs first so I can merge that in individually as well? Also lead from behind causes the AI to value units in a stack, it does not add logic to put high value units in stacks, and prevent them from wandering off by themselves in the first place; probably the biggest cause of needless death for high level units. Do you want to try to tackle this, and if not where should I look to implement such a behavior? Basically what's needed is a simple but crude control on the unit behavior, so that if a unit is designated "high value" (say level 5 or higher, or a World Wonder unit) it may never, ever go anywhere by itself, except to join a stack.

 

[jdog5000]

Cool. Looking over the changes to CvUnitAI::AI_lead I think it might be good to add an extra multiplayer value at the end of the function for a units that have a max global instances of 1 (I'd go as far as multiplying the value by 2 straight across, that way a 2 strength unit that's a world wonder will have a value of a 4 strength regular unit, which will likely make sense due to multipliers and such on these types of units); I also think it would be a good idea to add an increased value for high XP units that have not lost their XP from upgrading already; currently a level 1 maceman has the same value in the code as a level 10 maceman unit with full XP; and a level 10 maceman with full XP would be valued less then a level 1 grenadier with no XP. This in effect nullifies one of the biggest advantages of using a GG for the AI, that is the ability to upgrade for free while keeping the XP of a high level unit.

Cool, good ideas! Will add them.

I'd like to merge this into LoR's source, and not sure when you'll get around to merging in the new BBAI code to RevDCM. So what function did you improve to get the AI to use use RAMs first so I can merge that in individually as well? Also lead from behind causes the AI to value units in a stack, it does not add logic to put high value units in stacks, and prevent them from wandering off by themselves in the first place; probably the biggest cause of needless death for high level units. Do you want to try to tackle this, and if not where should I look to implement such a behavior? Basically what's needed is a simple but crude control on the unit behavior, so that if a unit is designated "high value" (say level 5 or higher, or a World Wonder unit) it may never, ever go anywhere by itself, except to join a stack.

CvUnitAI::AI_sacrificeValue

For keeping high value units alive, it's mainly the UNITAI_ATTACK behavior that has to be significantly modified ... well that and maybe PILLAGE. Those are the ones which can wander into enemy territory alone.

Units with ATTACK_CITY will already compulsively group, and COUNTER units as well. For these there'd just need to be an adjustment of odds thresholds so that they don't do risky attacks when not leading a stack, and maybe also an avoidance of traveling to join a stack in enemy territory without an escort.

The easiest and most reliable way to make this happen is frankly to tell very high value PILLAGE, ATTACK, and COUNTER units to behave like ATTACK_CITY, then tweak ATTACK_CITY in a couple key places to manage these high value units. This wouldn't actually change the UNITAI, just which behavior the unit runs. Does that sound reasonable?

The only other relevant land unit ai's are CITY_DEFENSE, COLLATERAL, and PARADROP. I think those should stay the way they are, their roles are very different.

 

[phungus420]

I inlcuded the recent changes to a test game using LoR's latest SVN. Here is a save, where when you press enter an AI player will spawn a GG, and then send the GG to it's capital to settle. In this instance this AI player should attach the GG to the 300 Spartans unit it invested 120 early game Hammers into. Running the debugger and setting a break point, CvUnitAI::AI_Lead is never ran, so I tracked where it gets called in CvUnitAI, specifically CvUnitAI::AI_generalMove. In this function I added the following code right above the AI_Construct() call so that AI_Lead woud be called:

// Legends of Revolution - Push GG to join Legendary units
	CvPlayer& kOwner = GET_PLAYER(getOwnerINLINE());
	int iLoop;
	for (CvUnit* pLoopUnit = kOwner.firstUnit(&iLoop); pLoopUnit; pLoopUnit = kOwner.nextUnit(&iLoop))
	{
		int pLoopUnitMaxGlobal = GC.getUnitClassInfo(pLoopUnit->getUnitClassType()).getMaxGlobalInstances();
		if( pLoopUnitMaxGlobal == 1 )
		{
			if (AI_lead(aeUnitAITypes))
			{
				return;
			}
		}
	}
// LoR end

This code worked in this case, in that it called AI_Lead correctly. The problem is that the GG still isn't attached to the 300 Spartans unit, instead it runs through AI_Lead and, and just returns false. Using the debugger again, I set a few breakpoints in the function, the problem is here:

if (pLoopUnit->AI_getUnitAIType() == aeUnitAITypes[iI] || NO_UNITAI == aeUnitAITypes[iI] || isWorldUnitClass(pLoopUnit->getUnitClassType()) )

This control statement never returns true, the loop contuines over everything else below it, even though the player has a WorldUnitClass unit, and in fact this check is used specifically to even get here in the first place:
if(GC.getUnitClassInfo(pLoopUnit->getUnitClassType()).getMaxGlobalInstances() == 1)
I think something is wrong with the isWorldUnitClass call.

I realize part of the problem with writing new AI code and getting it to work is having good in game examples to work with and test the code on. At least this was one of the main problems I had with rewriting the Inquisitions AI code for the 2.8 branch of RevDCM. So i am including this save for the current version of the LoR SVN to work with. I would like to work on it myself some, but my Step dad's mom is having medical issues and she needs someone to stay at her place at least for a few days (possibly a couple of weeks, if it goes longer then this she would need to go to a nursing home, so this wol't be a permanent issue), and I do not have access to the internet or my computer over there; and I simply will not have time while this is going on to do any modding for civ4 while I have access to a computer.

 

[jdog5000]

Hmmm ... my guess is that maybe you called AI_lead in your new code without pushing anything into aeUnitAITypes. The code was not setup to work with a 0 length array, which I should have thought of.

Just checked in code which should be able to handle that.

I'm not sure whether to add a block like yours which causes the AI to have GG join any world units it has with top priority ... since this would only be for mods, any other mod makers want to chime in? If that's almost always the desired behavior, then it's easy to do.

 

[phungus420]

I'm not sure whether to add a block like yours which causes the AI to have GG join any world units it has with top priority ... since this would only be for mods, any other mod makers want to chime in? If that's almost always the desired behavior, then it's easy to do.

Agreed, which is why I originally stated I should set this up specifically for LoR, but then Afforess posted he wanted this behavior in to. It would help getting the opinions of more mod makers, especially from people who would like this in, or who would be harmed by it (if it's harmful to some mods, it probably should just not be included). I suspect most mods simply would be ambivalent to such a feature, as World Wonder Units are just never used, and those that could have a problem wouldn't because they couldn't receive a leader a promotion anyway (such as king units in assassination games).

 

[Afforess]

I'm not sure whether to add a block like yours which causes the AI to have GG join any world units it has with top priority ... since this would only be for mods, any other mod makers want to chime in? If that's almost always the desired behavior, then it's easy to do.

When in doubt, create a global define, and turn it off. Let us turn it on if needed.

 

[LunarMongoose]

I suspect most mods simply would be ambivalent to such a feature, as World Wonder Units are just never used

I don't use any World-unique units in MongooseMod as yet (except for the Kraken and such which only the barbs can spawn, and they can't have Generals), however I do have a number of National-unique and National-limited units... each Civ can have one Master Swordsman, four Manta submarines, etc in my mod. So I'd definitely like to see Generals favoring National units if they're going to be used as Warlords anyway, but don't as-yet care whether they look at World units or not.

I don't want them necessarily always becoming Warlords though... Military Academy and Great Instructor use could be more valuable in some situations. I have trouble choosing between those options myself as a human player sometimes though, so I'm not entirely sure how the AI is supposed to heh.

 

[IPEX-731BA5DD06]

I've got more a programming error, then bug, it essentially revolves around the usage of Capitals and lower case in naming a file or folder under Linux, specifically Ubuntu 10.04.

Fonts is a different file name to fonts, and as such won't be recognised as such.

I've had trouble getting it to work under Ubuntu, version 1.00, I've renamed the various files I could see to the Correct Capitalization, but it still say's that it need the Bug.dll to work.

I'm at a loss as to how to enable this, I've extracted the Coregame.dll file to my assets folder, but it just won't enable.

I'm able to run bug 4.5 and Bat 2.3, but not Bull or the Better A.I.

The better A.I, just comes up with a blank tech screen, no icons or helper buttons, but that's all due to the file naming, of which I'm not a programmer, don't know what to change in what to comply etc.

Window won't distinguish between CapiTals and lower case, so CapiTals Doesn't equal capitals, under Linux.

Small note, may solve other problems, create 50 others, but, I've said it.

Bull and Better A.I. Both will suffer from this error under Linux distributions.

 

[Fimbulvetr]

I've had trouble getting it to work under Ubuntu, version 1.00, I've renamed the various files I could see to the Correct Capitalization, but it still say's that it need the Bug.dll to work.

When does the game say that? Normally that's only relevant for a few BUG features that can be enabled via the BUG Options screen (those that require BULL). No part of Better BTS AI requires any part of BUG or BULL.

I'm able to run bug 4.5 and Bat 2.3, but not Bull or the Better A.I.

There is no BUG 4.5 out yet, the newest is 4.4.
More interesting than that, BAT contains BULL (== the BUG dll) so if you got BAT 2.3 to work, you got BULL 1.2 to work. If whatever version of BULL on its own doesn't run then that's just strange.

The better A.I, just comes up with a blank tech screen, no icons or helper buttons, but that's all due to the file naming, of which I'm not a programmer, don't know what to change in what to comply etc.

You sure it's all due to file naming?
Anyway, enable logging and look through your xml and python logs, maybe you'll see something.

 

[jdog5000]

Maybe .DLL instead of .dll?

If you figure out what works, I can easily change capitalization. Right now I'm using the same as the default BTS I believe. The details of what the capitalization should be (at least for the DLL) are hidden from our view in the EXE however.

 

[LunarMongoose]

Oops, wasn't thinking. Moved this to the UP forum where it belongs. *sheepish*

 

[mwyeoh]

moved

 

[phungus420]

I recently merged in the 1.00 code from Fuyu's BetterBugAI into RevDCM. Testing leads to a crash, specifically an access violation error, breaking to here:

CvUnit* CvUnit::getTransportUnit() const
{
return getUnit(m_transportUnit);
}

I added checks throughout the source code to ensure getTransportUnit is not being called on a NULL object, but to no avail. It's possible I've screwed up the merge, but I kind of doubt that would lead to this type of crash.

 

[phungus420]

Here are two saves, one before the turn, and one on the turn this crash occurs. Save is with the current SVN of LoR (not LoR light though, I haven't bothered updating the SVN for LoR light since this critical bug is here). As I stated, this is basically RevDCM's source updated with BBAI which I grabbed from Fuyu's BBAI mod. The crash is caused by the call getTransportUnit() being called on an object it shouldn't (I'd assume NULL), I tried to add checks throughout the SDK to ensure this call wasn't being made an a NULL object, but this did not fix the crash. I'm surprised no crashes have been reported in BBAI 1.0 since I'm sure that has to be where this crash is coming from; I suppose Fuyu is using a different BBAI version for his source or something. In case you don't have it, LoR's SVN is here: https://civ4lor.svn.sourceforge.net/svnroot/civ4lor/Trunk/LoR/ and the Source is here: https://civ4lor.svn.sourceforge.net/svnroot/civ4lor/Trunk/LoRSource/CvGameCoreDLL/