All this writing about the dll makes me wonder if the problem is in python or the dll. It is triggered by a python change, but python calls the dll. Also it would be possible to analyze the dll at runtime to tell which functions python calls and that way get an indication of what python is doing. For all we know the dll could act up due to being called with an invalid argument and the dll ends up in an undefined state. Not looking into the dll might be a mistake, particularly since it seems that we don't really have tools to analyze what python is doing at runtime.
the game said something about indents, but as far as I could see there was nothing wrong.
Try to set Notepad++ to show whitespace. It might be due to replacing space with tabs or vice versa.
A debug dll is a CvGameCoreDLL.dll file about three times the size of a normal one. It is the same source code files compiled in one dll in a different way.
Strictly speaking, it is compiled in the same way, except the debug dll skips the last step (optimization) and instead it has extra data to tell which line in the source belongs to which instruction in the compiled dll. Other than that they should be identical.
That's Nightinggale's job!
I had a job interview? and I passed? I remember nothing of that. I must be getting
You can also just replace your dll with the debug dll. Your game will run slower but then you can get important messages/hints (asserts) about potential problems.
Makefile 2 can make a hybrid called assert. It is an optimized dll with asserts enabled. It is slower as it has to perform the assert checks, but it's almost as fast as release dlls (regular dlls). The intended goal for this is to always use this type when playing your own mod, which helps to catch bugs. It will require a proper debug dll if you want to attach the debugger, but most failed asserts can he dealt with without the debugger.
Even xml only modders benefits from using an assert dll. For instance if you give a free promotion PROMOTION_RANGGER, it will trigger an assert due to being an unknown string while a release dll will just silently fail and change it to NO_PROMOTION. The vanilla assert text for this error is rather poor and is aimed at people who debug right away. However it's still better than silently fail and a worst case scenario is for people to show up here and ask for help due to an unreadable assert. Perhaps a bit annoying, but still better than what the release dll would do.
It's not really helpful in the case of an infinite loop, but we can't rule out yet that you don't have other problems than that.
That depends on the code. It is possible that an infinite loop will trigger an assert. I
think it is vanilla code, which has a loop to decide what an AI unit should do. It's intended to run 1-3 times and it asserts when it has tried 100 times and still haven't decided. Other than that, as I mentioned before the failproof dll infinite loop detection is to profile (also with makefile 2). Being told how much time it spend on each line reveals which loop which eats up 100% of the time. It's impossible to miss.
If you can find a debug dll that can run your game, it would be easier. Otherwise, we have to compile one from the source files you provided.
I have bad experience with using debug dll files provided by other people. It's like there are hardcoded paths or something in them. However they always just work when I compile myself.
The solution to this problem, which works best in my experience is to place the mod in git. Other people can then pull all the files and if set up correctly, everybody can compile out of the box and run their own tests. It makes fixing a problem like this one easier and faster and it doesn't involve as much guesswork. Git also helps in case you end up with "this feature is broken. It worked last weekend. How did I break it?" as it logs all changes down to each line change.
I usually end up with projects in the compiler that have all the same name CvGameCoreDLL and don't know how to differentiate them easily (I can't rename them).
I don't see the problem in having the same name for all project files except it might be a bit confusing if you have multiple projects open at the same time. Luckily it is quite easy to rename a project.
Close the project. You really don't want to keep the files in memory while doing this. Also backup in case something goes wrong.
The project files are partly autogenerated, which mean the only files you need for distribution (and hence renaming) are:
CvGameCoreDLL.sln
CvGameCoreDLL.vcxproj
CvGameCoreDLL.vcxproj.filters
Filters is poorly named as it is really the folder structure for the source file. If you don't use it and have all files in one "folder", the file will not be present.
Last open the .sln file. It will have the following line near the top:
Project("{some number}") = "CvGameCoreDLL", "CvGameCoreDLL.vcxproj", "{another number}"
The numbers appear to be random or hashes of something. I never touched those. The first string is what the project is called internally while the next is the name of the vcxproj file. Rename both to what you want. Save and the new name should be there.
I'm using msvc 2010, but it should be the same in 2008, though I remember something about vcproj file extensions as it was 2010, which added the x.