Crash to desktop, with recurring error code in .dmp file

The source files listed in the vcxproj file don't matter much. Those are just files that VS will list in the Solution Explorer. When compiling, this rule in the Makefile ...
Code:
{$(SOURCE_DIR)\.}.cpp{$(TEMP_TARGET_FILES)\.}.obj:
	@ECHO.>"$*.obj.@"
	@$(CPP) /nologo $(CFLAGS) $(PRECOMPILE_CFLAGS1)$(PRECOMPILE_CFLAGS2) $(INCS) /Fo$*.obj /c $<
	@DEL "$*.obj.@"
... will compile every cpp file in the SOURCE_DIR (same directory as the Makefile if no SOURCE_DIR set in Makefile.project). Probably looks a little different in dave_uk's Makefile, but none of these project setups rely on the lists in the vcxproj. (The h files aren't compiled separately; the cpp files include them.) To make the files listed in the Solution Explorer consistent with those in the SOURCE_DIR, one can remove everything from the Solution Explorer window and then use "Add Existing Item" and select everything in the SOURCE_DIR. This change gets saved in the vcxproj file (upon exiting VS?).

CvTextScreens.cpp – Leoreth has removed that file entirely. It was, apparently, accidentally included in the DLL source released by Firaxis. CvTextScreens is not referenced anywhere else, so the compiler or linker should discard it at some point.
BetterBTSAI.cpp – Someone might have forgotten to add that in the Solution Explorer when LoR was merged with BBAI. Oh, well.
At this point, I'm going to just make methodical changes to dave uk source files, but not sure where to start.
You mean that you're still merging Leoreth's project files with dave_uk's? As far as I recall, there is nothing worth preserving in dave_uk's Makefile, vcxproj, sln and, let's see, what else is there ... the vcprojs are outdated, the suo and filters should be generated locally by VS. I'd just delete all that (actually have already done so in my local copy and in the files I uploaded). As for changing the actual C++ source – the cpp and h files – I assume that you want to get the debugger running before making changes there. (And, then, the first change to make will hopefully fix the crash you've been experiencing.)
 
The source files listed in the vcxproj file don't matter much. Those are just files that VS will list in the Solution Explorer. When compiling, this rule in the Makefile ...
Code:
{$(SOURCE_DIR)\.}.cpp{$(TEMP_TARGET_FILES)\.}.obj:
    @ECHO.>"$*.obj.@"
    @$(CPP) /nologo $(CFLAGS) $(PRECOMPILE_CFLAGS1)$(PRECOMPILE_CFLAGS2) $(INCS) /Fo$*.obj /c $<
    @DEL "$*.obj.@"
... will compile every cpp file in the SOURCE_DIR (same directory as the Makefile if no SOURCE_DIR set in Makefile.project). Probably looks a little different in dave_uk's Makefile, but none of these project setups rely on the lists in the vcxproj. (The h files aren't compiled separately; the cpp files include them.) To make the files listed in the Solution Explorer consistent with those in the SOURCE_DIR, one can remove everything from the Solution Explorer window and then use "Add Existing Item" and select everything in the SOURCE_DIR. This change gets saved in the vcxproj file (upon exiting VS?).

