Better DuneBUG AI

Finally, located an pre-crash Assert failure:

Code:
File:  CvUnitAI.cpp
Line:  24367
Expression:  pDefender != NULL
Message:

The lines of code are with the DCM code, CvUnitAI::AI_RbombardCity:
Code:
							pDefender = pLoopPlot->getBestDefender(NO_PLAYER, getOwnerINLINE(), this, true);
							[B]FAssert(pDefender != NULL);[/B]
							FAssert(pDefender->canDefend());
							iDamage = GC.getGameINLINE().getSorenRandNum(bombardRate(), "AI Bombard");

I think the second FAssert would blow up if pDefender is null, which it clearly can be.

I looked at the equivalent code in the Dune Wars 1.8 RevDCM version and the AI_RbombardCity is very different, much simpler and looks null-safe.

Dune Wars 1.8X / DCM version in full:
Spoiler :
Code:
// Dale - RB: Field Bombard START
// Returns true if a mission was pushed...
bool CvUnitAI::AI_RbombardCity()
{
	PROFILE_FUNC();

	CvCity* pCity;
	CvPlot* pLoopPlot;
	CvPlot* pBestPlot;
	CvUnit* pDefender;
	int iSearchRange;
	int iPotentialAttackers;
	int iValue;
	int iDamage;
	int iBestValue;
	int iDX, iDY;

	if(!canRBombard(plot()))
	{
		return false;
	}
//	for (int iPlayer = 0; iPlayer < MAX_CIV_PLAYERS; ++iPlayer)
//	{
//		gDLL->getInterfaceIFace()->addMessage((PlayerTypes)iPlayer, true, GC.getDefineINT("EVENT_MESSAGE_TIME"), "Got here!", "AS2D_BOMB_FAILS", MESSAGE_TYPE_INFO, GC.getUnitInfo(getUnitType()).getButton(), (ColorTypes)GC.getInfoTypeForString("COLOR_RED"), plot()->getX_INLINE(), plot()->getY_INLINE());
//	}
	if(GC.getDCM_RANGE_BOMBARD())
	{
		iSearchRange = getDCMBombRange();
		iBestValue = 0;
		pBestPlot = NULL;
		for (iDX = -(iSearchRange); iDX <= iSearchRange; iDX++)
		{
			for (iDY = -(iSearchRange); iDY <= iSearchRange; iDY++)
			{
				pLoopPlot	= plotXY(getX_INLINE(), getY_INLINE(), iDX, iDY);
				if (pLoopPlot != NULL)
				{
					if (canBombardAtRanged(plot(), pLoopPlot->getX_INLINE(), pLoopPlot->getY_INLINE()))
					{
						iValue = 0;
						pCity = pLoopPlot->getPlotCity();
						if (pCity != NULL)
						{
							iValue += std::max(0, (std::min((pCity->getDefenseDamage() + airBombCurrRate()), GC.getMAX_CITY_DEFENSE_DAMAGE()) - pCity->getDefenseDamage()));
							iValue *= 5;
							if (pCity->AI_isDanger())
							{
								iValue *= 2;
							}
							if (pCity == pCity->area()->getTargetCity(getOwnerINLINE()))
							{
								iValue *= 3;
							}
						}
						iPotentialAttackers = GET_PLAYER(getOwnerINLINE()).AI_adjacentPotentialAttackers(pLoopPlot);//pLoopPlot->getNumVisibleEnemyDefenders(NO_PLAYER);
						if (iPotentialAttackers > 0 || pLoopPlot->isAdjacentTeam(getTeam()))
						{
							pDefender = pLoopPlot->getBestDefender(NO_PLAYER, getOwnerINLINE(), this, true);
[B][COLOR="Red"]							FAssert(pDefender != NULL);
							FAssert(pDefender->canDefend());[/COLOR] - NB Problem lines[/B] 
							iDamage = GC.getGameINLINE().getSorenRandNum(bombardRate(), "AI Bombard");
//							iValue = max(0, (min((pDefender->getDamage() + iDamage), bombardRate()) - pDefender->getDamage()));
							iValue += ((((iDamage * collateralDamage()) / 100) * std::min((pLoopPlot->getNumVisibleEnemyDefenders(this) - 1), collateralDamageMaxUnits())) / 2);
							iValue *= (3 + iPotentialAttackers);
							iValue /= 4;
						}
						iValue *= GC.getGameINLINE().getSorenRandNum(20, "AI Bombard");
						if (iValue > iBestValue)
						{
							iBestValue = iValue;
							pBestPlot = pLoopPlot;
							FAssert(!atPlot(pBestPlot));
						}
					}
				}
			}
		}
		if (pBestPlot != NULL)
		{
			getGroup()->pushMission(MISSION_RBOMBARD, pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE());
			return true;
		}
	}
	return false;
}

