Editting UnitInfos breaks Better AI

[PTM]

Love this mod. Can't play with out it. Hence the problem...

My own mod uses Better BTS AI (and BUG, actually, via some merging) as a base. Basically, all I've done thus far is revamp civics, button graphics, traits, and parts of the tech tree (around the medieval era). All of this works fine.

The next thing I wanted to do was revamp units. Part of this included stripping the game of all existing UUs. Unfortunately, this utterly breaks Better BTS AI. The game consistently crashes around Turn 50, no matter what I'm doing. It is not related to a syntactic error on my part, and I know it's a Better BTS AI issue because making a clean mod (Better BTS AI-less) with just my unit changes works fine. Reintroducing Better BTS AI, however, reintroduces the crash. This occurs using JUST BBTSAI too, so it's not BUG.

My question is this: why? Is BBTSAI "forcing" the AI to build predetermined units - units that, as per my edits, no longer exist? If so, where is this located (so that I may remove or edit it to prevent crashes)? There are no python errors, no XML errors, etc. upon loading. All graphics are in tact, everything places fine.

 

[MartinHarper]

Part of this included stripping the game of all existing UUs.

I made a mod with Better BTS AI 0.80 a few days ago that stripped the game of all unique units (and all but one unique building, which was modified), and played an automated game till turn 400-ish. As well as removing the units from UnitInfos, I also removed them from CivilizationInfos.

 

[PTM]

I made a mod with Better BTS AI 0.80 a few days ago that stripped the game of all unique units (and all but one unique building, which was modified), and played an automated game till turn 400-ish. As well as removing the units from UnitInfos, I also removed them from CivilizationInfos.

I did this as well. I stripped out all the UUs and the longbowman unit from every relevant XML file (including CivilizationInfos). When I realized this was causing crashes I readded the longbow. When I realized this was causing crashes I readded art definitions for all of the deleted units. When I realized this was crashing I readded a UU for each civ (everyone used Fast Workers as their UU, and I readded the Fast Worker to UnitInfos).

Took these changes out of BBAI folder and put them in a clean one. Works like a charm. Put them back in, crash city. Put a clean BBAI into the clean mod folder with the changes, crash city.

 

[God-Emperor]

When you say "Put a clean BBAI into the clean mod folder", what do you mean?

Just the DLL? More?

I use the BBAI DLL in a Final Frontier modmod. Not too surprisingly this mod has almost none of the standard units in CIV4UnitInfos.xml, the exceptions being the great people units. The only XML file I added from the BBAI mod is Text\CIV4GameText_BetterBTSAI.xml, and I merged the GlobalDefinesAlt.xml into mine. None of the python that comes with BBAI was added. In that state, it works just fine.

 

[PTM]

When you say "Put a clean BBAI into the clean mod folder", what do you mean?

Just the DLL? More?

I use the BBAI DLL in a Final Frontier modmod. Not too surprisingly this mod has almost none of the standard units in CIV4UnitInfos.xml, the exceptions being the great people units. The only XML file I added from the BBAI mod is Text\CIV4GameText_BetterBTSAI.xml, and I merged the GlobalDefinesAlt.xml into mine. None of the python that comes with BBAI was added. In that state, it works just fine.

I've tried it both ways (i.e., I've tried it with just the dll and GlobalDefines, and I've tried it with all of the files included in the BBAI file). It crashes consistently around Turn 50 (almost always 53-56). The instant I delete the dll things are totally fine (BUG works fine, my changes work fine). BBAI just won't play nicely, and it must be something in the dll. I've tried both 0.8 and 0.81M...

 

[jdog5000]

There's no specific mention of any unit type in BBAI or forcing like that, and I know many mods that use BBAI have changed the unit files ... there must be something more subtle going on in your case.

Is your mod available somewhere? Running with a debug DLL I could figure out what's causing the crash pretty quickly.

 

[PTM]

I've attached a barebones version of my mod. This strips out every XML change I've made except for deletion of longbowmen and UUs. With the Better BTS AI dll, it crashes consistently (literally every single time) between turn ~36 and turn ~60. Halp!

