CvGameCoreDLL Build Error boost/python/list.hpp

I've given it a try myself now. I've got to say, the process is not entirely straightforward, even with the dependencies already installed. I'm not suggesting that you start over; just listing the steps I took for reference:

Downloaded the Master of Mana Xtended snapshot from SourceForge. (Didn't verify that this is really the latest version of the mod, but the last revision being from June 2019 is a good sign.) Unzipped, renamed to "CvGameCoreDLL".

Threw out CvTextScreen.cpp, resource.h (doesn't hurt, but, since the mod has removed CvGameCoreDLL.rc, it's useless) and CvGameCoreDLL better AI.suo (always better to let Visual Studio generate that). Also set aside the original .sln, .vcxproj and makefile to make sure that they don't get in the way.

Downloaded Nightinggale's makefile-2.5 archive and extracted it into a newly created folder "project" inside CvGameCoreDLL. I much prefer having a separate folder for the project files. The SOURCE_DIR variable needs to be set accordingly (see below).

Created a folder "bin" in project and moved fastdep.exe there because that's where the makefile looks for fastdep.exe.

Commented out YOURMOD in the makefile (because I didn't install the mod's assets). Set CIV4_PATH=$(PROGRAMFILES)\Sid Meier's Civilization 4\Beyond the Sword
– I guess I moved my boost and python libraries at some point; anyway, they're in my BtS install directory. The other paths (TOOLKIT, PSDK) happened to be correct already.

Opened the .sln file in VS 2010. Added all the files in CvGameCoreDLL so that I can access them in the VS code editor if needs be: right-clicked on the project (Civ4DLL) in the Solution Explorer, "Add->Existing item", marked everything in CvGameCoreDLL, added it.

F7 to compile. That failed, predictably, but created Makefile.project. Set
SOURCE_DIR = ..
in Makefile.project so that the makefile goes one folder up to find the source code.

Compiled again and it worked:
Code:
Linking DLL
1>     Creating library temp_files\Debug\CvGameCoreDLL.lib and object temp_files\Debug\CvGameCoreDLL.exp
1>      COPY "temp_files\Debug\CvGameCoreDLL.dll" "Debug\CvGameCoreDLL.dll"
1>          1 file(s) copied.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Since I didn't set YOURMOD, the (debug) DLL was created in project\Debug.

Finally, for tidiness, moved all my path settings from the makefile over to Makefile.settings.

Now, is there anything in the original makefile or VS files that is worth merging into Nightinggale's? Hard to say; I haven't spotted anything. Certainly, in the VS files (.sln, .vcxproj), there isn't much to see.
 
Hi,

So I'm working away using VS 2003 Toolkit but using VS2010 Express as the development environment.

I had actually tried to install VS2003 to use as the development environment but it would not install as some software versions on my laptop are not compatible with it.

The MoM sourcecode that you (@f1rpo) used is that for Master of Mana Extended. I don't know how similar that is to the original MoM sourcecode but MoM Extended has more features that I don't want to use, hence I was basing my mod off the earlier MoM sourcecode. I'll download the MoM Extended sourcecode and see if many of the files have been updated. It may contain the fixes to the errors that I've been finding.

---

I have been finding and (hopefully) fixing some errors as I try to do this compilation.
Most common error has been the missing int at the start of for loops, so that the integer is undeclared.
I've also found a couple of instances of where an integer is used outside of a for loop which defines it. I commented out the offending line in one case and repositioned it in another.
I've removed both CvTextScreen.cpp and resource.h as you suggest.

It's not working fully for me yet but I feel I've made progress - at least I've encountered new error messages; LNK2001 and LNK2019: unresolved external symbol. I take it that this means the compilation has made it all the way through the cl.exe and is now getting stuck at the link.exe stage.
Build Error messages:
Spoiler :

1>------ Build started: Project: Civ4DLL, Configuration: Debug Win32 ------
1> Building source list
1> Running fastdep
1> Linking DLL
1> Creating library temp_files\Debug\CvGameCoreDLL.lib and object temp_files\Debug\CvGameCoreDLL.exp
1>CyStructsInterface1.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>_precompile.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CyInfoInterface1.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CyInfoInterface2.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CyInfoInterface3.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CyInfoInterface4.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvXMLLoadUtilityModTools.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvXMLLoadUtilitySet.obj : error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "private: void __thiscall CvXMLLoadUtility::LoadGlobalClassInfo<class CvCommerceInfo>(class std::vector<class CvCommerceInfo *,class std::allocator<class CvCommerceInfo *> > &,char const *,char const *,char const *,bool,class CvCacheObject * (__thiscall CvDLLUtilityIFaceBase::*)(char const *))" (??$LoadGlobalClassInfo@VCvCommerceInfo@@@CvXMLLoadUtility@@AAEXAAV?$vector@PAVCvCommerceInfo@@V?$allocator@PAVCvCommerceInfo@@@std@@@std@@PBD11_NP8CvDLLUtilityIFaceBase@@AEPAVCvCacheObject@@1@Z@Z)
1>CyCity.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CyHallOfFameInterface.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvTeamAI.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvUnit.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvUnitAI.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvXMLLoadUtility.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvSelectionGroup.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvStatistics.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvStructs.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvTeam.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvPlot.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvPopupInfo.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvPopupReturn.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvReplayInfo.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvMapGenerator.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvMessageData.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvPlayer.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvPlayerAI.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvHallOfFameInfo.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvInfos.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvInitCore.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvMap.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvGame.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvGameInterface.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvGameTextMgr.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvGlobals.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvDllPythonEvents.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvDllTranslator.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvDLLWidgetData.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvEventReporter.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvCity.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvCityAI.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvDiploParameters.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvDLLButtonPopup.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>AI_Group.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>AI_Units.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvArtFileMgr.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>CvBarbarians.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
1>temp_files\Debug\CvGameCoreDLL.dll : fatal error LNK1120: 1 unresolved externals
1>NMAKE : fatal error U1077: 'bin\link.exe' : return code '0x460'
1> Stop.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "set TARGET=Debug
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake source_list /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake fastdep /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake dll /NOLOGO" exited with code 2.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========



I'll take a look at the MoM Extended sourcecode in the meantime but I'd be interested to hear how to fix unresolved external symbol issues.

-------
So with the MoM Extended sourcecode, I was still finding some errors when trying to compile.
  • There were missing int to declare integers in for loops in; AI_ChooseProduction, AI_ChooseTech, CvGame, CvGameTextMgr & CvInfos.
  • There were statements relying on an undeclared integer in CvGameInterface.
  • isApplyImprovementCost was missing () in CvInfos.
Eventually, I ran into this error message;
Spoiler :

1>------ Build started: Project: Civ4DLL, Configuration: Debug Win32 ------
1> Building source list
1> Running fastdep
1> CvMap.cpp
1>.\.\CvMap.cpp(2463): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h(371) : see declaration of 'sprintf'
1>.\.\CvMap.cpp(2465): warning C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\string.h(110) : see declaration of 'strcat'
1>.\.\CvMap.cpp(2615): error C2039: '_Inc' : is not a member of 'std::_Tree_const_iterator<_Mytree>'
1> with
1> [
1> _Mytree=std::_Tree_val<std::_Tset_traits<CvPlot *,std::less<CvPlot *>,std::allocator<CvPlot *>,false>>
1> ]
1>NMAKE : fatal error U1077: 'bin\cl.exe' : return code '0x2'
1> Stop.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "set TARGET=Debug
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake source_list /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake fastdep /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake dll /NOLOGO" exited with code 2.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


I've seen some messages about functions or variables may be unsafe before on initial builds. Typically if I hit build again, those messages do not reappear. In this case, these warnings are not disappearing on rebuilding.
CvMap.cpp(2615): error C2039 is an error message that I have not seen before. What would cause this and what would the fix be?
 
Last edited:
The MoM sourcecode that you (@f1rpo) used is that for Master of Mana Extended. I don't know how similar that is to the original MoM sourcecode but MoM Extended has more features that I don't want to use, hence I was basing my mod off the earlier MoM sourcecode.
I see. Sephi's code from 2013 also compiles without a hitch for me.

see declaration of 'sprintf'
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h
That sounds like TOOLKIT is set to
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC
And while it's good to address those problems with loop counters being used outside the loop, the VS2003 compiler shouldn't point them out.
Also, the "_Inc" gets flagged as an error by the VS2010 code editor, but is accepted by my VS2003 compiler.

If spaces in the path are a problem, then you could always rename the Toolkit 2003 folder to, say, "MSVCToolkit2003" and put it directly under C:\ or so. That also avoids any potential problem with the PROGRAMFILES environment variable.
 
Thinking about the issue with CrtDbgReportW, I suspect you need msvcrtd.lib version 7.1. It's in the 2003 toolkit. If you keep using 2010 for some reason, you get CRT version 10, hence no access to version 7.1. You really need to make sure you are compiling using 2003 only and not 2010. The makefile shouldn't contain any references to 2010.
 
Hi,

I restarted from scratch, trying to follow f1rpo's approach above.

I think I found the error I had created in my setup. The nmake.exe that I'd previously copied in was from VS2010, not the VS2003 toolkit. I'm no longer getting all of the various interesting messages. The error message has been reduced to,
Spoiler :

1>------ Build started: Project: Civ4DLL, Configuration: Debug Win32 ------
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "set TARGET=Debug
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake source_list /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake fastdep /NOLOGO
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake dll /NOLOGO" exited with code -1073741515.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


One bit that was unclear to me in f1rpo's post,
I
Opened the .sln file in VS 2010. Added all the files in CvGameCoreDLL so that I can access them in the VS code editor if needs be: right-clicked on the project (Civ4DLL) in the Solution Explorer, "Add->Existing item", marked everything in CvGameCoreDLL, added it.
Are these actions all taken within VS2010?
When saying add all the files in CvGameCoreDLL, is this all of the files in the renamed "CvGameCoreDLL" folder?
 
I think it should be fine using the 2010 version of nmake. What's important is which compiler the makefile calls. The makefile is really just a gigantic script, which calls a bunch of command line calls and together they end up compiling all the files and link them together. In theory you don't even have to use nmake at all. GNU make would actually be a better option and you don't even have to use any version of make. You can just type the right stuff in cmd and compile that way. Nmake is chosen primarily because everybody have it installed already. It's not my first choice from a technical point of view.

I have a hard time figuring out what's wrong with your setup. I think it would be a good idea to test if your compiler is set up correctly. The best way to do that would likely be to make you compile a mod, which has a known good setup. I propose my own We The People. It has project files and a custom makefile. This means if your compiler is set up correctly, you should be able to compile. Maybe you need to copy boost and python and maybe nmake, but other than that it should work out of the box if your compiler is installed correctly. You don't even have to have Colonization installed to test this since all versions of civ4 use the same compiler. This way we will know if it's a problem with your compiler or the mod itself.
 
One bit that was unclear to me in f1rpo's post,

Are these actions all taken within VS2010?
When saying add all the files in CvGameCoreDLL, is this all of the files in the renamed "CvGameCoreDLL" folder?
Yes to both; I've attached a screenshot.

So apparently Visual Studio fails to execute these commands from the .vcxproj file
Code:
<NMakeBuildCommandLine>set TARGET=Debug
nmake source_list /NOLOGO
nmake fastdep /NOLOGO
nmake dll  /NOLOGO</NMakeBuildCommandLine>
and even fails to set a proper error code. I doubt that the first command fails, so it's probably the second one. source_list is a target in the makefile. I don't think nmake gets to that because the source_list target would output "Building source list" on the console. Apparently nmake is found, because, if I simply rename nmake.exe, I get a different error.

Maybe you'd get a more informative error message by entering the commands separately into the Visual Studio command prompt (under "Tools").
To temporarily add the nmake path to the search path:
set PATH="c:\program files (x86)\microsoft visual studio 10.0\vc\bin";%PATH%
^Edit: Shouldn't be necessary after all; I think Visual Studio sets that already.

To browse into the folder with the makefile:
cd [insert your path here]\CvGameCoreDLL\project
Setting the TARGET variable should yield no response.
set TARGET=Debug
And finally:
nmake source_list
This gives me:
Code:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Building source list
 

Attachments

  • add-items.jpg
    add-items.jpg
    176.7 KB · Views: 157
Last edited:
Hi,

cd [insert your path here]\CvGameCoreDLL\project
There is no "project" subfolder there. Only subfolders are, "temp_files", "Debug", "obj" and "bin".

Thanks for the picture. Adding the files using the solution explorer did not appear to make a difference though.

@Nightingale, I'll download your sourcecode and try a compile with it. Not going to happen tonight though.
 
There is no "project" subfolder there. Only subfolders are, "temp_files", "Debug", "obj" and "bin".
Oh, OK. If you kept the makefile in CvGameCoreDLL, then just CvGameCoreDLL. Or whichever folder the makefile is in.
Thanks for the picture. Adding the files using the solution explorer did not appear to make a difference though.
Right, that's only a convenience for editing the source code in Visual Studio.
 
Hi,

Didn't get to try compiling @Nightingale's mod. It was taking too long to download (via my mobile).

I did nmake source_list, as @f1rpo suggested. I got the pop up;
nmake.exe - System Error
The program can't start because MSVCR71.dll is missing from your computer. Try reinstalling the program to fix this problem.

There is a comment in the makefile.inc file in the toolkit,
Spoiler :
# These are the prebuilt objects which are static link components in the
# MSVCR71[D].DLL implib


So the question is where do I get MSVCR71.dll or which program do I need to reinstall to fix the problem?
 
You may also want to copy it to the bin folder of the toolkit. Not sure if nmake looks for them there. It seems that the updated version I had linked to does not contain msvcr71.dll. On my system, this doesn't cause any problems, but perhaps it does on yours. Comparing the bin folders of the two toolkit versions, msvcp71.dll and dbghelp.dll are also absent from the updated version. All three files are in the BtS install folder and could hopefully simply be copied from there. Or if that still doesn't fix the problem, then I'd consider going back to the toolkit installer from Leoreth's thread.

Comparing the file version numbers:

BtS folder:
msvcp71.dll 7.10.3077.0
msvcr71.dll 7.10.3052.4
dbghelp.dll 5.1.2600.2180

2003 toolkit (from Leo's installer):
msvcp71.dll 7.10.3077.0
msvcr71.dll 7.10.3052.4
dbghelp.dll 6.0.17.0

Updated toolkit:
(none included)

Files extracted by @Anq (link): [edit: link fixed]
msvcp71.dll 7.10.6030.0
msvcr71.dll 7.10.6030.0
(dbghelp.dll not included)

I don't suppose much is gained or lost by using the most recent dlls.
 
Last edited:
Hi,

I copied both mscvp71.dll and msvcr71.dll from my Sid Meier's Beyond the Sword folder. After hitting the Build button , the last 4 lines are
Spoiler :

1> Creating library temp_files\Debug\CvGameCoreDLL.lib and object temp_files\Debug\CvGameCoreDLL.exp
1> COPY "temp_files\Debug\CvGameCoreDLL.dll" "Debug\CvGameCoreDLL.dll"
1> 1 file(s) copied.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

There's a new CvGameCoreDLL.dll file in the debug folder.

Thank you both very much for your patience and advice.

-----
For any other newbies (and myself if I come back to trying to work with the dll after a few months), the final compiling set up that worked for me was;
Spoiler :

1) I installed MS Visual Studio 2010 Express, as advised in @Leoreth's tutorial, https://forums.civfanatics.com/threads/the-easiest-way-to-compile-a-new-dll.608137/.
2) I installed @alberts2 toolkit from https://forums.civfanatics.com/thre...cussions-thread.377892/page-914#post-15499500 into a Microsoft Visual C++ Toolkit 2003 folder in Program Files (x86).
3) I copied @Nightingale's makefile version 2.5, available at https://forums.civfanatics.com/thre...tion-profiling-and-more.499166/#post-12549883 into my working folder.
4) I created a bin folder within the working folder and moved the fastdep application, provided in Nightingale's makefile into this.
5) Edit: I've switched back to using a CD installation, as I was not sure how to use Steamless. I've been able to run debugger using this.
6) I've copied the nmake application from the Toolkit into my working folder.
7) I've copied the mscvp71.dll and msvcr71.dll from my Sid Meier's Beyond the Sword folder into my working folder.
(Photo of the basic working folder is attached, without the sourcecode)
8) The sourcecode to be compiled is copied into the working folder. Note: For BtS, I copied everything from Beyond the Sword/CvGameCoreDLL folder. For FFH, I used copied everything from Beyond the Sword/CvGameCoreDLL folder and then overwrote with the modfied FFH files.
9) Edit: The CvTextScreens.cpp was deleted. I got an error on removing the resource.h, so I've kept it in.
10) Click on the Civ4DLL solution in the working folder.
11) Click the build button when VS 2010 Express opens up.
12) Copied the CvGameCoreDLL.dll file from the Debug folder in my working folder into Beyond the Sword/Mods/MyMod/Assets