Dune Wars 1.8 / RevDCM version in full:
Spoiler :
Code:
// Returns true if a mission was pushed...
bool CvUnitAI::AI_RbombardCity(CvCity* pCity)
{
	PROFILE_FUNC();

	CvUnit* pDefender;
	CvPlot* pPlot;

	if(!GC.getDCM_RANGE_BOMBARD())
	{
		return false;
	}

	if (GC.getDefineINT("DCM_NAVAL_BOMBARD"))
	{	
		return false;
	}

	if (pCity == NULL)
	{
		return false;
	}

	pPlot = pCity->plot();
	if (pPlot == NULL)
	{
		return false; // ok will never happen but anyway...
	}

	if(!canBombardAtRanged(plot(), pPlot->getX_INLINE(),pPlot->getY_INLINE()))
	{
		return false;
	}

	pDefender = pPlot->getBestDefender(NO_PLAYER, getOwnerINLINE(), this, true);
	if (pDefender != NULL) [B][COLOR="Red"]- NB this check makes is what Dales version is missing[/COLOR][/B]
	{
		if (collateralDamageMaxUnits() > pPlot->getNumUnits())
		{
			if (pDefender->isRbombardable(3) && getGroup()->getBombardTurns(pCity) < 3)
			{
				getGroup()->pushMission(MISSION_RBOMBARD, pPlot->getX_INLINE(),pPlot->getY_INLINE());
				return true;
			}
		}
	}
	return false;
}

This could be down to the joys of code interaction. Dales code was was written before Uncut Dragon's Lead from Behind modcomp. Perhaps the vanilla getBestDefender never returns null whereas the Lead from Behind version does.

Anyway, there are two options for a fix. I can either swap in the RevDCM version of AI_RbombardCity or make the more sophisticated DCM version safe against getBestDefender returning null.

On the XML front, my manual schema validation technique has found a long list of problems with CIV4BuildingInfos.xml. Mostly these are to do with the fact that the schema expects <Help> to be after <Strategy> but they are the wrong way around in many cases. Also, there were uses of <BonusType> instead of <Bonus> inside <PrereqBonuses> and YieldProduced etc being in the wrong place.

All of this proves that the mod loading does mean your XML is valid. It would be great if there was an automated way of verifying all your files against the schemas. My solution is quite tedious, but it has saved a lot of time in the case of BuildingInfos.

Attached cleaned and validated versions of LeaderHeadInfos and BuildingInfos. I can see these making the Python pedia issues go away (hopefully). Then it's just a question of fixing the SDK crash.
 
