RevDCM Specific Code Proposals

Just checked the latest SVN source, and none of this was included :(

It wouldn't take any time to add Barbarian World to RevDCM with how it's laid out here. And the rev trait effects would be awesome to have as well. I can see why you wouldn't include the unit upgrade code or the nonstatereligioncommerce code, since it's not helpful to RevDCM itself, only for other moders (but it wouldn't hurt anything). The rest of the code (exposing Revolution civic effects to the civilopedia, adding Barbarian World, and adding Revolution modifiers to trait infos) would be very handy to have. Bumping this in the hopes the code gets added.

Now that I'm much more experienced with the SDK, and looked this code over, I must agree with Phungus here. This code should be included in 2.6. It adds a lot of modibility to the game.
 
I've just added all this to the latest SVN. Here is the latest SVN updated with these code suggestions. It's as simple as using winmerge at this point. With one exception, the iPrice code in CvUnit.cpp includes a double price for upgrading to a different unitcombat type cost function from LoR, you will need to remove, but that's pretty trivial. All files included, all the text is in it's own XML text file, it's pretty small, I assume you'd merge this in with other RevDCM text files.
 
Woops I forgot the functionality code portions for RevTraits. Here is the Revolution.py file, taken from the latest RevDCM SVN version with RevTraits added in. It should have been included in the attachment above, but I missed it.
 
It's not really a code proposal; rather it is something I'm wondering about since a long time and I figured it could fit in this thread.

Why is Revolutions written part in the DLL, part in python? Out of my knowledge of python, I can't think of a real advantage of doing it in it rather than in the DLL. Maybe I'm missing some advantage of python (easier to modify?)...

I'm interested in using Revolutions in a mod (doing the merge and all myself) but I'm not really fond of using python; especially since I'm really a stranger to all that INI settings things and all the new python files. I come from FFH and we don't have that kind of functionality there. So I'm a bit lost with it; I guess I could learn but I don't see a real advantage to it and I would prefer to do everything in the DLL.

By the way, I checked how BarbarianCiv works and it seems to me that it could really be ALL done in the DLL. That's actually how I came to wonder why Revolutions is a hybrid Py/DLL mod.
 
The short answer is because it started in Python because Python is simply easier ... you don't have to close the game, recompile, and start the game up to test a change. Python is reloaded if you modify it while the game is running, so that's one nice feature.

Python is also easier for other players to modify and include in mods. Once you know how to merge C++ code and recompile a DLL, you can certainly do more, but there are far more people comfortable with Python merging and tweaking than SDK merging I believe.

That said, if I was to start from scratch at this point, I'd do a lot more inside the DLL ... there's more power there, and once you know your way around it's easier to figure out what functions do what.
 
Thanks for the answer!

That was what I thought. Python has its advantages (especially the auto-reloading during a game) but the SDK has the advantage of allowing easy transparency and is better for the game perfomance-wise.

Anyway, thanks and keep up the good work :)
 
Another code proposal.

This code removes the free techs granted to the AI when start as minors is selected. I have only heard complaints about how high level play is impossible with start as minors because the AI archer rushes you, yet if you make it past the begining it's too easy because you can't set an apropriate difficulty level. I've heard this mulitple times, and experience it myself. It's rather annoying for high level players because if your preffered difficulty is Immortal, you can't play it with start as minors on, in fact Emperor and monarch usually take a few starts to survive, but then if you survive into the mid classical age, the game is ended because you start to blow the AI away. If you disagree with this sentiment (as I'm sure some do), make sure you play on Emperor+ before voicing such oppinions, a Noble player's experience just isn't aplicable, because I haven't seen yet an Emperor+ player that thinks the current start as minors + early archer rush mechanic feels right, (granted it can be fun at Monarch, but the production bonuses are much lower for a monarch AI, the free archery tech doesn't lead to the same insane archer rushes you get on Emp+).

