RevolutionDCM for BTS

New Makefile based on the BULL one has been uploaded. Building Debug or Final_Release both work, however there's still the linking problem in the new BULL code in CvGame so the commented out section there has to remain commented out. Will try tracking down that problem tomorrow, I though the Makefile switch would fix it but apparently not.

Also, with the change to the Makefile I took the liberty of changing the project file as well. If you have a solution file set up for the mod, say RevolutionDCM.sln, you can open it up in a text editor and change it to point to RevolutionDCM.vcproj. That should be all you need to change to get compiling with the new Makefile.
 
The new makefile works. You have to do a full recompile though, I tried just deleting the .lib file, and it failed, had to rebuild it from scratch. Thanks for getting that out, a debug dll is an essential modding tool in my oppinion. Even if you're not messing with the SDK, it helps imensly even for simple XML mods.

Also I need to point out this bug:
http://forums.civfanatics.com/showpost.php?p=8514849&postcount=1884
Still exists in revision 174. Other then that I haven't found any issues, and none of the 6 people that have downloaded the current LoRtest build have reported any either. So 2.6 seems to be coming along quite nicely.
 
jdog5000 said:
New Makefile based on the BULL one has been uploaded. Building Debug or Final_Release both work, however there's still the linking problem in the new BULL code in CvGame so the commented out section there has to remain commented out. Will try tracking down that problem tomorrow, I though the Makefile switch would fix it but apparently not.

Also, with the change to the Makefile I took the liberty of changing the project file as well. If you have a solution file set up for the mod, say RevolutionDCM.sln, you can open it up in a text editor and change it to point to RevolutionDCM.vcproj. That should be all you need to change to get compiling with the new Makefile.
Click to expand...

Excellent work, you have my thanks.
 
phungus420 said:
The new makefile works. You have to do a full recompile though, I tried just deleting the .lib file, and it failed, had to rebuild it from scratch. Thanks for getting that out, a debug dll is an essential modding tool in my oppinion. Even if you're not messing with the SDK, it helps imensly even for simple XML mods.

Also I need to point out this bug:
http://forums.civfanatics.com/showpost.php?p=8514849&postcount=1884
Still exists in revision 174. Other then that I haven't found any issues, and none of the 6 people that have downloaded the current LoRtest build have reported any either. So 2.6 seems to be coming along quite nicely.
Click to expand...

Great.

We'll see if we can figure out what to do with that Python error, since minor civs aren't normal BUG doesn't always consider them.
 
Okay, I just download your revision 176 sources and merged them successfully, compiled a Final_release DLL fine, that works great, but I'm having strange issues with the debug dll. I can compile it okay with the new makefile, but I get some strange error messages when I try to start the game.
Here are what some of the dialogs are:
Spoiler :

error1.png

error2.png

error3.png


Hitting "ignore" brings me to each new dialog, in which, the final one, the game refuses to start.

I can start it fine with the new final release dll, but not the new debug. Is any other modder getting these types of errors?
 
Achilleszero, the guy who does the art for LoR, and thus the person that really needs the debug dll is reporting the new debug dll crashes to desktop as well. Final release works fine. So yeah, corroberating Afforess's report.
 
100 turns with a Debug DLL and still going, it's working just fine for me. I did just upload a little Makefile tweak, but it's rebuild dependency stuff not anything that would make or break the DLL.

You guys did notice the project file changed right? And you did a clean rebuild of the Debug DLL?

If you're scratching your heads you could try removing the Debug folder manually, or deleting the solution file and recreating the project following Refar's instructions. Not sure what else could be going on.
 
I rebuilt from scratch, had to or it wouldn't compile. I'll try deleting the whole project, and setting it up again from scratch.

I do have a question though, this:
Code: 
### Civ4 SDK Paths

BOOST = C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\Boost-1.32.0
PYTHON = C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\Python24

So you're now having it pull the Python and Boost folders from the BtS directory? Does this mean I need delete the Python and Boost folders from the main project folder, where all the other source is? Why did you change this? Could you put it back to how it was before, and defining the location of the Python and Boost folders wasn't necessary, as they were just used along with the rest of the SDK in the main project folder?
 
Since CvGameUtils.py has been eliminated in the last SVN release, what's the purpose of this code in CvCity.cpp?