Ok. I believe the problem is not the LeaderHeadInfos.xml file anymore. Thanks Deliverator for the link to the validator (and instructions).:) The LeaderHeadInfos.xml file validates and the xml log is totally clean...
Code:
[109091.187] Loading XML file xml\GameInfo/CIV4PlayerOptionInfos.xml
[109091.233] Load XML file xml\GameInfo/CIV4PlayerOptionInfos.xml SUCCEEDED
[109091.233] SetGlobalClassInfo (Civ4PlayerOptionInfos/PlayerOptionInfos/PlayerOptionInfo)
[109091.233] Loading XML file xml\GameInfo/CIV4GraphicOptionInfos.xml
[109091.249] Load XML file xml\GameInfo/CIV4GraphicOptionInfos.xml SUCCEEDED
[109091.249] SetGlobalClassInfo (Civ4GraphicOptionInfos/GraphicOptionInfos/GraphicOptionInfo)
The game still CTD but look at the python log...
Code:
load_module CvEventInterface
load_module BugEventManager
load_module CvEventManager
load_module CvUtil
load_module traceback
load_module CvScreensInterface
load_module CvMainInterface
load_module ScreenInput
load_module CvScreenEnums
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "<string>", line 52, in load_module
  File "CvEventInterface", line 17, in ?
  File "<string>", line 52, in load_module
  File "BugEventManager", line 102, in ?
  File "<string>", line 52, in load_module
  File "CvEventManager", line 12, in ?
  File "<string>", line 52, in load_module
  File "CvScreensInterface", line 3, in ?
  File "<string>", line 52, in load_module
  File "CvMainInterface", line 6, in ?
  File "<string>", line 52, in load_module
  File "CvScreenEnums", line 65, in ?
AttributeError: type object 'CvPythonExtensions.CivilopediaPageTypes' has no attribute 'CIVILOPEDIA_PAGE_CONCEPT_DCM'
load_module CvAppInterface
Since it has already been proven that Vista is not fault tolerant, I bet this is the true culprit (at least right now).
 
Since it has already been proven that Vista is not fault tolerant, I bet this is the true culprit (at least right now).

You may be right. To be honest we don't really need this separate DCM Concepts pedia section anyway. The Dune Wars Concepts section seems to work in a different way from this and we can add the DCM help content to that if needs be.

Does commenting out the line:
Code:
##### DCM START
PEDIA_CONCEPT_DCM = CivilopediaPageTypes.CIVILOPEDIA_PAGE_CONCEPT_DCM + PEDIA_START
##### DCM END
from the Python file CvScreenEnums.py making this error go away, or will we have to seek and destroy references in the SDK as well?
 
Also, CIVILIZATION_MINOR needs to be completely removed from CivilizationInfos to stop another pedia error. Presumably that crept back in when I was merging.
 
I've made a first patch for 1.8X to fix some of the issues we've found so far.

+ SDK fix for DCM Ranged Bombardment AI crash - new DLL and altered source included - I've not tested this again yet.
+ Fixed XML files - BuildingInfos, LeaderheadInfos and CivilizationInfos (removed Minor civ).

Download Here

I'm quite busy the next few days and I'm away this weekend so I won't be able to spend much time on this until next week sometime.
 
I think something is missing from the 1.8X code to do with the new Memory types. If you remove all the MemoryDecays and MemoryAttitudePercents in CIV4LeaderheadInfos.xml with <MemoryDecays/> and <MemoryAttitudePercents/> then my Debug DLL loads up fine even on the PC where it was crashing before. When I'm back, I'll make sure that the two new memory types are in all the required files - they are missing from CyEnumsInterface.cpp for example...
 
I started a game using a Final_Release dll. Some obvious bugs (hey I like to drink:D) :

1. Viewing the city screen, food icons are shown instead of water icons and the hover text says food. The map does show the correct icon though.
2. When meeting a civ for the first time, and also the Diplomacy screen later, the screen looks like this...
Spoiler :
Busted!.JPG
3. Although not a bug, the 'Orions inquisitor Mod screen ' should not show at start-up (just like RevDCM options screen was removed in 1.8) IMO.
4. // I think I'll wait until a Debug version can be compiled under Vista before playtesting further.
5. #Def NoBug : Thanks to Deliverator - this seems to be the future of the Dune Wars Mod - IF the bugs can be worked out.:)
 
ive noticed that you removed the hated civics from the sdk, is this on purpose?
This has been discussed on the previous page. It is by accident and will be fixed.

i saw you might have missed a code line by cephalo.
Sorry, but this feedback is extremely unhelpful. There are thousands of changed lines. If you found one you believe is missing, please give a little more detail, like a file and line number.