-----

I have noticed that the dll that I compiled is almost three times bigger than the MoM original, 18,080 kb, versus 6268 kb.
Turns out it was only a partial success. I'm getting some error messages when loading the mod now, XML Load Error, Failed Loading XML file xml\Terrain/Civ4TerrainClassInfos.xml, and then leading on to
Spoiler :
Assert Failed: Civ4BeyondSword.exe
Assert Failed
File: .\.\CvXMLLoadUtilitySet.cpp
Line: 2040
Expression: false
Message: Empty XML File (Civ4TerrainInfos/TerrainInfos/TerrainInfo), last Type loaded was TERRAIN_OCEAN_DEEP


Going back to the totally unedited MoM sourcecode and using my compiling setup, that seemed to work, resulted in the 1>CvTextScreens.cpp(5): fatal error C1083: Cannot open include file: 'CvTextMgr.h': No such file or directory error again.

Deleted CvTextScreens.cpp and hit build again. This time it was a successful build. Again, the created CvGameCoreDLL.dll file is big, 18,084 kb. When loading the mod, the error, "XML Load Error, Failed Loading XML file xml\Terrain/Civ4TerrainClassInfos.xml" and the Assert error appear again.

Line 2040 in CvXMLLoadUtilitySet.cpp is the FAssertMsg(false, szLog); in
Spoiler :
Code:
           {
               sprintf(szLog, "Empty XML File (%s), last Type loaded was %s", szTagName, mszLastType.GetCString());
               FAssertMsg(false, szLog);
               break;
           }