Code: 
//	if(GC.getUSE_CANNOT_TRAIN_CALLBACK())
	// RevDCM TODO: would be better to remove the UNIT_INQUISITOR line ...
	if( eUnit == GC.getInfoTypeForString("UNIT_INQUISITOR", true) || GC.getUSE_CANNOT_TRAIN_CALLBACK() )
/*************************************************************************************************/
/** REVOLUTIONDCM_MOD                         END                                 Glider1        */
/*************************************************************************************************/
	{
		CyCity *pyCity = new CyCity((CvCity*)this);
		CyArgsList argsList2; // XXX
		argsList2.add(gDLL->getPythonIFace()->makePythonObject(pyCity));	// pass in city class
		argsList2.add(eUnit);
		argsList2.add(bContinue);
		argsList2.add(bTestVisible);
		argsList2.add(bIgnoreCost);
		argsList2.add(bIgnoreUpgrades);
		long lResult=0;
		gDLL->getPythonIFace()->callFunction(PYGameModule, "cannotTrain", argsList2.makeFunctionArgs(), &lResult);
		delete pyCity;	// python fxn must not hold on to this pointer 
		if (lResult == 1)
		{
			return false;
		}
	}
 
I tried removing the boost and python folders from the source code directory, and totally restarted the project from scratch. Everything compiled fine. The Final_Release gamecore also works, but the debug is definatly broken. It throws all sorts of errors on initializion, and python doesn't load up, so you get an opening screen you can't do anything in. Also Revision 183 broke stuff, using a new compiled final release gamecore all units except the settler had an assisnate option (even though I have this turned off) and clicking on it caused a crash. I double checked all the files with winmerge and the only stuff that's different are the files that need to be, like unitinfos, or some python files that deal with displaying the Legends Units in the Civilopedia, also checked the specific code in all the python files that were different, and everything checked out. So revision 183 is not working correctly, and still can't build a function debug gamecore.
 
jdog5000 said:
100 turns with a Debug DLL and still going, it's working just fine for me. I did just upload a little Makefile tweak, but it's rebuild dependency stuff not anything that would make or break the DLL.

You guys did notice the project file changed right? And you did a clean rebuild of the Debug DLL?

If you're scratching your heads you could try removing the Debug folder manually, or deleting the solution file and recreating the project following Refar's instructions. Not sure what else could be going on.
Click to expand...

I did a full rebuild (three separate times). I tested it on Revision 176, my own sources, and my sources merged with 176. All had exactly the same issue, so I'm blaming the makefile. Also, I was slightly annoyed that I had to change all the /program files/ references to /program files (x86)/. The last makefile, at least I thought, had both places listed...
 
phungus420 said:
I rebuilt from scratch, had to or it wouldn't compile. I'll try deleting the whole project, and setting it up again from scratch.

I do have a question though, this:
Code: 
### Civ4 SDK Paths

BOOST = C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\Boost-1.32.0
PYTHON = C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\CvGameCoreDLL\Python24

So you're now having it pull the Python and Boost folders from the BtS directory? Does this mean I need delete the Python and Boost folders from the main project folder, where all the other source is? Why did you change this? Could you put it back to how it was before, and defining the location of the Python and Boost folders wasn't necessary, as they were just used along with the rest of the SDK in the main project folder?
Click to expand...

This is a cool new feature of the BULL Makefile, you no longer need to copy over the Python and Boost folders for each project. They never change, so instead this Makefile just uses the ones in the main BtS folder.

phungus420 said:
Since CvGameUtils.py has been eliminated in the last SVN release, what's the purpose of this code in CvCity.cpp?

Code: 
//	if(GC.getUSE_CANNOT_TRAIN_CALLBACK())
	// RevDCM TODO: would be better to remove the UNIT_INQUISITOR line ...
	if( eUnit == GC.getInfoTypeForString("UNIT_INQUISITOR", true) || GC.getUSE_CANNOT_TRAIN_CALLBACK() )
/*************************************************************************************************/
/** REVOLUTIONDCM_MOD                         END                                 Glider1        */
/*************************************************************************************************/
	{
		CyCity *pyCity = new CyCity((CvCity*)this);
		CyArgsList argsList2; // XXX
		argsList2.add(gDLL->getPythonIFace()->makePythonObject(pyCity));	// pass in city class
		argsList2.add(eUnit);
		argsList2.add(bContinue);
		argsList2.add(bTestVisible);
		argsList2.add(bIgnoreCost);
		argsList2.add(bIgnoreUpgrades);
		long lResult=0;
		gDLL->getPythonIFace()->callFunction(PYGameModule, "cannotTrain", argsList2.makeFunctionArgs(), &lResult);
		delete pyCity;	// python fxn must not hold on to this pointer 
		if (lResult == 1)
		{
			return false;
		}
	}