CvTextScreens.cpp – Leoreth has removed that file entirely. It was, apparently, accidentally included in the DLL source released by Firaxis. CvTextScreens is not referenced anywhere else, so the compiler or linker should discard it at some point.
BetterBTSAI.cpp – Someone might have forgotten to add that in the Solution Explorer when LoR was merged with BBAI. Oh, well.
You mean that you're still merging Leoreth's project files with dave_uk's? As far as I recall, there is nothing worth preserving in dave_uk's Makefile, vcxproj, sln and, let's see, what else is there ... the vcprojs are outdated, the suo and filters should be generated locally by VS. I'd just delete all that (actually have already done so in my local copy and in the files I uploaded). As for changing the actual C++ source – the cpp and h files – I assume that you want to get the debugger running before making changes there. (And, then, the first change to make will hopefully fix the crash you've been experiencing.)
Thanks, that is useful.
No, I'm not merging anything. Will see what progress I can make when I'm not at work.
 
BetterBTSAI.cpp – Someone might have forgotten to add that in the Solution Explorer when LoR was merged with BBAI. Oh, well.
use "Add Existing Item" and select everything in the SOURCE_DIR. This change gets saved in the vcxproj file (upon exiting VS?).
OK, so I understand the relevance of vcxproj now. There is a BetterBTSAI.cpp and other cpp files that reference or connect to it.
Gonna try and get a better result by adding items myself. Do I need the cpp and .h files to compile a working DLL?
 
Do I need the cpp and .h files to compile a working DLL?
Yes, they're the main thing, the Makefile and VS files just tell the compiler and Visual Studio where to find them (and where to find libraries not specific to Civ). Once you run the game, only the DLL matters (and XML and Python and artwork). Oh, maybe your question is, do you need the C++ source file names inside the vcxproj file? No. That's only for being able to edit them more easily in VS.
 
only the DLL matters
Finding that out.
I've had a successful F7 after modifying dave uk makefile
F5 didn't work, it's looking for CvGameCore.dll in the SourceDir(CvGameCoreDLL folder)
Leoreth's files compiled a new DLL that didn't work with dave uk Assets
It's looking like dave uk source files did not compile a DLL, or I could be wrong there
Spoiler :
F5.png


So I need to figure out what to change to the makefile to get the new DLL in the right place?
 
I think you're missing the proper debug command in the debug build configuration. This thing:
VS thinks that you're trying to debug the compiled "solution" (CvGameCoreDLL), but you actually want to attach the debugger to Civ4BeyondSword.exe, which will then load the DLL. The debug command gets stored in a vcxproj.user file by VS.
Yes, I over looked that earlier.
Not sure if I'm compiling it right though, because I wasn't able to find the new DLL, and not sure if it did make a new DLL.
The build config thing worked, and it loaded Civ4
but got this
Spoiler :
F5.jpg

Which I ignored(Yes)
And got this:
Spoiler :
assertion.failed.jpg



Sorry about the size of the images

Here is the VS output
Spoiler :

'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Civ4BeyondSword.exe', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\apphelp.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\AcLayers.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\win32u.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\gdi32full.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\msvcp_win.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\ucrtbase.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\shlwapi.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\oleaut32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\combase.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\bcrypt.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\mpr.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\sfc.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\winspool.drv', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\sfc_os.dll', Cannot find or open the PDB file
FTH: (1188): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. ***
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\SortWindows61.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\ws2_32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\boost_python-vc71-mt-1_32.dll', Binary was not built with debug information.
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\zlib1.dll', Binary was not built with debug information.
'Civ4BeyondSword.exe': Unloaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\zlib1.dll'
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\binkw32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\msvcp71.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\version.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\python24.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\msvcr71.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\winmm.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mss32.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\d3dx9_33.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\hapdbg.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Unloaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\hapdbg.dll'
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\dsound.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\powrprof.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\winmmbase.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\zlib1.dll', Binary was not built with debug information.
'Civ4BeyondSword.exe': Loaded 'C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\hapdbg.dll', Cannot find or open the PDB file
'Civ4BeyondSword.exe': Loaded 'C:\Windows\SysWOW64\umpdc.dll', Cannot find or open the PDB file
The program '[1188] Civ4BeyondSword.exe: Native' has exited with code 0 (0x0).
 
Not sure if I'm compiling it right though, because I wasn't able to find the new DLL, and not sure if it did make a new DLL.
The Output window should say "Linking DLL and "1 file copied" at the end. If linking succeeded already the last time, then it'll only copy the DLL (from temp_files\Debug to YOURMOD\Assets).
[...] Which I ignored(Yes)
Always to be ignored. I suppose I must've gotten that myself once, long ago (and clicked always ignore); I wouldn't remember anymore.

The failed assertion comes from the EXE, hence no option to debug it. FFreeListTrashArray.h is part of the DLL too, but has also been compiled into the EXE. Why it is failing is harder to say. The VS output does not say that the GameCoreDLL has been loaded. I suppose that, when the mod name is passed as a command-line argument, the EXE will load the mod before loading the original GameCoreDLL. So I guess something is going wrong very early on in the process of loading the mod. This assertion isn't really helpful without context (which the debugger would provide if it were an assertion in the DLL). Could try taking away the "mod=" argument – to make sure that attaching the debugger to unmodified BtS at least works. And could then load the mod from the "Advanced" menu (debugger still attached), see what goes wrong next. Or ignore the failed assertion – again, hoping that the next error will be more illuminating.
 
The Output window should say "Linking DLL and "1 file copied" at the end. If linking succeeded already the last time, then it'll only copy the DLL (from temp_files\Debug to YOURMOD\Assets).
I've tried 2 different makefiles so far. Nightingale's(2.5) and the 1.0 version in dave uk's source. I have had the most success with the older one, but I don't know what to change in it to successfully compile the DLL.
 
With that old build system, the paths for TOOLKIT, PSDK, YOURMOD need to be edited inside the Makefile. The line that sets YOURMOD needs to be uncommented. The sample path goes through My Games, but I assume that you're using the Mods folder under Program Files (x86). The Makefile will look for the Boost and Python24 directories only in the source directory, i.e. in the same directory as the Makefile.

Will have to use the old vcxproj file along with that Makefile; can't mix in Nightinggale's files. I guess the old solution (sln) file should also be used (though I think VS will generate a fresh one when the vcxproj is opened and no sln exists). All the other project stuff (vcproj, suo, vspscc, filters) in dave_uk's archive should be discarded even when keeping his build system.

I'd agree that getting something to work at all would be more important than having the latest and greatest. On the other hand, I don't think the more recent Makefile is somehow more fragile or more difficult to configure. (Well, Nightinggale's upload doesn't include an empty template for Makefile.settings, and having to generate that file - by attempting to compile without it - is not intuitive.)
 
With that old build system, the paths for TOOLKIT, PSDK, YOURMOD need to be edited inside the Makefile. The line that sets YOURMOD needs to be uncommented. The sample path goes through My Games, but I assume that you're using the Mods folder under Program Files (x86). The Makefile will look for the Boost and Python24 directories only in the source directory, i.e. in the same directory as the Makefile.

Will have to use the old vcxproj file along with that Makefile; can't mix in Nightinggale's files. I guess the old solution (sln) file should also be used (though I think VS will generate a fresh one when the vcxproj is opened and no sln exists). All the other project stuff (vcproj, suo, vspscc, filters) in dave_uk's archive should be discarded even when keeping his build system.

I'd agree that getting something to work at all would be more important than having the latest and greatest. On the other hand, I don't think the more recent Makefile is somehow more fragile or more difficult to configure. (Well, Nightinggale's upload doesn't include an empty template for Makefile.settings, and having to generate that file - by attempting to compile without it - is not intuitive.)
Thanks.
I followed those instructions to the word.
F7 completes, but can't find a new DLL
F5 loads and gets the same error as previously when loading save game.
So something has changed.
With Nightinggale's files and build F7 completed(can't remember if it "linked" as you said earlier, it needs to do, but possible). Can't remember if it was game or save loading that crashed. I could find evidence of DLL changing.
Current DLL is different size to the original, but "Date Modified" isn't recent(ie, same time as log file).

