[BTS] Can't remove Mapfinder without breaking scenarios?

[Imperator Knoedel]

I'm trying to use a trimmed down version of BUG (4.4) + BULL (1.3, from the SVN repo on SourceForge) as a base for a mod of my own, by which I mean that I want to get rid of features that I personally have no use for, like for example anything to do with BUFFY, or those copy-pasted strategy articles from twelve years ago that advise the player to go all in on a "Specialist Economy" or a "Cottage Economy". However, it appears that "Mapfinder", whatever that might be, is a load bearing bit of code for no obvious reason. Not for regular games, no, those work without issue. Play Now, Custom Game, Pangaea, Fractal etc. everything in that vein has been playtested without issue by yours truly. But whenever I try playing a Scenario like e.g. Earth18Civs, and it doesn't matter if its custom or regular, upon entering the "Select a Civilization" screen I receive this Python Exception:

Traceback (most recent call last):

File "CvWBInterface", line 65, in getGameDate

File "CvUtil", line 212, in findInfoTypeNum

RuntimeError: unidentifiable C++ exception

When I then click on OK and move on to actually start the game, it crashes while the loading screen claims the game is "Initializing".

I couldn't find anything relevant in the listed (Python) files, and considering scenarios work fine if I just leave all the Mapfinder code in the DLL in even though none of that should have any effect from what I can tell, it seems reasonable to assume that the cause of these crashes lies somewhere in the DLL.

However nothing in the code sprang out to me as in any way related, so I tried compiling the DLL as Debug instead of Release, only to encounter a new error message in Visual Studio:

C:\Program Files (x86)\Civ4SDK\Microsoft Visual C++ Toolkit 2003\include\memory(498): fatal error C1067: compiler limit : debug information module size exceeded

A quick search revealed to me that this could be resolved by splitting code among many smaller files instead of concentrating it in fewer larger ones. I'm not sure I want to mess with that, although this implies that the official developers of BULL have only ever run Release instead of Debug compilations themselves, no?

What does any of that mean? What solutions are possible? Why am I typing any of this? Well, I had hoped that in the process of documenting my findings for the world to see I might have an epiphany of my own, akin to the Rubber Duck effect. Alas, no such burst of inspiration has graced me, and so I am left with no recourse but to hope for you, the reader, to offer some special insight that has eluded me so far.

I guess the easiest solution would be to just leave the Mapfinder code in and ignore it, but... I don't wanna.

 

[Imperator Knoedel]

Bump, in order to facilitate discourse on best practices when it comes to modding this 20 year old game.

 

[f1rpo]

How thoroughly did you remove the MapFinder module? Because I'm wondering how I might reproduce the issue on my end. Through text search, I'm seeing MapFinder.xml/py (plus status screen) getting loaded from init.xml (just not loading it from there does not cause apparent problems), some game text used by or mentioning MapFinder, MapFinder options placed on the Map tab and the MapFinder module imported by AutoSave.py and GameSetUpCheck.py. The latter script, I think, should never get run by (non-BUFFY) BULL, could be trimmed away as well. And just a bunch of MapFinder.isActive calls in AutoSave.py.

The stack trace (as you've probably considered) indicates that looking up the map size obtained from the WBSave causes the crash somehow:

	worldSizeType = CvUtil.findInfoTypeNum(gc.getWorldInfo, gc.getNumWorldInfos(), WBDesc.mapDesc.worldSize)

Still no success compiling a Debug build? I don't recall getting that compilation error from the BULL source, but I've also only compiled it with Nightinggale's makefile and project files. An Assert build could also be worth a try. This assertion ...

int CvGlobals::getInfoTypeForString(const char* szType, bool hideAssert) const
	{
	FAssertMsg(szType, "null info type string");

... might fail. Well, maybe more promising to add log output to the Python functions in the stack trace - what world size string is obtained and passed along?

 

[Noble Zarkon]

I want to get rid of features that I personally have no use for, like for example anything to do with BUFFY,

There is no BUFFY code in BUG/BULL, we add the HOF bits on top of their build.