[BTS] The Easiest Way to Compile a New DLL

[Nightinggale]

From previous experience with some other unrelated program (in VB6), I had a hunch that the DLL needs registering, and therefore opening the DLL (CvGameCoreDLL.dll) in Notepad++ would be enough to register it. Apparently this worked. After opening and closing the DLL in Notepad, I can launch Civ4 with the mod and it opens I can start games and play without issue. But just once.

That's a new one. Have you tried starting with the debugger attached to see where it crashes? Also which OS are you running? I kind of assume Windows 11 and that it could be a file permission issue.

I would like to see this for myself, but it doesn't look like your git repository is public.

 

[Basilmoyh]

Actually, after looking at it today, it seems more random whether or not is passes the Black Screen of Death. If it crashes and I just try try again and it will start within a few attempts the game seems to runs with no issues.

I did create my repo yesterday and set it to public.

GitHub - Basilmoyh/Civ4

Contribute to Basilmoyh/Civ4 development by creating an account on GitHub.

github.com

 

[Mr Smith]

You need to use VS2003 because that's the compiler, which was used with the exe.

I used C++ Toolkit 2003 per Asaf's and Leoreth's guides, so that's not enough?

Since the 2003 version does the actual compilation, the resulting DLL file will be unaffected by which version of visual studio you use.

Those are your own words. Am I not using 2003 compiler already? I had the same Boost and Python24 libraries Xyth used when he compiled the stable DLL and since then replaced them with those used by C2C team, it still didn't help.

As I understand it, it has become possible to mix, but only if all versions involved are 2015 or newer.

So can I shift to 2022 or should I go back to 2003? The problem is only present on Steam version and chances are some extra layer it adds is responsible, how would I even know which environment to conform with, especially with Civ4 still being a VS2003 application? Can someone at least clarify if having a specific .NET 4.0 would impact DLL compilation so that it's less stable on other PCs?

Read this. It's written for Civ4colo, but it applies to BTS too.

I already mentioned Original Release, for many people using anything but Steam for connection isn't an option. I had high hopes for ZeroTier, but turned out my friend's router is so cursed, he couldn't even connect to ZeroTier itself, not to mention other people. So my question about transplanting Steam's superior NATNeg (or whatever it does instead) or enabling Direct IP on Steam version still stands.

Hamachi avoids having to open ports or dealing with router settings.

From what I've heard in the multiplayer community it's not true, Hamachi (and orther LAN emulators) still can fail to connect more than 2 players if they don't have at least some replacement for Gamespy's NATNeg, even if Hamachi is whitelisted for PC's firewall.

which is free for up to 5 players

RadminVPN is just free and doesn't require manually shifting network adapter or even rebooting before it starts to work like was the case for Hamachi when I still used it. Maybe ZeroTier is still better in bypassing firewalls, though.

 

[Basilmoyh]

Well, it was working. For a couple weeks it would open with about a 50% success rate of passing the Black Screen of Death. But as of yesterday, it just won't pass the Black Screen of Death anymore.

I tried attaching to process. That didn't seem to do anything. But it might be hard because you can't pause Civ4, and it's probably only active for that short time before it reaches the Black Screen of Death.

I tried the event viewer but it was pretty useless. Just said it had a memory violation. It had a location within the DLL.

I turned on logging. The 'PythonDbg.log' logs just end here

...
419: 16:25:59 DEBUG: BugEventManager - adding event 'combatLogCollateral'
420: 16:25:59 DEBUG: BugEventManager - adding event 'combatLogFlanking'
421: 16:25:59 DEBUG: BugEventManager - adding event 'playerRevolution'
422: 16:25:59 DEBUG: BugInit - game not fully initialized
423: PY:OnInit

A normal log will continue.

...
419: 16:37:39 DEBUG: BugEventManager - adding event 'combatLogCollateral'
420: 16:37:39 DEBUG: BugEventManager - adding event 'combatLogFlanking'
421: 16:37:39 DEBUG: BugEventManager - adding event 'playerRevolution'
422: 16:37:39 DEBUG: BugInit - game not fully initialized
423: PY:OnInit
424: load_module Full_of_Resources_3_00
425:
426: load_module CvOptionsScreenCallbackInterface
427:
428: load_module copy

When/if my mod passes the Black Screen of Death, it gets the same logs.

I tried building the BBAI "CvGameCoreDLL.dll" from their source code, but that gets a Black Screen of Death too.

The only thing of note is that I use a different makefile because the BBAI makefile has these errors

1>NMAKE : fatal error U1073: don't know how to make 'source_list'
1> Stop.
1>NMAKE : fatal error U1073: don't know how to make 'fastdep'
1> Stop.
1>NMAKE : fatal error U1073: don't know how to make 'dll'
1> Stop.

And since the makefile is written in a alien language, I can't decipher what that means nor how to fix them.

The BBAI "CvGameCoreDLL.dll" file, when I build it comes out as 5072 KB, while the one they built is 5364 KB.

It is Windows 11. I tried running Civ4 in Administrator and different Compatibility mode. Still no dice.

I had my Document in DropBox and moved them out of the cloud, not that that should cause a problem that's unique to the mod though.

I don't have any other ideas on how to debug this.

 

