RevolutionDCM for BTS

I am toying with the idea of trying to merge RevDCM 3.0 back into Legends of Revolutions. As my modding skills are limited this would be a big project for me but I think it is feasible once the bugs you are working on are sorted out.

Good luck with the bug hunts.

 

This may not be the right place to ask, but I have a minor question: I am making a scenario for Revolutions DCM, and have found that once the game gets through the list of unused civilizations, all rebellions it forms are either disorganized or rebirths of dead nations. I would like it to be able to continue creating new nations (aka nations that are already being used, but with a different color/leaderhead, like what you get if you set a scenario to have two Frances). Is there any way to do this? (otherwise, I quickly run out of new rebellions, most of which occur in the old world, meaning that modern revolutions are sadly ineffectual)

 

Never mind, I have solved my problem

 

How are you doing regarding RevDCM 3.0?

I had another bug for you if you are not busy:

With bUpgradeAnywhere, there is a situation in which you cannot upgrade anywhere.

You can always upgrade in your own territory, unclaimed and rival territory, but there is a situation in which you cannot upgrade in your own territory - in cities not connected to your capital. I'd consider this a bug because it means you have to get out of your city into rival territory in a war for example, and then you can upgrade in the rival territory but not in your own unconnected city.

 

Hi Ferocca thanks for posting the bugs. I hit a snag merging K-Mod with Revolutions because there are random CTD's with revolution events and it is frustrating to fix until the work is put in. However I did improve range bombard logic and all of my work to date is in the sourceforge repository for this project. When I get frustrated with BNW and want a change I'll get back to this project. Frustration usually drives me to change from project to project. I guess we are all trying to enjoy our leisure time with minimal frustration eh.

 

Haha, that's totally true, we do. Good luck with all the frustrating projects then, I can be patient.

 

The build that is in source forge is so close yet so far to RevDCM 3.00 K-Mod was showing real promise and it autoplayed perfectly. The problems started when I hand played through revolution specific scenarios (like typical leadership change type events) to see the CTD's start to crop up. I have also posted about this in the Evolution forums but they too have been quiet.

Suggest that if you want to help speed this along, you could try Evolutions latest beta and play it with a focus on Revolutions events and whether you get CTD's happening in it. If they are absent from Evolution, I then have a comparison base to compare why it is not happening there but is happening in RevDCM 3.00 beta.

Random CTD's are the worst and are a challenge.

 

First, I'm *thrilled* to hear you're still working on this, I had feared it would be abandoned when V came out.

I'm trying to get NextWar runnign with it via the module you posted in the evolution thread, but nothing seems to be happening. Is this something I'm doing, does 2.92 not support that, or is that module not compatible?

 

Hi Requia - you need the next war module compatible with RevDCM 2.90. I'm not at my computer for the next couple of days. Bump me in 2-3 days on this forum if I forget to upload it to you. Your other option is to play Diversica which includes Nextwar and is very similar to RevDCM considering it was built off it.
Cheers

 

I know someone was complaining earlier about inquisitor purge religion not working properly and i think I was able to reproduce this error.

In LOR if you transfer into Organized Religion or Theocracy without running a state religion it will not unlock purge religion even if you change to a state religion later.

If you change to a state religion first and then change civics into Organized Religion or Theocracy it seems to work fine.

 

That's exactly the bug I've reported here earlier, but I had no idea how to produce this bug and that's why other people claimed they had no problem with inquisitors, because most people do first convert to a religion (I usually wait with that till I need the happiness bonus and such). Thanks for discovering the reason of the bug!

Glider, would you know if it's hard to fix this bug? If you tell me where in the SDK/python this is determined, I can give a try at fixing it.

 

Hi Ferocca and Chronis
The two areas of the code you would be interested in are:
CvPlayer::setInquisitionConditions() and CIV4CivicInfos.xml

I think I can see the line in the code you would be interested in is:

Code:

CvPlayer::setInquisitionConditions()
.
.
.
	if (getStateReligion() == NO_RELIGION)
		return;
.
.
.

So the code insists that you run a state religion first otherwise it will just dump out of that function and not process any further.

EDIT: I get your point that it is bugged but have not looked into it.

Cheers

 

Thanks for that, it should be easy now. Well, not so easy that this code worked, this was my first try, maybe it'll inspire someone to correct it to a non-bugged code:

Code:

void CvPlayer::setInquisitionConditions()
{
	m_bInquisitionConditions = false;

	if (GC.getGameINLINE().isOption(GAMEOPTION_NO_INQUISITIONS))
		return;
		
	for (int iI = 0; iI < GC.getNumCivicOptionInfos(); iI++)
	{
		if (GC.getCivicInfo(getCivics((CivicOptionTypes)iI)).isDisallowInquisitions())
		{
			return;
		}
		else if (GC.getCivicInfo(getCivics((CivicOptionTypes)iI)).isAllowInquisitions())
		{
			if (getStateReligion() != NO_RELIGION)
			{
				m_bInquisitionConditions = true;
			}
		}
	}
}

What I did didn't give any new bugs, it just didn't change anything.

EDIT: This didn't work either:

Code:

for (int iI = 0; iI < GC.getNumCivicOptionInfos(); iI++)
	{
		if (GC.getCivicInfo(getCivics((CivicOptionTypes)iI)).isDisallowInquisitions())
		{
			return;
		}
		else if (GC.getCivicInfo(getCivics((CivicOptionTypes)iI)).isAllowInquisitions() && (getStateReligion() != NO_RELIGION))
		{
			m_bInquisitionConditions = true;
		}
	}

 