Edit: I should note, that I forgot to remove one instance of the unit LONGBOWMAN (it is left in as an archer upgrade). This error is not present in my mod, and making a correction does not fix the crashing.

 

[phungus420]

You should compile a debug dll, and check the cause of your crash. I'd hesistate to blame BBAI until you check it.

 

[PTM]

You should compile a debug dll, and check the cause of your crash. I'd hesistate to blame BBAI until you check it.

I don't know how to do this, but I will look into it. It would be odd if it were not BBAI, however, since the crash only occurs when BBAI's dll is active. Removing that dll (and therefore running with the BTS default) creates a perfectly stable mod. This is 100% reproduceable. I've even edited UnitInfos from scratch twice over now, so if it's a syntax error somewhere that logging won't detect I doubt I could have made it three consecutive times.

 

[phungus420]

It would be odd if it were not BBAI, however, since the crash only occurs when BBAI's dll is active. Removing that dll (and therefore running with the BTS default) creates a perfectly stable mod. This is 100% reproduceable.

In that case it's a reasonable assumption that BBAI is the cause. Still a debug dll might help isolate it, and if you can track the cause using one it would take some of the workload off of jdog

The SDK wiki page is good, it directs you to all the stuff you need to compile a debug dll, except the BBAI source which you'd get from these BBAI forums:
http://modiki.civfanatics.com/index.php/How_to_Install_the_SDK

 

[PTM]

In that case it's a reasonable assumption that BBAI is the cause. Still a debug dll might help isolate it, and if you can track the cause using one it would take some of the workload off of jdog

The SDK wiki page is good, it directs you to all the stuff you need to compile a debug dll, except the BBAI source which you'd get from these BBAI forums:
http://modiki.civfanatics.com/index.php/How_to_Install_the_SDK

Working on getting this set up, although I'm having a few errors. Will update if/when I have this done.

Edit: haven't gotten the debug up, but I should note that I'm getting crashes even while leaving all the UUs in the game... adding 1-2 units seems to be fine, but I just added about 5 more and its causing the same crashes. This is frustrating and nonsensical, since I'm not doing anything wrong. I wish I could get this dll to compile, so I could run a debug.

 

[PTM]

Running a debug dll seems to circumvent the crash (rebuilding a final_release produces the same problem). I do get several instances of:

Assert Failed

File: CvGlobals.cpp
Line: 1365
Expression: eUnitNum > -1
Message:

----------------------------------------------------------


That function looks like this:
CvUnitInfo& CvGlobals::getUnitInfo(UnitTypes eUnitNum)
{
FAssert(eUnitNum > -1);
FAssert(eUnitNum < GC.getNumUnitInfos());
return *(m_paUnitInfo[eUnitNum]);
}

Clicking ignore when running a debug dll seems to be fine. Possibly this is forcing a crash when using a final_release? I have no clue what to do about this.

Edit: actually, subsequent runs of the debug dll produce the same problem accompanied by an immediate crash thereafter. So clearly this must be the issue. Does anyone know what I should do about it this, though?

 

[God-Emperor]

The obvious solution is to stop calling "getUnitInfo(-1)" (or some other negative number).

In the debugger you should be able to move up the call stack to the code doing the call and see why (or, at least, where) it is passing a negative number instead of a valid unit number.

 

[phungus420]

Awesome job on getting the debug dll working

That assert message should help jdog locate the bug. Now the best thing you can do is package the bug report. Upload your mod to the internet (you can use filefront or any other file hosting service, and if it's under 10MB, which yours might be since you're just removing units, you can just upload it as an attachement on these forums), and upload the save where you are getting the crash. Also in your report show the assert failure message. Post it all in the Bug Reporting thread.

Of course that's probably all not necessary as jdog will probably check this thread, but in the future that's the best way to do it. jdog could definatly use a copy of your mod with a save though, as that allows for quick and easy reproduction of the bug.

The obvious solution is to stop calling "getUnitInfo(-1)" (or some other negative number).

In the debugger you should be able to move up the call stack to the code doing the call and see why (or, at least, where) it is passing a negative number instead of a valid unit number.