[f1rpo]

@Basilmoyh: I've downloaded your mod and compiled a Debug DLL – albeit using my existing copies of the dependencies, and I don't have Steam. There's no need to attach the debugger manually, "Start Debugging" (F5) will do it if the a command line is configured on the Property Pages (screenshot attached). Though the error I encountered also gave me a failed-assertion popup, which doesn't require a debugger. Seems that the "extra assets" (as a comment in the makefile says) for _MOD_GWARM are missing, which is to say the XML code for the Rising Seas game option that this compiler flag enables. Disabling _MOD_GWARM fixed that problem. I think this resulted in an out-of-bounds access, which could randomly crash the game while loading the mod. Since you mention the screen going black just before the crash, I take that you play in fullscreen mode. That could interefere with error popups.

When launching a game, there's some problem with unit ID 35 having an unexpected unit class (another failed assertion). And lots of "cannot locate settings folder" messages, repeated upon window activation. Just seems to be missing a UserSettings folder in the mod's directory. I guess an empty folder might be a problem with Git. Usually default settings for unit names and the Domestic Advisor are put in that folder (example).

 

[Nightinggale]

Since you mention the screen going black just before the crash, I take that you play in fullscreen mode. That could interefere with error popups.

WTP has asserts always on top even in fullscreen. However I can't remember precisely how we did that. Must be some flag in FAssert.cpp, through we have modified that one multiple times.

And since the makefile is written in a alien language, I can't decipher what that means nor how to fix them.

Perfect description of nmake. I would highly recommend using GNU make instead, but so far I haven't been bothered enough to start writing a new makefile.

As for the errors, it tries to call targets I added in my makefile (see my signature), but they were apparently not present in the makefile you used. You need the calls in MSVS to match the requirements of the makefile, so you can't take the project from one makefile and use it with another makefile without ensuring those two makefiles are compatible.

 

[Basilmoyh]

Thanks. That'll play.

I did notice the missing User Settings, but since that didn't resolve the issue, I hadn't pushed them yet.

The failed unit? It's either the "UNIT_ETHIOPIAN_OROMO_WARRIOR" or "UNIT_GRENADIER" depending on whether the index starts at 0. I reordered units in the xml, it makes it easier to find select archers in the world editor which I commonly add archers when changing a maps difficulty. Both units seem to work without issue in game. /shrug

I might be able to get the debugger working. I couldn't work out how or if modern Visual Studio can compile/debug Civ4, so I have "Visual C++ 2010 Express". It's 'attach to process' didn't appear to allow me to choose what to attach it to. Those setting may help. I also can't build the a 'debug' version, the complier says it runs out of memory. But the makefile seems to have the option to to include a pbd file with the "release"

Anyway, it works now and it's pretty much set and forget. Making changes to the cpp, that's the easy part.

 

[f1rpo]

I also can't build the a 'debug' version, the complier says it runs out of memory.

That does sound like an obstacle. Maybe the "assert" build, then, for the time being. No debug symbols, but at least assertion checks and popups.

The failed unit? It's either the "UNIT_ETHIOPIAN_OROMO_WARRIOR" or "UNIT_GRENADIER" depending on whether the index starts at 0.

Just to tie this up: It starts at 0, but the Grenadier still kind of seems to be the problem. Civ4CivilizationInfos.xml says that the Oromo is a Grenadier, but Civ4UnitClassInfos.xml says it's a Rifleman. (Agree btw that these later units make more sense than Musketman.)

 

[Mr Smith]

Very interesting to read, everyone. Thanks for making me aware of Steamless, it provided me with an option I can offer to people whose connection is incompatible with Gamespy lobby and want to run complicated mods that Steam may ruin. It messes up Python components somehow, possibly more:

Spoiler :

View attachment 714204On third message below there's an EOF Error, if it matter.

Original History Rewritten DLL is somehow fine, yet one I recompiled in VS2010 (which relies on .NET 4.0 and not newer) also breaks when run through Steam library (or invites):

Spoiler :

View attachment 714205Failing at Line 1 should tell of something catastrophic, right?

Sorry for offtopic, but... any clues how to reconcile such mods with Steam? Or to access Direct IP if it's hidden and not actually cut from Steam version? Or to transplant newer NAT negotiation to Original Release? (would be nice if it's on some domain like civ4bts.natneg1/2/3.gamespy.com, but I couldn't find anything like that with a superficial sweep) RI fails on Windows 7, but not Windows 10. HR fails on both. It wouldn't matter if people could use Direct IP with Steam's NATNeg, but dissecting .exe is way over heads of everyone I know. I'll move somewhere else if I should.

Ok, I found exactly what Steam breaks (it's print every time) and cutting it out everywhere at least allows to launch the game and generate a map.

Spoiler here's an example of a one-piece exception: :

Yes, Steam launch also breaks other mods, if they try to print something. Any idea where "line 7 in write" might be? Oh, and the original DLL was broken too the whole time, guess I didn't test it in correct conditions back then. Flabbert says the problem is with Boost, an error about it follows right after the exception above, but nothing can be done about that. So is there anything that can be done that is not as crude as throwing out all the prints around? Commenting out debugMsg or all it's mentions didn't help.