Edited - as have switched to cd installed game, have stopped trying to pick and choose the files I'm supposed to use in the compilation and have had more success with compilation.
 

Attachments

  • WorkingFolder.PNG
    WorkingFolder.PNG
    65.1 KB · Views: 109
Last edited:
When you compile a debug DLL you include symbols in it, which debuggers and profilers can use to track the compiled code back to the source code. For instance if you have an assert failure, the debugger will tell you which line it's in. It can only do that if the symbols are included. Symbols takes up a lot of space. 18 MB with symbols and 6.2 MB without them sounds reasonable.

Another thing you include when you use a debug DLL is the assert checks. They tell of possible bugs in the game, but if you compile a release DLL, the assert checks are removed for performance reasons. This means the DLL included with MoM might have those issues too, but due to being a release DLL, it just skips telling the player.

It's generally a good idea to fix all causes of assert failures. When the code is bug free, it should also be free of assert failures. It's however easier said than done as it can take a lot of work to fix every single cause of assert failures.
 
For any other newbies (and myself if I come back to trying to work with the dll after a few months), the final compiling set up that worked for me was [...]
Thanks for that summary; I hope it'll save someone some trouble (perhaps me as well). Sorry if the toolkit archive I suggested ended up sending us on an extra lap.
I have noticed that the dll that I compiled is almost three times bigger than the MoM original, 18,080 kb, versus 6268 kb.
You can switch to the Release(-fast) build through the Configuration Manager. That's a bit awkward to reach; I'm attaching a screenshot. However, this error
"XML Load Error, Failed Loading XML file xml\Terrain/Civ4TerrainClassInfos.xml"
may still show up and sounds rather critical. There might be further info in the xml.log (My Games\Beyond the Sword\Logs). As for the assertion, I'm not familiar with this one. It's in a function SetGlobalClassInfo of the "TrueModular" mod component, which, apparently, overhauls parts of the (modular) XML loading code.

