RevolutionDCM for BTS

At the moment I do not have access to a PC that I work on with winmerge. I am on a linux computer now. Really easy to compare and build one though. At least I think so. I do not think anything else has changed in that area. You can see the commented section RevDCM something related to projects in the cvinfos.cpp with some text about fixes projects from glider. I will just wait for glider to update the official dll because it is not hard to do.

The rest of the code may get updated in the near future even just waiting on faichele to get his merger done. He is looking at adding the some things extra that the WoC has as well in anyone is interested like another DCM mission called Bomber Engage that he did. He is going to basically merge RevDCM into a new WoC dll anyway. So the code would be easier to move to one or the other anyway.
 
I have noticed two slight bugs in RevDCM 2.5 and didn't see them corrected on the changelog to 2.51:
1. Using the ALT function to upgrade all units of a particular type only seems to upgrade a fraction of the units eligible at any one time, even if there is enough gold.
2. On the Spy missions popup, the Espionage point costs between the mission selection list and the detailed mouseover popup do not agree with each other, with the mouseover popup using displaying a much lower number than the mission selection list.

Are these actual bugs or just features that I am not totally understanding?

Thanks - Infantryman06
 
OK, got it. Now for a few "dumb" questions.

I notice the RevDCM SDK does not include many of the files in the BTS SDK, especially the vcproj file. I assume the missing files need to be copied to the same folder before compiling. I am using VCToolkit 2003 and Codeblocks per refars instructions.

Do I need a makefile? I found references to it but not a link to one in the threads.

For my first project I wand to incorporate the Mountains mod as a switchable item. I know how to merge it into the gamecore.dll but then it is always on. I have read through the thread and have some idea, but don't quite get all of it.

First should I use WOC or WOC Lite? From what I have read, WOC is only for the XML part of the mod, and I did download the WOC converter and WOC Lite, but have not used them yet. I understand the part about modularity in XML files, but I don't see how this gives me that on/off switch in the options menu. Where does that come from?
 
@Johny and Phungus
Thanks for filling in with info about the "infos.cpp". I might be able to knock up an informal dll at some point next few days, but no official release due to lack of time.

@BobTheBull
Looks like it's time for you to go and check out the forum for building a dll:
http://forums.civfanatics.com/showthread.php?t=196283&page=1

Cheers.
 
Hi,

I wanted to raise this issue even prior to checking the actual code, in case someone already knows the answer and it's just like a parameter value or sg.
It seems that ranged bombardment fails more often than specified in the units accuracy tag in XML.
It is more obvious when it's a unit with longer bombardment range(tiles). Is it so that the code is adjusting the hit probability also based on (tile) distance?
 
I noticed the same thing that avain mentioned and would also be interested in any information that is available. Most of my artillery pieces have accuracy set at 100% and they still miss a lot. Sometimes the hit ratio is as low as 50%.
 
Yes, distance is a factor, IIRC.
 
Ninja2,
Thanks.

avain,
If you're interested in changing the way that long range bombardment works. I just did a quick test with bombardment accuracy. I used my heavy artillery that has a range of 8 tiles. With accuracy set at 100, the target was hit about 25% of the time. With accuracy set to 1000 it was hit 100% of the time. It looks like you just need to play with numbers over 100 to get long range bombardment to be more accurate.
 
This isn't a bug per se, but just an oddity I found, and was hoping somebody could help me with. I'm attempting to do my own little modmod, based on RevolutionDCM, and have encountered a puzzling issue.

One of my ideas was to expand the UnitCombat definitions, replacing UNITCOMBAT_MELEE with two new definitions, UNITCOMBAT_LIGHT and UNITCOMBAT_HEAVY. Running RevDCM 2.51, I make the XML changes in Civ4UnitInfos, Civ4PromotionInfos, and add the two new definitions to BasicInfos\Civ4UnitCombatInfos. Everything works fine within the Units, Promotions, etc. However, the Revolution Watch screen no longer works! The button (the little red Che icon) is still visible, but nothing happens when I click on it, nor does Ctrl-Shift-G do anything.

As best I can tell, this is solely due to Civ4UnitCombatInfos.xml. If I roll that file back to the vanilla definitions, then everything's fine. However, if I roll back UnitInfos, PromotionInfos, etc., not using any of my new UNITCOMBATs, but still have them present in CombatInfos, I get the same problem (no RevWatch screen). At first, I thought maybe the number of entries in CombatInfos was referenced somewhere within the Python files, but I tested this out by substituing a different definition (UNITCOMBAT_LIGHT in place of UNITCOMBAT_MELEE), and still had the same problem. I then noticed that zappara's Rise of Mankind, which is largely built on top of RevolutionDCM, has a UnitCombatInfos file with a huge number of new defintions (UNITCOMBAT_WOODENSHIPS, UNITCOMBAT_EARLY_BOMBERS, etc.), but the RevWatch button works fine in RoM (2.71) -- until and unless you make any changes to *its* CombatInfos file, at which point the same thing happens. :confused:

I'm assuming this is some kind of Python issue, and have looked briefly at a couple of .py files, but I'm not seeing anything. I'm hoping there's some kind soul out there who knows what's going on here, and can help me out ...
 
@Sergeant
The rev watch screen not showing is a python problem. First thing is to turn the python logs on in civilization.ini and look in the log folders. That is a good general tip for the sergeant. I'm not sure what's going on but there is another file you have to adjust for new combat types. In the doc's section of this mod there is some notes on merging and modding. Here is one entry that might help:
- Any mod that introduces a new combat type needs to modify BUG:
- Unit Naming.xml (necessary) for example:
<!--RevolutionDCM - add new combat types here or get python isColor error-->
<option id="Combat_SPY" key="CombatSPY"
type="string" default="DEFAULT"/>
- BugUnitNameOptionsTab.py (not necessary)
- in case modifying this, Bug xml text has to be added as well.

Have a read of the python error log and see what it comes up with.
Cheers.
 
Hello,

Two things:

I'm requesting for future feature: that you remove archer bombardment button but let archer bombardment be active anyway for attack support purpose only.

Secondly, for present, how do I go about modding that for myself?

Thanks!
 
Glider -- thanks much for the help. Fixing the UnitNaming file in the Config folder was apparently all it took to resolve my issue; it's now working great. :goodjob:
 
@Sergeant Hulka
Great!!! That was unexpected and a little too simple.....

@GeneralTso
Having helped the sergeant, I would now like to help "the General". When adjusting range bombard, consider these two variables in GlobalDefinesAlt.xml as well:
Code:
	<Define>
		<!-- RevolutionDCM variable - higher values increase ranged bombard inaccuracy making city attack/defense harder against the AI. 100 is equal to previous releases -->
		<DefineName>DCM_RB_CITY_INACCURACY</DefineName>
		<iDefineIntVal>350</iDefineIntVal>
	</Define>
	<Define>
		<!-- RevolutionDCM variable - higher values increase ranged bombard chance to inflict city defense bombard damage over city defender collateral damage. -->
		<DefineName>DCM_RB_CITYBOMBARD_CHANCE</DefineName>
		<iDefineIntVal>5</iDefineIntVal>
	</Define>

@Anyone
A few reasons "I think" why smaller maps work so well from my perspective, is that resource distribution becomes more uneven, thus destabilising global power more readily especially on aggressive. It's probably not that simple! Also the AI seems a lot more "together" strategically with a fewer number of civs. Perfectworld2 small maps are a bit bigger than vanilla small and thus very nice. For the first time I have found a perfect use for aluminium co, to virtually corner the world market for aluminium. The "adjustment" that has to be made coming from being a large map player to a small map player is purely a "perception" adjustment. Just increase the scale in your mind (thinking of cities as the really major cities of the globe and the towns as the smaller regional cities for example), and small maps become huge!

EDIT:
@OS79
Yes I see your point and that might be a nice experiment for new battle concepts. Some changes would have to be made to the SDK code, but not much. I do not have much time, but first port of call is CvSelectionGroup.cpp and the attack support code in that, re-enabling the option for archer bombard only there.

Cheers.
 
@GeneralTso
Having helped the sergeant, I would now like to help "the General". When adjusting range bombard, consider these two variables in GlobalDefinesAlt.xml as well:
Code:
	<Define>
		<!-- RevolutionDCM variable - higher values increase ranged bombard inaccuracy making city attack/defense harder against the AI. 100 is equal to previous releases -->
		<DefineName>DCM_RB_CITY_INACCURACY</DefineName>
		<iDefineIntVal>350</iDefineIntVal>
	</Define>
	<Define>
		<!-- RevolutionDCM variable - higher values increase ranged bombard chance to inflict city defense bombard damage over city defender collateral damage. -->
		<DefineName>DCM_RB_CITYBOMBARD_CHANCE</DefineName>
		<iDefineIntVal>5</iDefineIntVal>
	</Define>
Could you explain these values a little more in depth?
 
Having installed 3.19 and got RevDCM to work is there a version available that isn't WoC-ified? Or do standard modules (like civs) work with it anyway?
 
Having installed 3.19 and got RevDCM to work is there a version available that isn't WoC-ified? Or do standard modules (like civs) work with it anyway?

They work just like before, the WoC does not take anything away, it just adds the option to break it down even more modular. Any xml you could use before can still be used.
 
Back
Top Bottom