God-Emperor, PTM isn't a programmer, he was just running a debug dll to make sure that the bug was caused by BBAI, and not the XML changes in his mod, which that assert pretty much demonstrates.

 

[jdog5000]

If you remove longbowmen from CIV4UnitInfos.xml, you also have to remove UNITCLASS_LONGBOWMAN from CIV4UnitClassInfos.xml. If you carefully remove all references to the units and unit classes you've cut out from xml, you'll be back in business. You can be sure you've got them all when you don't get any more asserts.

What these asserts mean is that the game is looking up the unit type for a particular unit class and found no appropriate unit (-1). The assert was put there to let Firaxis know this is happening so they would know they need to fix something in their xml files.

I've seen the asserts now but haven't gotten your mod to actually crash on me yet during debugging.

 

[Yakk]

I've attached a barebones version of my mod. This strips out every XML change I've made except for deletion of longbowmen and UUs. With the Better BTS AI dll, it crashes consistently (literally every single time) between turn ~36 and turn ~60. Halp!

Edit: I should note, that I forgot to remove one instance of the unit LONGBOWMAN (it is left in as an archer upgrade). This error is not present in my mod, and making a correction does not fix the crashing.

I suspect from reading your assert that there are other 'dangling references'.

You mentioned deleting unique units -- they exist in more than one spot. I think it is 3 spots. They exist in the unitinfos, they exist in the unitclassinfos, and they exist in some civilisation-specific xml file (which I think is redundant, but what can you do).

Remember that any file you don't copy over to your mod ends up using the default one. So dangling references to units can easily cause the crash you are describing.

 

[AbsintheRed]

Sry for necro, google search pointed to this thread

I have a very similar assert(?) problem:

Assert Failed

File: CvInfos.cpp
Line: 9675
Expression: i < GC.getNumUnitClassInfos()
Message: Index out of bounds

Assert Failed

File: CvGlobals.cpp
Line: 1439
Expression: eUnitNum < GC.getNumUnitInfos()
Message:

The case is the same what was for PTM:

Edit: actually, subsequent runs of the debug dll produce the same problem accompanied by an immediate crash thereafter. So clearly this must be the issue. Does anyone know what I should do about it this, though?

I have a couple harmless assert messages, which comes up quite a couple times when runnning debug .dll
But these 2 messages come up only once, right after each other, and an immediate crash follows them:

This program has encountered a problem and needs to be closed. Do you wish to save a diagnostic file?

These are the corresponding parts of the 2 files:

int CvCivilizationInfo::getCivilizationUnits(int i) const
{
	FAssertMsg(i < GC.getNumUnitClassInfos(), "Index out of bounds");
	FAssertMsg(i > -1, "Index out of bounds");
	return m_piCivilizationUnits ? m_piCivilizationUnits[i] : -1;
}

CvUnitInfo& CvGlobals::getUnitInfo(UnitTypes eUnitNum)
{
	FAssert(eUnitNum > -1);
	FAssert(eUnitNum < GC.getNumUnitInfos());
	return *(m_paUnitInfo[eUnitNum]);
}

 

[AbsintheRed]

I suspect that this must be some oversight in the XML files, but I simply cannot find any mistakes or leftover parts anywhere...
Also, the inavoidable crash after those 2 supposedly assert issues is very strange
As I said, there are a couple "normal" assert issues left there (for testing this out), and those behave as they usually do
They doesn't really affect the game, one can simply ignore them

The obvious solution is to stop calling "getUnitInfo(-1)" (or some other negative number).

In the debugger you should be able to move up the call stack to the code doing the call and see why (or, at least, where) it is passing a negative number instead of a valid unit number.

Can you specify this a little more?

 

[embryodead]

Since it starts with getCivilizationUnits and the "i < GC.getNumUnitClassInfos()" assert failed, it's not a case of calling getUnitInfo(-1). I'd suspect some default unit is wrong in UnitClassInfos, or some unique unit points to the wrong unit class in CivilizationInfos. If you can't find anything in the XML, you can select Debug/Break on the first assert and check the stack to trace what is the value of variable i, and what called getCivilizationUnits with that argument (you have to attach the debugger to the exe for this option to be available, just having a debug dll won't be enough).