With a debugger attached, you could get some more info out of the assertion, in particular the call stack leading up to the SetGlobalClassInfo call. But, last I heard, the Steam installation doesn't work with a debugger, so that's no immediate help. Actually, there's probably no reason then to use a debug build; an assert build should suffice. It'll also provide line numbers – not through debug symbols but through the __FILE__ and __LINE__ macros.
Spoiler FAssert.h :
Code:
bool FAssertDlg( const char*, const char*, const char*, unsigned int, bool& );

#define FAssert( expr )   \
{ \
   static bool bIgnoreAlways = false; \
   if( !bIgnoreAlways && !(expr) ) \
{ \
   if( FAssertDlg( #expr, 0, __FILE__, __LINE__, bIgnoreAlways ) ) \
{ _asm int 3 } \
} \
}
I'd recommend windowed mode for any build with assertions as an assertion popup in full-screen can make the whole system unresponsive – though perhaps this doesn't apply to every system.
 

Attachments

  • open_config-manager.jpg
    open_config-manager.jpg
    275.2 KB · Views: 123
I'd recommend windowed mode for any build with assertions as an assertion popup in full-screen can make the whole system unresponsive – though perhaps this doesn't apply to every system.
Usually alt+tab still works. Having a debugger attached and reaching a breakpoint is the problematic one. You need control+alt+delete to open the task manager to reach MSVS if that happens. Still window mode is recommended because it's the easiest solution.

But, last I heard, the Steam installation doesn't work with a debugger, so that's no immediate help.
Steamless solves that problem. It removes the steam DRM from some exe files (civ4 included) and then if you play with the new exe file you can use the debugger.

this error
"XML Load Error, Failed Loading XML file xml\Terrain/Civ4TerrainClassInfos.xml"
may still show up and sounds rather critical.
I agree that it sounds critical and should be fixed. However I'm not convinced the problem is caused by LPlate2. It wouldn't be the first time a mod has an issue, which is "fixed" by releasing a DLL without assert checks.
 
Usually alt+tab still works. Having a debugger attached and reaching a breakpoint is the problematic one. [...]
Yes, I think that's it. Didn't remember anymore exactly how that happens.
Steamless solves that problem. It removes the steam DRM from some exe files (civ4 included) and then if you play with the new exe file you can use the debugger.
Ah, that's good to know. (You've mentioned Steamless before, but somehow that hadn't registered with me.)
I agree that it sounds critical and should be fixed. However I'm not convinced the problem is caused by LPlate2. It wouldn't be the first time a mod has an issue, which is "fixed" by releasing a DLL without assert checks.
Right; and perhaps it's not as bad as it sounds. I guess most or all of the TerrainClass data could already be loaded when the Load Error occurs.
 
At this point, it looks like I've a fair bit of work to do.
I fixed the TerrainClassInfos error and a couple of other load xml errors.
Some assert errors are possibly ignored minor issues from the original mod.
Some(most?) are possibly down to extensive xml pruning that I performed in my mod. I've noticed specific BUILDING_, PROMOTION_, etc references in the cpp files. I think I need to go through each cpp and trim out infotype specific references, where I'm no longer planning to use that infotype.
I thought that it was recommended practice to try to avoid infotype specific references in the dll, unless it's really essential to a mod.
 
Are you using any sort of version control for your code modifications (code as in either source code or xml)?

I highly recommend using git as it can help to keep track of what you are doing and very importantly you can commit to "bookmark" stages of the source code you might want to revert to in the future. Way too often people write something on the forum after they have messed up their source code and have to spend ages fixing it when using git could have reverted the damage in minutes.

I thought that it was recommended practice to try to avoid infotype specific references in the dll, unless it's really essential to a mod.
It is, but just like car drivers aren't supposed to exceed the speed limit, it happens anyway. It doesn't sound great to have specific references to either promotions or buildings. In general what is in xml shouldn't be hardcoded in the DLL. It makes the code prone to break if somebody works on the xml in the future.

There are exceptions though. For instance UnitAI. When filling out unit xml data, the modder tells the AI how to use the unit (worker, settler, spy, explorer etc). However in order to assign an entry to an xml tag, the xml engine requires it to be another xml file. Because of this there is a UnitAI xml file, which only serves the purpose of matching the DLL's number and order of UnitAI entries. This is a valid reason to hardcode xml data in the DLL.

However I can't think of a good reason to hardcode either buildings or promotions. If you really need something special for a specific entry, you can always add a bool tag to the xml and then check for that bool in the dll. Not great, but at least it's not completely hardcoded and a bool tag is at least visible in xml.
 
Top Bottom