DarkAnt said:
I would like to use this, but I don't know how. I've got a mod that crashes as soon as the first units are spawned, but I'm not sure about it. I could comment out code until I find the problem, but I think the debug.dll would give me some extra info to narrow it down. Unfortunately, I don't know how to use it. Could anyone point me in the right direction?
Thanks
If you can get the debug dll to compile and link, then you've probably got half of your problems for doing a debug build all set!
If not, there are plenty of different problems that are in that, but I'm assuming you've already gotten this step accomplished. I'm also assuming you're using Visual Studio, 'cuz I haven't heard of anyone even getting a debug build compiled using other methods.
First off, I wasn't able to get it working as CvGameCoreDLL_DEBUG.dll, I made it so that the debug built to the dll CvGameCoreDLL.dll, same as the norm. Of course, you can easily tell the difference in the end product (one was 3mb, the other 11)!
Next, you'll want to place it in the mod folder. You've probably gathered that part already.
Now, start the mod like normal. With your project open in Visual Studio, click in the menu bar "Debug->Processes". This will now give you a window showing some processes running on your computer. Find "Civilization 4" and then click attach. I'm kinda newb with using Visual Studio debugging myself, but I've found that Native works. I don't really know what these options are.
After selecting native, hit "Ok", then close.
At this point, if you're like me, you've probably run into 18,000 errors that don't allow you to attach to the process. I guess this is a good time to post them.
If you got lucky, you should now be "attached". At any time, you can pause the execution of the code hitting the "pause" button in the top left of the screen. The arrow will show you exactly where the code execution is. From there, you can step-through the code using the various step functions (located just to the right of the play/pause/stop buttons).
Breakpoints are fun. Left-click the grey bar (should be to the left of the line number) and you'll see a red "dot" appear. This is a breakpoint. At any point, if the code execution hits this line, it will pause execution and you can then take the time to look at different things.
When paused, you can look at the "Call stack", which is a window typically residing as a tab in the bottom. If you can't find it, look under the menu bar "Debug->Windows->Call Stack". This shows you what the call stack looks like.
The two other windows that will help you out are the Locals and Autos window. These are located by going to the menubar and selecting "Debug->Windows->Autos" or "Debug->Windows->Locals".
These windows show all the variables that are currently important. The local shows the variables that are in the local scope, while the autos mostly show variables that are temporary (such as what a function just returned).
Note that when your program hits a crash, it will probably give you that option to try to debug. If you're not in debug mode already, using the option to debug will allow you to enter debug mode at the line of code where the crash is happening, so long as the source code is loaded.
One last thing: if you try to set a breakpoint, and your breakpoint has a question mark on it, then your code doesn't match the DLL's compiled code. Chances are, you've recompiled the code and haven't restarted Civ with the new DLL that you just made.
But the hardest part is just getting the debug dll to actually compile and attach to Civ4. Once this is set, figuring out how to debug is just a matter of trying different things.