you removed events with imagaes - y?

This may be a good find. The only place this is used is where the mentat icon is displayed on the popup where you choose a mentat specialty. I have not tried, but maybe this is not working. Probably the schema change is present, so the xml which defines the image is working; but the sdk code may be missing. We had discussed about using more images with events, such as the first time a sandworm eats your harvester, etc.
 
Thanks for those merges Keldath - I have added the missing pieces in.

I have done some more diagnosis on the errors with Dune Wars 1.8X. The two things that aren't working, the two new MemoryInfos (MEMORY_MANIPULATED_US and MEMORY_POLITICAL_MARRIAGE) and the new CivilopediaPageType CIVILOPEDIA_PAGE_CONCEPT_DCM both involve adding to the hard-coded list of enumerations in CvEnums.h. In the case of the new MemoryInfos they are also added to the XML file CIV4MemoryInfos.xml. In Dune Wars 1.8 (the RevDCM version) adding these new values seems to work OK, but in 1.8X (the Better BUG AI version) with the same code the new values do not work.

I have carefully reviewed that all the code around MEMORY_MANIPULATED_US and MEMORY_POLITICAL_MARRIAGE to make sure nothing has been missed, but even then the DebugDLL still crashes. If I remove all references to MEMORY_MANIPULATED_US and MEMORY_POLITICAL_MARRIAGE from CIV4LeaderHeadInfos.xml then the mod boots up fine, the only errors being Python errors concerned with CIVILOPEDIA_PAGE_CONCEPT_DCM.

A possible theory is that all the Modular loading stuff in the RevDCM is what allows these enumerations to be extended and since the Better BUG AI version doesn't have this extending them with new values doesn't work.

Edit: The other weird thing is I can only reproduce these errors using the Debug DLL on a Steam/Windows XP install. Using the Final_Release DLL on Steam/XP doesn't give the Memory errors, and using the Debug DLL/non-Steam works OK too. For some reason Steam/XP and Vista seem to have the same issue when it comes to using the Debug DLL.

I think removing MEMORY_MANIPULATED_US, MEMORY_POLITICAL_MARRIAGE and CIVILOPEDIA_PAGE_CONCEPT_DCM from the SDK and XML may be the only way to get this Better BUG AI version to work. It would be unfortunate to have to lose features, but I don't have another solution at the moment.
 
Thought I'd respond to these quickly.

1. Viewing the city screen, food icons are shown instead of water icons and the hover text says food. The map does show the correct icon though.

Cosmetic issues like this are easily resolved. Working with gamefonts (the small icons) is one of the most painful things in Civ4 modding so I want to see if we can get this build working properly before doing them.

When meeting a civ for the first time, and also the Diplomacy screen later, the screen looks like this...

I think this is probably related to the MemoryInfo issue. Perhaps leaderheads aren't loading properly.

Although not a bug, the 'Orions inquisitor Mod screen ' should not show at start-up (just like RevDCM options screen was removed in 1.8) IMO.

Agreed. A simple one line change that I've already done locally. An aside is that it would be interesting to eventually get feedback on those different Inquisitor options.

4. // I think I'll wait until a Debug version can be compiled under Vista before playtesting further.
5. #Def NoBug : Thanks to Deliverator - this seems to be the future of the Dune Wars Mod - IF the bugs can be worked out.:)

I feel like this endeavour is in the balance at the moment. I'm getting to the stage where I'm not sure it worth spending any more time on it. Adding/developing features is much more fun then trying to get existing features working on a new code-base.
 
The diplo issue looks like the one you get when you don't remove all python files from old BUG mods properly or if you have an old BUG mod (and by old I mean anything not up to date with the svn) in your CustomAssets.

It looks like you are using a lot more of RevDCM functionality than I expected, maybe you really should consider sticking to RevDCM.
 
this memory thing is really odd.


about dcm - revdcm have some changes made into the dale code, along with some fixes, they also added naval bombardment fix, i have began adding it manually just to see how it goes,