Spoiler F7 log file :

Build started 16/10/2022 13:35:38.
1>Project "C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Lor Mod\CvGameCoreDLL\CvGameCoreDLL.vcxproj" on node 2 (build target(s)).
1>Build:
nmake Debug

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.

COPY "Debug\CvGameCoreDLL.dll" "C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Lor Mod\Assets\."
1 file(s) copied.
1>Done Building Project "C:\Program Files (x86)\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Lor Mod\CvGameCoreDLL\CvGameCoreDLL.vcxproj" (build target(s)).

Build succeeded.

Time Elapsed 00:00:01.81

Current makefile is fresh from modmod .rar and modified as you specified.
Have just tried Nightinggale VS files(TOOLKIT PSDK, etc set appropriately) & dave uk source(C++ files and so on)
Spoiler :

1>------ Build started: Project: CvGameCoreDLL, Configuration: Debug Win32 ------
1> Building source list
1> Running fastdep
1> bin\fastdep.exe: unrecognized option `--removepath=.\'
1> bin\fastdep.exe: unrecognized option `--removepath=.\'
1> BetterBTSAI.cpp
1> CvBugOptions.cpp
1> CvTextScreens.cpp
1>CvTextScreens.cpp(5): fatal error C1083: Cannot open include file: 'CvTextMgr.h': No such file or directory
1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Civ4SDK\Microsoft Visual C++ Toolkit 2003\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 ==========


