Bug Reports

If there are any critical ones you noticed in the past that RevDCM hasn't yet corrected themselves, please, do share them with us. ;)

They are not critical. But while forests and jungle grow the battle 3 and 6 won't grow. You can remove battle7 (fallout) and get a battle effect free plot. That's wrong. Also if a forest grows on a battleplot there won't be battle6 generated. And sometimes battle 3 and 6 have been forgotten.

You see minor things. As a result I've done a rework of the feature.
 
The best thing to do with battle effects is to extricate them completely, and then allow them to be added back in as an optional add on or WoC module for the rare users (and developers like glider) that like them. Probably 1/100 users ever turn this feature on, and it's messy, buggy, and complex code. Also the AI has no understanding of it whatsoever, so in terms of gameplay mechanics it is also broken.
 
The best thing to do with battle effects is to extricate them completely, and then allow them to be added back in as an optional add on or WoC module for the rare users (and developers like glider) that like them. Probably 1/100 users ever turn this feature on, and it's messy, buggy, and complex code. Also the AI has no understanding of it whatsoever, so in terms of gameplay mechanics it is also broken.

Or I could re-design them in a neater, less messy way. Like I have.

I've removed all traces of the extra features from Battle Effects, added a few new global defines to allow modders to configure the individual yield penalties from battles, and made them a smoke effect that gets updated from python. The effects used are chosen via XML, a new boolean tag on CIV4EffectInfos, and are randomly selected each time the game starts. I have included only changed files in the attachment.
View attachment RevolutionDCM.zip
 
Ok Afforess well done knocked up something quick. That's called cooking with the code! You seem to be on the boil at the moment. I'll have a look at it and report back. Phungus on the bipolar opposite end has a point about Battle Effects as well. The issue is that I keep forgetting that this mod now supports MP! So we probably do need to reorganize options to ensure that either no MP players get them, or all MP players get them. There are a few ways to do that including Phungus's "addon" approach.
Cheers
 
Ok Afforess well done knocked up something quick. That's called cooking with the code! You seem to be on the boil at the moment. I'll have a look at it and report back. Phungus on the bipolar opposite end has a point about Battle Effects as well. The issue is that I keep forgetting that this mod now supports MP! So we probably do need to reorganize options to ensure that either no MP players get them, or all MP players get them. There are a few ways to do that including Phungus's "addon" approach.
Cheers

I had the same issue with my options, and my solution was to make them adjustable for the host (active player == 0) and greyed out, but visible for all other players.
 
I have merged the Battle effects code to the SVN. Also I have done a rough and dirty merge of BBAI using Fuyu's BUGAI mod as a base; however the BBAI merge left original Revolutions functions in place if they conflicted with new BBAI code, so jdog will need to go over it again and also fine tune some logic for the AI's handling of specific RevDCM issues. For the most part though the tedious brute force work is done. Also thanks again Afforess for cleaning up Battle Effects, that has been something that needed to be done for a while. I'd also really like to get in the Ruthless AI option, if you can put up a similar zip file with the merged Ruthless AI code as you just did with the battle effects clean up :)
 
Okay, I've merged Ruthless AI and have only the updated files included. I ran a test game, and it worked fine. I even had a team purchase a war ally against me and dogpile me. :mischief:

I also took the liberty of updating the RevDCM options tab so that it will be accessible in MP, albeit only the host will be able to configure options. All other players will see the options, but they will be greyed out and un-selectable.

View attachment RevolutionDCM.zip
 
Okay, I've merged Ruthless AI and have only the updated files included. I ran a test game, and it worked fine. I even had a team purchase a war ally against me and dogpile me. :mischief:
I think you forgot to include the source files ;)

I also took the liberty of updating the RevDCM options tab so that it will be accessible in MP, albeit only the host will be able to configure options. All other players will see the options, but they will be greyed out and un-selectable.
That's awesome afforess! Thanks for doing that, it's something I've been wanting to work on for a while. Now what we need to do is grey out the Chop and Sentry actions from BULL in MP games, as these also break MP games if they are different. And finally we need to set up a way for all non host players to sync up their RevDCM and Chop and Sentry options to the host's options, that way everyone would have the same settings set when playing. I think the best way to do this would be to set up a new Python function, probably as it's own module "MPEnforcer.py" or something, that checks the PlayerID of all players at the start of each turn and syncs all RevDCM options and the afformentioned BULL options that need to be the same with the player who has the lowest ID number (will almost always be 0 for the host, I can't think of how it couldn't be actually, but using the lowest will ensure that the function will still work after the host player dies).
 
I think you forgot to include the source files ;)


They were in there.... I could have swore. Anyway, here they are.;)
View attachment CvGameCoreDLL.rar