Anyway here is the code in CvGame:
Code:
				//phungus remove free techs from AI's when starting as minors
					if (isOption(GAMEOPTION_START_AS_MINORS))
					{
						if ((GC.getHandicapInfo(getHandicapType()).isFreeTechs(iI)) ||
						  (GC.getTechInfo((TechTypes)iI).getEra() < getStartEra()))
						{
							bValid = true;
						}
					}
					else
					{
						if ((GC.getHandicapInfo(getHandicapType()).isFreeTechs(iI)) ||
						  (!(GET_TEAM((TeamTypes)iJ).isHuman()) && GC.getHandicapInfo(getHandicapType()).isAIFreeTechs(iI)) ||
						  (GC.getTechInfo((TechTypes)iI).getEra() < getStartEra()))
						{
						bValid = true;
						}
					}				
				//phungus end
The else function is the original code.
 
Hmmm ... this would certainly delay the early archer rush on higher levels a bit and makes some sense. However, won't this exacerbate the other problem you're reporting where a human player who survives the start up phase can blow the AIs away with start as minors on?

Another way to go would be to give the human player archery to start at higher levels with start as minors on, or to give the human player some extra defense units at the start of the game (like half what the AI gets or something).
 
Finally got the code working that I posted in this thread:
http://forums.civfanatics.com/showthread.php?t=341191

So the inquisitor is now softcoded. I did not change all the RevDCM python isInquisitionEnabled checks to a game.isGameoption(GAMEOPTION_INQUISITIONS) check, but it should be done before it's shipped out, and the RevDCM inquisitions tab and toggling removed. This was done because in order to softcode the inquisitor and eliminate the hardcoded reference in the dll and the canTrain python callbacks, I had to create a gameoption tag to fill this role. I have playtested around 1000 turns in AI autoplay with this code, and no issues were found. There was an issue with World Builder as reported in the linked thread above, but that was an issue with CvGameTextMgr.cpp, now I have no idea why World Builder breaks if you set it to do a check for a unit while in a city for the presence of the state religion, but it does, so I changed the bStateReligion check in CvGameTextManager and it works and displays correctly now.

In addition to removing the hardcoding and canTrain callbacks with the inquisitor, the following following changes have been made:

Added Tags UnitInfos
  • bStateReligion -Adds a has state religion check to CvPlot::canTrain (being in CvPlot seems wierd, but this is where the other similar religious and resource checks for canTrain are made)
  • PrereqGameOption -Adds a gameoption check to CvPlayer::canTrain, if defined as something other then NONE, this gameoption will be required in order to train the unit
  • NotGameOption -Adds a gameoption check to CvPlayer::canTrain, if defined the unit can not be built if the specified gameoption is selected in a game
  • PrereqOrCivics boolean array -Adds an Or Array for Civics Or Requirements to CvPlayer::canTrain, if filled the player must be using one of the specified civics in order to train the unit

Added Tags BuildingInfos
  • PrereqGameOption -Adds a gameoption check to CvPlayer::canConstruct, if defined as something other then NONE, this gameoption will be required in order to build the building
  • NotGameOption -Adds a gameoption check to CvPlayer::canConstruct, if defined the building can not be built if the specified gameoption is selected in a game
  • iUnitUpgradePriceModifier -Adds an integer tag to modify the cost to upgrade units, this is handled through CvPlayer.cpp and CvUnit.cpp and is applied to the team, so is designed for World Wonders, such as Leonardo's Workshop

Added Tag TraitInfos
  • bUpgradeAnywhere -Adds trait effect where if enabled the player may upgrade units outside of their territory


All code has been tripple checked and these files may be just copied over the current RevDCM source on the SVN. The XML and python as well is from the current RevDCMSVN and can be just copied over or just winmerged in. jdog and glider if you checked the earlier version in the linked thread that was specified as not being ready, please use this instead. There were three problems in the original code that made the code not as seemlessly mergeable, first the issue with WB breaking from the aforementioned bStateReligion check in CvGameTextMgr.cpp, secondly I forgot to remove the original GameOptionInfos loading line in CvXMLLoadUtilitiesSet.cpp so if the prior version is used this file will be spefied to load twice, and thirdly the prior code did not have the Civilopedia display code for the Civic Units requisite in SevoPediaUnit.py.

Edit:
Code updated and attached 3 posts down.
 
Awesome work Phungus! I'm stealin...er Using now.

Jdog, I fully support this code, it should ALL be in RevDCM.
 
I forgot when I moved the bStateReligion canTrain check to CvPlot to CvCity that I still needed to include CvCity due to the hardcode reference to Unit_Inquisitor in there. Here is CvCity which you will also want to include in the sources:
 