That was probably unnecessary. I can switch back to configuration you recommend.
 
Current DLL is different size to the original, but "Date Modified" isn't recent(ie, same time as log file).
If there's already a DLL in the Debug folder and none of the source files have changed, then the Makefile just causes that DLL to be copied. To force a partial rebuild, you could just edit any cpp file, e.g. add a space somewhere and remove it again, to cause a change to that file's last-modified date. For a full rebuild, Ctrl+Alt+F7 should work. But it sounds to me like the DLL that is getting copied is already compiled from dave_uk's source files, so I expect that rebuilding won't change anything.
F5 loads and gets the same error as previously when loading save game.
Which one is that? The FFreeListTrashArray assertion? But that would occur already upon loading the mod. If that's still happening, then I'd suggest to try this:
Could try taking away the "mod=" argument – to make sure that attaching the debugger to unmodified BtS at least works. And could then load the mod from the "Advanced" menu (debugger still attached), see what goes wrong next. Or ignore the failed assertion – again, hoping that the next error will be more illuminating.
CvTextScreens.cpp(5): fatal error C1083: Cannot open include file: 'CvTextMgr.h': No such file or directory
May need to uncomment this variable in the Makefile or else remove the (unused) CvTextScreens.cpp:
Code:
## Uncomment to block CvTextScreen (accidentally included by Firaxis)
# BLACKLIST=CvTextScreens
bin\fastdep.exe: unrecognized option `--removepath=.\'
This one is probably harmless – but puzzling. fastdep gets invoked here
Code:
@$(FD) --objectextension=pch -q --removepath=$(SOURCE_DIR)\ -O $(TEMP_TARGET_FILES) $(SOURCE_DIR)\CvGameCoreDLL.cpp >> $(FILE_DEPENDS)
in the Makefile. Your SOURCE_DIR appears to be set to a dot, i.e. the current directory, which should be fine. In any case, I don't think this will cause compilation to fail. fastdep itself isn't really needed and it looks like it actually does its job despite the unrecognized option. :think: The old Makefile also uses fastdep, but without the removepath option. Perhaps that option was added in a more recent version of fastdep, meaning that the fastdep.exe from Nightinggale's upload needs to be used. You might be using the old fastdep version with the new Makefile.
fastdep seems like a pretty obscure utility that, I guess, Danny Daemonic first introduced into the Civ world. I can't find documentation or a change history through Google.
 
Had a success with VS.
Spoiler :

Assert Failed

File: CvSelectionGroup.cpp
Line: 1509
Expression: false
Message:

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

1509 below
Spoiler :

/* Afforess Start 02/14/10 */
/* */
/* */
/************************************************************************************************/
case MISSION_INQUISITION:
/************************************************************************************************/
/* Afforess END */
/************************************************************************************************/
break;

default:
FAssert(false);<1509
break;
}

if ( bNotify )
{
NotifyEntity( headMissionQueueNode()->m_data.eMissionType );
}


I pressed Ignore and got the same message a few times.
Then
Spoiler :
Run-Time Check Failure #3 - The variable 'pTheirNearestCity' is being used without being defined.

Pressed 'Continue'
Then this
Spoiler :

First-chance exception at 0x05b91a51 (CvGameCoreDLL.dll) in Civ4BeyondSword.exe: 0xC0000005: Access violation reading location 0xccccccdc.
Unhandled exception at 0x05b91a51 (CvGameCoreDLL.dll) in Civ4BeyondSword.exe: 0xC0000005: Access violation reading location 0xccccccdc.

Which VS referred to the first line in this, some more is included so it can be located
Spoiler :

return m_iY;
}
#endif
bool at(int iX, int iY) const; // Exposed to Python
bool at(CvPlot* pPlot) const; // Exposed to Python - atPlot
DllExport CvPlot* plot() const; // Exposed to Python
CvPlotGroup* plotGroup(PlayerTypes ePlayer) const;
bool isConnectedTo(CvCity* pCity) const; // Exposed to Python
bool isConnectedToCapital(PlayerTypes ePlayer = NO_PLAYER) const; // Exposed to Python
int getArea() const;
CvArea* area() const; // Exposed to Python
/************************************************************************************************/
/* BETTER_BTS_AI_MOD 01/02/09 jdog5000 */
/* */


I can reproduce the crash if necessary.
 
Generally, it would be helpful to choose "Debug" or "Break" when a failure occurs, so that the call stack can be examined. In this case, it seems pretty clear that some variable pTheirNearestCity being used without having been defined is causing the crash (when its y-coordinate gets accessed). A text search in the source code shows that only one function has a variable of this name: CvTeamAI::AI_estimateClosestCityDistance

A comment in CvTeamAI.h indicates that this function was added by dave_uk. Seems to be his original work. He uses it only in one place, namely to (comment) "disincentivise going for very far away land targets" in CvTeamAI::AI_startWarVal. Anyway, looks like dave forgot to set pTheirNearestCity = NULL; at the start of AI_estimateClosestCityDistance. My guess is that the line pTheirNearestCity = pTestCity; in the first loop isn't reached, then, if (pTheirNearestCity != NULL) is true because an uninitialized variable can happen to be NULL but could also have any other value, and then CvCity::plot (several times), CvCity::getX_INLINE and CvCity::getY_INLINE are called through the uninitialized pTheirNearestCity for the purpose of distance calculations. This is at best going to result in erroneous distances, at worst it'll cause a crash resulting from an access violation. Well, I suppose the crash is really the better outcome because it makes the problem apparent. Edit: Actually, as far as I understand, the debug build helpfully sets unitialized variables to 0xcccccccc. That's never NULL and should cause an access violation as soon as any function is called through the pTheirNearestCity variable.

So it seems that the line number in the dmp was actually correct – it had pointed to CvCity::plot. That's not where the crash occurred this time, but it can (most likely) occur there as well with a release build. It's just that this information is unhelpful without further context, and the stack trace in the dmp was apparently rubbish.

As for CvSelectionGroup: I don't think this leads to the crash. There might be code missing for handling some newly introduced mission, but it could also be (seems more likely) that actually no special handling is needed and that whoever added the mission just forgot to explicitly add a
case MISSION_...: break;
to prevent the assertion from failing. To get to the bottom of that, one would have to choose "Debug" when the assertion fails and hover over the "eMissionType" in the line switch (headMissionQueueNode()->m_data.eMissionType) to see which type of mission isn't being handled.
 
Last edited:
It's actually strange that pTheirNearestCity = pTestCity; isn't reached (if that's what is happening). This should only happen if the AI team that is planning for war has no cities or if its potential war target has no cities. If either side has no cities, then the AI should probably disregard such a war already at an earlier point. It would be interesting to know what the two team IDs are in CvTeamAI::AI_estimateClosestCityDistance. To this end, I would first fix the immediate problem by initializing pTheirNearestCity to NULL, recompile (debug build), set a breakpoint by clicking left of the return -1;, load the save and, when the breakpoint is hit, hover over the eTeam variable to inspect its value and look up m_eID under "this" --> "CvTeam" in the Locals window for the ID of the team that does the war planning.
 
At the start and at the end of AI_estimateClosestCityDistance:
Code:
int CvTeamAI::AI_estimateClosestCityDistance(TeamTypes eTeam) const
{
    CvCity* pOurCapitalCity;
    CvCity* pTheirNearestCity = NULL;
    CvCity* pOurNearestCity;
    // ...
    return -1;
}
Perhaps best to first verify that the crash no longer occurs when pTheirNearestCity is properly initialized. Then, for the breakpoint, a click into the gray bar on the left margin should result in a red dot next to the return -1. Like in this screenshot:
Spoiler :

 
At the start and at the end of AI_estimateClosestCityDistance:
Done:
Code:
//finds the distance between what we estimate to be our nearest two cities:
//finds the nearest city to our capital, and then our nearest one of our cities to that city
//returns the step distance if we didn't find one of their cities in one of our capital areas
//and the path distance otherwise. returns -1 if it fails to find anything
//Not guaranteed to be the nearest two cities but faster than checking every one
int CvTeamAI::AI_estimateClosestCityDistance(TeamTypes eTeam) const
{
    CvCity* pOurCapitalCity;
    CvCity* pTheirNearestCity = NULL;
    CvCity* pOurNearestCity;
    int iBestDistance = MAX_INT;
    int iI;
    bool bSameArea = true;

    for (iI = 0; iI < MAX_PLAYERS; iI++)
    {
Not sure where the opportunity to initialise pTheirNearestCity occurs in this code:
Code:
    int iNearestCityDistance = AI_estimateClosestCityDistance(eTeam);
            if (iNearestCityDistance > iMaxDistance)
            {
                iValue *= iMaxDistance;
                iValue /= iNearestCityDistance;            
                iValue *= 100;
                iValue /= 100 + iProximityModifier;
            }
        }
        else if (AI_isAnyMemberDoVictoryStrategy(AI_VICTORY_DOMINATION3))
        {
            iValue *= 3;
            iValue /= 2;
        }
    }
    //CD Tweaks End

The other instances of pTheirNearestCity involve it being used in conjunction with other variables.
 
It only needs to be initialized once, so the change you've made should be sufficient, i.e. should at least prevent the crash (once you've re-compiled the DLL). As for the code snippet from AI_startWarVal – yes, that's the one place where AI_estimateClosestCityDistance gets called. But the caller doesn't need to worry about pTheirNearestCity – that variable is local to AI_estimateClosestCityDistance. The caller only sets the two teams (one is "this" AI team, i.e. the same team that is calculating a "startWar" value, the other is given by the eTeam parameter, which is an enum-type team ID) and then stores the returned distance value in the iNearestCityDistance variable (which is local to AI_startWarVal).
 
when the breakpoint is hit, hover over the eTeam variable to inspect its value and look up m_eID under "this" --> "CvTeam" in the Locals window for the ID of the team that does the war planning.
ID=11

During the week, when I had time, I was trying to recreate the success I had last weekend. I had no luck whatsoever. This morning, I finally got it all working and was able to debug. I got the makefile settings right, but the command argument in cvgamecoredll properties was not set correctly. I was pulling my hair out, until I had a read through of the output, and saw that VS was trying to use standard BTS cvgamecore.dll. Anyway, I've been doing lots of reading about compiling recently, so it was a simple fix
I didn't get anywhere with finding out the mission id(break point added). Hovering over the text you mentioned revealed nothing. Looking in the tabs under (locals, auto, etc) provided a lot of info, but as you thought this was possibly not the cause of the crash, I left it and waited for another break.

CvTeamAI.cpp Line 6566 bShareValid not defined
Runtime check failure #3 variable 'bShareValid' is being used without being defined.

Still no connections to the getcompletedspaceshipproject from the dmp file?

Then the turn completed. :confused:

So I replaced the VS dll with the standard dave uk dll, tried the turn again, and no crash.
 
Top Bottom