maybe there will be something you can use from there.

:)
 
I have carefully reviewed that all the code around MEMORY_MANIPULATED_US and MEMORY_POLITICAL_MARRIAGE to make sure nothing has been missed, but even then the DebugDLL still crashes.

I am on vacation this week, and I don't have access to my code. But, on Mon-Tue of next week I might be able to take a look. I'm not sure why RevDCM would be needed to make these work. Do you have any changes beyond the first 1.8X disti you uploaded?
 
I am in the process of updating Dune Wars (see my Immortal screenshot post for why I even have the time;)) to the following :

RevDCM - version 2.61 (included in DW 1.8)
Better BTS AI - version 1.00 (released 5/17/10)
BUG - version 4.4 (released 5/18/10)
BULL - version 1.2 (released 5/18/10)

I am going to use Dune Wars 1.8 as the base. So far, BULL 1.2 compiles a debug version just fine. If I succeed with the merge, I'll post the source code so the Dune Wars team can look at it. I am disappointed that the Better Dunebug AI project has run into problems, but in the end, all I really care about is the development of Dune Wars specific features. I'm pretty good with dumb dumb work, but not so much in the vision thing. I can't say this enough..thanks to the Dune Wars team for your hard work. This mod really is the best of the best!:goodjob:
 
I am on vacation this week, and I don't have access to my code. But, on Mon-Tue of next week I might be able to take a look. I'm not sure why RevDCM would be needed to make these work. Do you have any changes beyond the first 1.8X disti you uploaded?

I'll upload the latest source I have at the weekend. You may struggle to recreate the crash without Steam or Vista though as normal XP install/Debug DLL seems to work fine.

I am going to use Dune Wars 1.8 as the base. So far, BULL 1.2 compiles a debug version just fine. If I succeed with the merge, I'll post the source code so the Dune Wars team can look at it. I am disappointed that the Better Dunebug AI project has run into problems, but in the end, all I really care about is the development of Dune Wars specific features. I'm pretty good with dumb dumb work, but not so much in the vision thing. I can't say this enough..thanks to the Dune Wars team for your hard work. This mod really is the best of the best!

I had considered doing this, so thanks, there is a good chance that we'll end up using this if 1.8X can't be fixed.

On Dune Wars specific features - don't worry - I have been working to pull various new features together for a patch to DW 1.8. It is likely I'll upload this new patch by Saturday at the latest. The new features include new promotions and promotion effects, Cave features, Civilization animosities, FFH2/Orbis style defensive withdrawal from combat and Botanical Testing Stations.
 
I am on vacation this week, and I don't have access to my code. But, on Mon-Tue of next week I might be able to take a look. I'm not sure why RevDCM would be needed to make these work. Do you have any changes beyond the first 1.8X disti you uploaded?

Here is my latest source code for 1.8X/Better DuneBUGAI.

You should apply the patch from this post too.
 
Well, now I do (1.8.0.1 patch has been released:goodjob:). But, I enjoy multi-tasking. I am in the process of trying to get BULL 1.2 to compile a working Debug dll (compiles fine but CTD when running). I notified the BUG team, and I believe Lemon Merchant is going to see if the Debug dll will work under Vista (no word yet) on her computer. I have compiled and ran successfully the Debug version of RevDCM 2.72. One glaring difference between BULL 1.2 and RevDCM 2.72 is the absence of ximage. I don't know if this is important, but right now it seems a better bet to stick with the RevDCM base (which includes BUG/BULL/Better BTS AI anyway). From the available data, it would seem that RevDCM is compiled under Vista (but I could be wrong). IMO, a code base is only acceptable if a Debug dll will run - otherwise Vista specific CTD will not be able to be diagnosed. I'll keep you posted.
 
Jester Fool,

well, i like what your saying and not,
i read that glider plans on revdcm 3 to be the final part, so maybe indeed we should go back to revdcm,

although - i kinda like the work delvirator have done here, wish it to become the formal version.

cheers.
 
Top Bottom