Wierd Bug, when changing Mountains Back to Service Modcomp

[Afforess]

I changed the Mountains: Back to Service Modcomp into a game option that players choose when starting a custom game, but I have a really strange bug now that I added that. No units or buildings require resources anymore to build. Axemen don't require copper, ICBM's don't need uranium. All I did was change the code to make the Mountain mod a gameoption though, so I'm not really sure what's wrong. Could someone compare the two sources and tell me what I screwed up?

Standard Mountains Back to Service Modcomp:
View attachment 226812

Mountains Back to Service new gameoption:
View attachment 226811

 

[davidlallen]

Scrummaging through two sets of files to look for random changes will take some work. Do you want to give a hint, such as which files you changed, or what is the text of the comment you inserted?

But first, did you do a clean rebuild after making your changes? If you changed some .h files, you must recompile *all* the .cpp files. Usually if you fail to do this, you will get a crash, rather than some simple change in behavior. But this is little effort to try.

 

[Afforess]

Scrummaging through two sets of files to look for random changes will take some work. Do you want to give a hint, such as which files you changed, or what is the text of the comment you inserted?

But first, did you do a clean rebuild after making your changes? If you changed some .h files, you must recompile *all* the .cpp files. Usually if you fail to do this, you will get a crash, rather than some simple change in behavior. But this is little effort to try.

I only included the three files I changed, CvPlots.cpp, Enums.h, and Enuminterface.cpp.

All my changes are commented with "Afforess"

Using winmerge to compare the folders will make the few differences very obvious.

And yes, I know to rebuild everytime I build a new version. I'm not an SDK noob (anymore.)

 

[davidlallen]

Just checking. BTW, the rule I use is, if I change any header files, I do a full rebuild. If I have only changed cpp files, I trust the Makefile to know which cpp files and recompile those. But the Makefile is not smart enough to recompile everything when the header files change.

 

[Afforess]

Just checking. BTW, the rule I use is, if I change any header files, I do a full rebuild. If I have only changed cpp files, I trust the Makefile to know which cpp files and recompile those. But the Makefile is not smart enough to recompile everything when the header files change.

I use codeblocks, which forces a rebuild if you change a header file, but not a cpp. So that's a non-issue.

 

[Afforess]

So could someone with C++ knowledge please take a quick look at the two sets of 3 files and tell me what I changed that is wrong?

 

[xienwolf]

All the code commented out for the Vicinity Bonus was code added by it then? Disabled it while bug testing and whatnot? I presume as much for the time being.

I honestly see nothing in here even remotely capable of causing such an error. I don't know of any way you could do anything at all in CvPlot to affect the bonus requirements of units. My advice would be to comment out everything related to this modcomp in CvPlot, compile and see if the error goes away. If it does, we have a code miracle. The next step would be to uncomment each change individually and see when the bug comes back, then re-comment everything previously uncommented to verify that change is the only one causing the issue. Each piece of code is independent of the other, so if this is causing the issue it should be that just one of them does it.