The solution is to omit any reference to state religion in CvPlayer::setInquisitionConditions(). I feel a bit stupid now but at least I solved it. The state religion condition is already defined by CvCity::isInquisitionConditions().
So this is the new code that fixes the bug:

Code:

void CvPlayer::setInquisitionConditions()
{
	m_bInquisitionConditions = false;

	if (GC.getGameINLINE().isOption(GAMEOPTION_NO_INQUISITIONS))
		return;
		
	for (int iI = 0; iI < GC.getNumCivicOptionInfos(); iI++)
	{
		if (GC.getCivicInfo(getCivics((CivicOptionTypes)iI)).isDisallowInquisitions())
		{
			return;
		}
		else if (GC.getCivicInfo(getCivics((CivicOptionTypes)iI)).isAllowInquisitions())
		{
			m_bInquisitionConditions = true;
		}
	}
}

Oh, do not forget to disallow inquisitions for Paganism in the Civ4CivicsInfo.xml!
In RevDCM 2.90 inquisitions are not allowed or disallowed for Paganism at all; I had it disallowed for Paganism for a longer time already and it wouldn't surprise if Paganism could cause problems with inquisitors with this new code if you don't disallow Inquisitions for Paganism

It feels good that I can contribute to this!

 

Bump? sadly, Diversica refuses to work at all for me :/

 

Hi Requia
Here is Nextwar for RevDCM 290. Just put all the files in the assets/modules folder. Make sure you are running a clean copy of RevDCM 2.90 and then double click the woc_installer.jar which will install the nextwar audio (but not necessary if you don't want the sounds).

Hi Ferocca
At least you on the track and it is good to have someone else working on the project. I think now that the K-Mod merge with RevDCM is on hold, when I get holidays I'll release RevDCM2.91 which will fix and tidy up outstanding issues in 2.90.

 

That's a good idea if you ask me!
The bUpgradeAnywhere bug I tried to fix too, but it's too complex for me. The code obviously allows one to upgrade on plots that are not yours and it allows you to upgrade units that cannot move anymore that turn (I never knew till I looked at the code). However, sometimes you can't upgrade units because the units get 'connected' to a city of yours (it looks for the so called 'best city' when upgrading) and if that city is not connected to the capital/is not connected to the resource(s) you need, you cannot upgrade there (so you cannot upgrade anywhere).

I'm also still looking at the other bug I reported; the one that when the computer liberates a city to you due to revolutionary reasons (and only for revolutionary reasons this bug occurs) and you click the button that you do want to keep the city, nothing happens. I didn't really find anything yet for this bug though.

 

How evolution handles with it?

 

I am a bit closer to fixing the last bug I know of in the last RevDCM.

Traceback (most recent call last):

File "CvEventInterface", line 34, in applyEvent

File "CvEventManager", line 207, in applyEvent

File "Revolution", line 6035, in joinHumanHandler

KeyError: 'iJoinPlayer'
ERR: Python function applyEvent failed, module CvEventInterface

Line 6035 is the following line:
joinPlayer = gc.getPlayer( revData.dict['iJoinPlayer'] )

I checked RevData.py and iJoinPlayer/JoinPlayer indeed wasn't mentioned. To be honest, I have no idea how these Revolution-related python files work together, that's why I ask for help here, but this is the cause of the error, at least I found that

 

Hi Ferocca
No wonder you are confused it is not really object oriented coding. What the code in Revolution.py is trying to do is keep data packaged together in what is effectively a look up table or "dictionary" where it can find data based on a key.

When you see specialDataDict = {} that is a way of combining multiple relevant data into one neat package that can be dynamically created and accessed.

So for example on line 2845 of Revolution.py we see:
specialDataDict = {'iRevPlayer' : pRevPlayer.getID(), 'bIsJoinWar' : bIsJoinWar }
which combines up the id of the player and the boolean variable into one dictionary. So later in the code you could look up the dictionary to find out the bIsJoinWar status of that player.

The specialDataDict then usually get's sent to and stored in revData = RevDefs.RevoltData() which is the total data collection for all revolutions data.

You don't need to understand too much about dictionaries and the revData mechanics other than to think of it as a dictionary. There is a key which is a reference to the data you want and is works very much like a dictionary with a word, then it's meaning.

So the fact that iJoinPlayer is not in RevData.py just means that the key 'iJoinPlayer' was not entered into the revData dictionary during code execution and now when trying to look it up, the code cannot find it. So it wasn't initialised.

This is typical problem of this code style. The line 6035 is within an event handler (joinHumanHandler) which could fire at any time, but when it does, it needs the rev data dictionary to have the relevant data it needs already in it.

But there is a key error 'iJoinPlayer' which means that the key and it's accompanying data was not put into the dictionary revData prior to the event.

What we need to do is work out what fires joinHumanHandler() and then work out why 'iJoinPlayer' and it's data was not put into the revData dictionary before it fired. The other possibility amongst many possibilities is that it was put in, but the data is in the wrong format. For example 'iJoinPlayer' key is suggesting by the 'i' at the start of it that the accompanying data will be an integer, most probably the players ID.

This is not easy stuff! With no real debug tools, you have to really hunt it down to find it and it can take a long time. The coder uses print statements to work out what is going on in the code as for example:

if( self.LOG_DEBUG ) : CvUtil.pyPrint(" etc etc)

You have to have a save game file of the moment before the error and you have to be sure that the error fires repeatedly every single time you run that save game. Once you have that, you can then start tracing through the code.

I'll stay in touch but leave it at that for now.