Click to expand...

I put that code in to speed up the mod under the old Inquisition system. Glider changed the way the inquisition system works just in the last couple days, so we'll see if it's still needed or not shortly.

Afforess said:
I did a full rebuild (three separate times). I tested it on Revision 176, my own sources, and my sources merged with 176. All had exactly the same issue, so I'm blaming the makefile. Also, I was slightly annoyed that I had to change all the /program files/ references to /program files (x86)/. The last makefile, at least I thought, had both places listed...
Click to expand...

You will always have to customize a Makefile to your own setup. I made this one, so the paths are for my computer (XP). glider made the last one, so the paths were for his.
 
jdog5000 said:
You will always have to customize a Makefile to your own setup. I made this one, so the paths are for my computer (XP). glider made the last one, so the paths were for his.
Click to expand...

That's okay, I said I was just "slightly annoyed."

Any progress on the debug CvGameCore, or are Phungus and I just crazy?
 
Glider changed the way the inquisition system works just in the last couple days, so we'll see if it's still needed or not shortly.
Click to expand...

Yeah I guess python callbacks are expensive. The inquisitions rebuild was forced because of BUG 4.0, but BUG's system of handling events and callbacks is very elegant and the mechanism should be used. Unfortunately, the new inquisitions still uses the same callback system, but via the BUG callback handlers which could include more overhead not less? Only a guess. The presumed wast of time that is occurring is consumed in the process of c++ hooking into python every umpteenth milliseconds, and not actually in the python execution stage of the callback?

Cheers.
 
Where is the cannottrain code for the inquisitor handled now then?
 
I know you guys said you were shooting for today for the release of 2.6. However in testing RevDCM SVN revision 187 I have found the following bugs that really must be fixed first.

  • Python exceptions at game start up when "Start as Minors" selected, see here for more details:
    http://forums.civfanatics.com/showpost.php?p=8514849&postcount=1884
  • Rising Seas game option is missing it's text entry, so it says GAME_OPTION_TEXT_RISING_SEAS when starting a custom game
  • Inquisitors can be built under all civics, including pasifism
  • All units except settlers have an "assassinate" option; selecting this option causes a CTD. This occurs with SS on and assassination off, haven't checked other options.
  • Modmakers cannot use Refar's guide to build a debug dll, and thus can't make debug dlls. It is imperative for modmakers to have this ability, it takes about 10 times as much work to build a large mod without the ability to build one.
 
Some bugs i found with the SVN 187 build:

- The Options under the Domestic Advisors section in the BUG Mod Options window are missing.
- I couldn't seem to get the "Go to and Sentry" feature to work. When I order a unit to "Go to and Sentry," it dose not move. Regular "go to" works however.
-The "Naval Sentry" option appears for land units and not naval units
- The "Sentry Until Healed" appears for sea units and not land units
 
Thanks for the reports guys. Glider is working hard at getting all the release bits merged together and ironing out the remaining issues. Many thanks to him for all of that work!

We won't release without a functioning Debug build process ... the current one works fine for me, glider's going to try it out next. If there isn't an easy solution we will drop the new BULL feature which is causing this whole issue, at least in the short term (this feature is required for the BUG Map Finder feature, I'm not sure what that does actually).
 
jdog5000

I found your little era limit tool and it works great with RevDCM 2.5 but I can't seem to get it to work with the new build.
Is it possible for you to include this feature in the new version or put it on the wishlist for the next?
If there was some frontend for this that would be great too, such as being able to set the Max Era when starting a custom game/scenario.

Era Limit
 
You must log in or register to reply here.

Similar threads

H
Custom music folder troubleshooting
Replies
1
Views
572
<Nexus>
<Nexus>
MantaRevan
Can't seem to find CIV4TraitInfos.xml for trait editing
Replies
7
Views
631
<Nexus>
<Nexus>
D
How to run a mod running under ProtonGE
Replies
1
Views
326
a pen-dragon
A
gavenkoa
BULL hover popup text "Speeds Up ..." on F6 is not shown
Replies
5
Views
404
f1rpo
f1rpo
S
All game crashing for a unknown reason
Replies
15
Views
773
burticus
B
Back
Top Bottom