Changing DLL constants / #defines - gotcha!

[whoward69]

Nearly all of the useful constants, #defines and enums used within the cpp code come from CvDLLUtilDefines.h and CvEnums.h - including MAX_CIV_PLAYERS, MAX_MAJOR_CIVS et al and all of the AI "decision" values.

These two files are not actually part of the "CvGameCoreDLL" code base but are included from the "CvGameCoreDLLUtil" code base - for which we only have the headers and the pre-compiled library file.

The CvGameCoreDLLUtil code base is shared with the exe file (and presumably the other dlls, eg CvGameDatabase) - note the comments at the top of these files, especially the word "shared" in CvEnums.h

//! \file   CvDLLUtilDefines.h
//! \brief  Public header Civ5 definitions that are external to the DLL.
//! This header includes all macros and defines that are external to the DLL

//! \file   CvEnums.h
//! \brief  Public header common Civ5 enumerations
//!  This header includes all enumerations shared by both exe and dll.

So while we could edit these files to change the values used within the CvGameCoreDLL .cpp code files, there is no guarentee that the resulting changed code will be compatible with the .exe and other .dll files! In fact, Gedemon's "34 Civs DLL (for YnAEMP)" modded DLL not loading LeaderHead screens for more than the first 22 (default number) civs is a very strong indication that there are dependencies in the other code bases that we do not have access to.

Adding another entry to one of the AI decision enums crashed my game (not immediately but after 70 to 80 turns) presumably because the value passed from the GameCore code to some other code was not one that was expected. This is going to make extending the AI (as opposed to altering its current behaviour/response) tough, as you can't, with any certainity, add new behavioural outcomes to the AI enums (eg adding a new spy task in addition to "rig election" and "steal tech").

So what's the point of this post ... really just to say don't be surprised if you change one of the values in these files and you get reports of (apparently random) game crashes!

 

[daviiadams]

I take it this scenario is likely to render a lot of ideas useless as a result?

Granted, I'm largely naive to the world of modding, but it seems especially hap-hazard in general since the Fall Patch. I'm finding all sorts of things to work one minute and not the next and, from what I've read about the dll, that doesn't sound like much more fun either thus far :-S

 

[whoward69]

I take it this scenario is likely to render a lot of ideas useless as a result?

It will make some of them a heck of a lot harder and/or lead to a lot of wasted time/effort/morale/enthusiasm

 

[trystero49]

Yes, when I was looking through Gedemon's mod I was confused that he was changing a header file that plainly said it was external to the .dll whose source we had access to.

So what does this mean for the future?

 

[whoward69]

So what does this mean for the future?

It means any mod that changes those headers are taking a huge gamble that the resulting conflicting values will not be fatal to the other exe/dll modules - at some unspecified future point in a player's game.

 

[Irkalla]

I get the idea that there's some things they just don't want us to do. Possibly reserving such things for an expansion or DLC.

 

[Gedemon]

It means any mod that changes those headers are taking a huge gamble that the resulting conflicting values will not be fatal to the other exe/dll modules - at some unspecified future point in a player's game.

So that could explain the problem I have trying to fix this : http://forums.civfanatics.com/showthread.php?t=473022 ?

When using a modded DLL the path of the farray file in the assertion is not "c:\buildagent\work\..." anymore, and is pointing not to my source code directory, but to "d:\Firaxis\civ5expansion\...", and fire even if I comment out the assert on line 149 to test.

The files related to the issue (CvWorldBuilderMapTypeDesc.h, farray.h) are in CvGameCoreDLLUtil

 

[trystero49]

Threadjack Noob question: These header files with the constants are external to the .dll. They also don't show up in the .proj file. So how can you change this file and end up with a resulting difference in the compiled .dll? I thought this file was external to the .dll? Doesn't that mean that file isn't compiled?

 

[PawelS]

If I understand it correctly, the file itself isn't compiled, but the constants defined there are used in files that are compiled. Correct me if I'm wrong.