Now what we need to do is grey out the Chop and Sentry actions from BULL in MP games, as these also break MP games if they are different. And finally we need to set up a way for all non host players to sync up their RevDCM and Chop and Sentry options to the host's options, that way everyone would have the same settings set when playing. I think the best way to do this would be to set up a new Python function, probably as it's own module "MPEnforcer.py" or something, that checks the PlayerID of all players at the start of each turn and syncs all RevDCM options and the afformentioned BULL options that need to be the same with the player who has the lowest ID number (will almost always be 0 for the host, I can't think of how it couldn't be actually, but using the lowest will ensure that the function will still work after the host player dies).

I actually dealt with this problem with my mod today...

I categorized my options into two different types...

Game-Wide options that should be the same for all players in MP.
And Player-Wide options that can differ player to player.

Game-wide options I just left configurable for the host, and disabled for other players, but I created a new enum class and primitive variable type (ModderOptionTypes) and saved player-wide options for each player. That way, in BULL's case, each player could have their own chop settings without causing an OOS or any other conflicts. The implementation is very very similar to the way PlayerOptionTypes work right now.

I'd be willing to share my code for that.
 
They were in there.... I could have swore. Anyway, here they are.;)
:hmm:
Where is here, I do not see it?

Your solution for MP sounds good, and I'd like to merge that too. My original idea for syncing to the host via a python function was so that the implementation of the code could be applied to BUG itself; the new Enum types code couldn't work for BUG as it would break save game compatibility. Basically the closer BUG is to RevDCM the easier it is for me on merging as BUG is updating :mischief: Given that you use RoM as a base for your mod, which in turn uses a RevDCM core which in turn uses a BUG core, I'm sure you can see the benifits of applying the code to the base mod over the derivative. But that was just the way I originally was looking at it. If you have working MP code here that can easily be merged into RevDCM (Which I assume it can be since AND uses a RevDCM core) I'd definatly want to go with that, as it would be great to pop it in and have MP functionality working with the RevDCM options tab in the RevDCM SVN. So yeah, if you have the MP code done and fully working, and the Ruthless AI merge done, please put those up and I'll merge them into the SVN right away.

And thanks again Afforess for this, these are two major improvements for RevDCM that I've wanted to get into the 2.8 build for a while now. I definitely appreciate your work here.
 