Updated the code. Added a bStateReligion canTrain check to CvPlayer, and also improved the check in CvPlot. Also completely moved all RevDCM InquistionsEnabled calls over to the new GAMEOPTION_IQUISITIONS. Checked this and it works, the AI still builds and uses inquisitors and the player can also. Was just a simple but mildly tedious procedure of changing all the REVdcm.isINQUISTIONS_ENABLED calls to gc.getGame().isOption(GameOptionTypes.GAMEOPTION_INQUISITIONS) calls. Also I added some if logic to the RevDCM tab so that the Inquisitions options only display if Inquisitions are enabled, and Super Spies options do not display if No Espionage is selected.

Everything is good to go in the code. I can't break it at least, and it's built off the current 259 RevDCM svn, both source and assets files. No outstanding issues that I am aware of, that's why I finished it up by cutting the isIQUISITIONS_ENABLED calls and shifting everything over to the SDK or XML, with no hardcoding in the SDK. Figured it would be good to tie up all the loose ends instead of leaving that outstanding.
 
Problem: in RevDCM, project prerequisites are hardcoded. Many thanks to phungus420 for pointing out the offending code in CvInfos.cpp:
Code:
int CvProjectInfo::getProjectsNeeded(int i) const
{
	FAssertMsg(i < GC.getNumProjectInfos(), "Index out of bounds");
	FAssertMsg(i > -1, "Index out of bounds");
	// RevolutionDCM interim patch to Apollo Program bug
	// CvProjectInfo::readPass2() does not fill the m_piProjectsNeeded array.
	// Problem manifests as the info screen displaying a completed apollo project at the start of the game.
	if (i == 2 && m_bSpaceship) return 1; else return 0;
	// original BTS code
	// return m_piProjectsNeeded ? m_piProjectsNeeded[i] : false; 
}
This is awful; it hardcodes a dependency on the spaceship project based on the *position* in the projects file.

Solution: A project prereq is a project. Handle this correctly in CvProjectInfo readpass2. Many thanks to xienwolf for pointing out several changes which are required.

1. Put back CvProjectInfo::getProjectsNeeded to what seems obviously correct:
Code:
int CvProjectInfo::getProjectsNeeded(int i) const
{
	FAssertMsg(i < GC.getNumProjectInfos(), "Index out of bounds");
	FAssertMsg(i > -1, "Index out of bounds");
	return m_piProjectsNeeded ? m_piProjectsNeeded[i] : false; 
}
2. In CvProjectInfo::copyNonDefaults, add:
Code:
	if ( m_piProjectsNeeded == NULL)
	{
		m_piProjectsNeeded = new int[GC.getNumProjectInfos()];
		for ( int i = 0; i < GC.getNumProjectInfos(); i++)
			m_piProjectsNeeded[i] = 0;
	}
	for ( int i = 0; i < GC.getNumProjectInfos(); i++)
	{
		if(getProjectsNeeded(i) == 0)
			m_piProjectsNeeded[i] = pClassInfo->getProjectsNeeded(i);
	}
This function is not passed a pXML pointer, so we cannot use pXML->Init as you might expect. You may prefer to change the caller in order to avoid a raw "new", or you may not care.

3. In CvProjectInfo::copyNonDefaultsReadPass2, add:
Code:
	if(m_piProjectsNeeded == NULL)
	{
		m_piProjectsNeeded = new int[GC.getNumProjectInfos()];
		for ( int i = 0; i < GC.getNumProjectInfos(); i++)
			m_piProjectsNeeded[i] = 0;
	}
	for ( int i = 0; i < GC.getNumProjectInfos(); i++)
	{
		if (pClassInfo->getProjectsNeeded(i) != 0)
			m_piProjectsNeeded[i] = pClassInfo->getProjectsNeeded(i);
	}
See this thread for the original discussion.
 
Added Tag TraitInfos
  • bUpgradeAnywhere -Adds trait effect where if enabled the player may upgrade units outside of their territory
Having this modifier as a civic option would be cool too. Isn't today's USA like this, they have troops all around the world and they do upgrade them anywhere (granted they have bases in many countries where they can train troops to use the new equipment).
 
Back
Top Bottom