Current save throws an assert failure because the player index is out of bounds (specifically it is less then 0, assuming it's -1 for None). Adding some code to get the Python to throw an exception when this occurs leads to:
Code:
	def onFirstContact( self, argsList, bVerbose = True ) :
...
		[B]playerX = gc.getPlayer(teamX.getLeaderID())[/B]
In BarbarianCiv.py

I normally would just add a check to make sure this value is not passed into the getPlayer function, to fix the assert. However right below the code you have a control statement error message that is commented out:
Code:
		if( playerX == None or playerY == None ) :
			#if( self.LOG_DEBUG ) : CvUtil.pyPrint("  BC - Error: didn't find any players")
			return
So I suppose something is going wrong here you might want to take a look at.

The save is for the current version of LoR on the SVN.

Jdog I'm going to update the LoR SVN soon, and this save with the bug will loose save game compatibility. So if you want to take a look at what's going wrong in the save you should grab the current LoR SVN within the next 24 hours. This isn't an easy bug to reproduce either, I played 3 games before this showed it's head.
 
Jdog I'm going to update the LoR SVN soon, and this save with the bug will loose save game compatibility. So if you want to take a look at what's going wrong in the save you should grab the current LoR SVN within the next 24 hours. This isn't an easy bug to reproduce either, I played 3 games before this showed it's head.

Phungus, I assume this bug occurs when getLeaderID returns -1, which implies that the team has no player members in it. So this check beforehand should stop any errors:

Code:
		if ( teamX.getNumMembers() == 0 or gc.getTeam(iHasMetTeamY).getNumMembers() == 0):
			return
			
		playerX = gc.getPlayer(teamX.getLeaderID())
		playerY = gc.getPlayer(gc.getTeam(iHasMetTeamY).getLeaderID())


:hmm:
Where is here, I do not see it?

*facepalm*

Anyway, it's there now, unless I'm hallucinating. In which case, I want a pony. :mischief:

Your solution for MP sounds good, and I'd like to merge that too. My original idea for syncing to the host via a python function was so that the implementation of the code could be applied to BUG itself; the new Enum types code couldn't work for BUG as it would break save game compatibility. Basically the closer BUG is to RevDCM the easier it is for me on merging as BUG is updating :mischief: Given that you use RoM as a base for your mod, which in turn uses a RevDCM core which in turn uses a BUG core, I'm sure you can see the benifits of applying the code to the base mod over the derivative. But that was just the way I originally was looking at it. If you have working MP code here that can easily be merged into RevDCM (Which I assume it can be since AND uses a RevDCM core) I'd definatly want to go with that, as it would be great to pop it in and have MP functionality working with the RevDCM options tab in the RevDCM SVN. So yeah, if you have the MP code done and fully working, and the Ruthless AI merge done, please put those up and I'll merge them into the SVN right away.

I'll go hit up EF, because my idea won't even break save compatibility... since the options are already saved in the UserSettings folder, there's no reason to save them in the SDK again.
 
One small question, is it possible that the popup menu asking if to abandon or to install a new governor while a city flipps is somehow prohibited by the revolusions mod, even if revolutions is disabled on the options menu?

Many thanks.


You are exactly correct, that is what was happening. It has been fixed (CvPlayer.cpp line 2920) in svn and the fix will be included in the next version. When phungus gets back I'm sure he will quickly add it to LoR as well.

Hi Jdog5000, on May the 20th you published the fixed CvPlayer.cpp on SVN and titled it
Fix for no "Disband city?" popup when city flips and Revolution is not on.

I've downloaded the file and imported the change to LoR svn and compiles me a working CvGameCore.DLL

Somehow on the latest LoR SVN from May.06 the fixed line is missing, so I've checked your SVN and the fix is gone, the relevant code is back to as before the fix.

Was there a problem with the fixed line?
 
I have done a rough and dirty merge of BBAI using Fuyu's BUGAI mod as a base; however the BBAI merge left original Revolutions functions in place if they conflicted with new BBAI code, so jdog will need to go over it again and also fine tune some logic for the AI's handling of specific RevDCM issues. For the most part though the tedious brute force work is done.
Not enteriely sure if it was intentional but if not, using my merge as a base might not have been the greatest of ideas because my mod is not a 100% merge but includes a bit of experimental code of my own, which made it to RevDCM with this merge. Most of it is in CityAI and I think most of it is both good and marked with "Fuyu" but I seem to have forgotten to put any indication that this is not jdog's code to the PlayerAI part that handles UNITAI_ATTACK_CITY values (just search for "// Effect army composition to have more collateral/bombard units").
Since that merge on June 1st I also toned down my additional worker building, see "City %S uses choose worker 6a", and 6b.

So, if you see bugs that weren't there before revision 512 I suggest replacing my playerAI code and maybe some other parts with jdog's original BetterAI code. And please report to me if that actually fixes bugs/bad behavior.
 
Hi Jdog5000, on May the 20th you published the fixed CvPlayer.cpp on SVN and titled it
Fix for no "Disband city?" popup when city flips and Revolution is not on.

I've downloaded the file and imported the change to LoR svn and compiles me a working CvGameCore.DLL

Somehow on the latest LoR SVN from May.06 the fixed line is missing, so I've checked your SVN and the fix is gone, the relevant code is back to as before the fix.

Was there a problem with the fixed line?

Looks like a later merge accidentally took at that fix, I will add it back. Thanks for the warning.

Not enteriely sure if it was intentional but if not, using my merge as a base might not have been the greatest of ideas because my mod is not a 100% merge but includes a bit of experimental code of my own, which made it to RevDCM with this merge. Most of it is in CityAI and I think most of it is both good and marked with "Fuyu" but I seem to have forgotten to put any indication that this is not jdog's code to the PlayerAI part that handles UNITAI_ATTACK_CITY values (just search for "// Effect army composition to have more collateral/bombard units").
Since that merge on June 1st I also toned down my additional worker building, see "City %S uses choose worker 6a", and 6b.

So, if you see bugs that weren't there before revision 512 I suggest replacing my playerAI code and maybe some other parts with jdog's original BetterAI code. And please report to me if that actually fixes bugs/bad behavior.

Thanks for the heads up Fuyu, I'll try to sort that all out.
 
This is not strictly a bug but it is probably a mix between a question and an enhancement request:
Playing ROM 2.9.2 which contains revolution mod.
Having 5 cities with the capital in the middle and the other cities 4 to 5 squares away.
Why does the mod consider this as a "distant location"? It is just 1 square more than the lowest allowed distance, so it is really close.

5 cities is a large empire? Why that? Where can I see the limits?

In general I get the impression that the mod is set too tough. Is it possible to configure that?
 
Did ranged bombardment get changed? When my catapult wants to target 2 fully healed axemen in jungle hills, the targetting square gets green but I cannot fire off the catapult. Any idea why?
 
This is not strictly a bug but it is probably a mix between a question and an enhancement request:
Playing ROM 2.9.2 which contains revolution mod.
Having 5 cities with the capital in the middle and the other cities 4 to 5 squares away.
Why does the mod consider this as a "distant location"? It is just 1 square more than the lowest allowed distance, so it is really close.

5 cities is a large empire? Why that? Where can I see the limits?

In general I get the impression that the mod is set too tough. Is it possible to configure that?

What size map are you playing on? Because I believe the empire size is dictated by map size so on a huge it would be a small empire but on a duel it would be large.
 
Large Map - I think I already know what the problem was. I did not look closely enough. ROM deliberately sets negative modifiers due to the starting civics.
 
Back
Top Bottom