RevolutionDCM for BTS

@Duuk
Work on Inquisitions for RevDCM using OrionVeteran's latest Inquisitions build is underway. Orion has based his code on bmarnz, so this Inquisitions will be traceable again back to bmarnz the inquisition champion. Thanks for the thoughts on what is causing the bugs. Time will tell.

@Phungus
Yeah I see your point about it being a possible addon. Configurability is important. My workload is too high but the good news is that I've got access to a quad four machine to run background stability/balance tests. Unfortunately the machine does not have any civ software on it......yet!

Cheers.
 
For the next release could you offer a seperate gamecore.dll without DCM Artillery and Archer bombard merged in? I'm pretty sure these two components are the cause of the only true gameplay bug to the mod (cannot bombard in friendly territory). It's possible it's another DCM component that causes it, but these two components are redundant anyway as their effects can be added by XML in the CivUnitsInfos file.
Spoiler :
If you really like Ranged bombardment for artillery though, there is a work around, thanks to the new functionality of the <iairrange> tag in the unitinfos.xml file.

Example. Open the CIV4unitinfos.xml file (found ....mods/WolfRevolution/Assets/XML/Units) using notepad, or some sort of codewriting utility. After opening the file in notepad use the Edit options, and select find. Type in Unit_Catapult you'll get taken down the file to this line
Code: 
		<UnitInfo>
			<Class>UNITCLASS_CATAPULT</Class>
			<Type>UNIT_CATAPULT</Type>
			<UniqueNames/>
			<Special>NONE</Special>
This is the start of the block that the Civ Engine calls the unit stats for the Unit Catapult. Now use find again this time type in airrange. Since you're in the Catapult block it'll drop you to this line in the catapult block (if you hit it again it'll skip to the next incidence of airrange which the next unit after the cat is treb I think) where this tag is
Code: 
<iAirRange>0</iAirRange>
Change the 0 to a 1 (or 2 or whatever you want the bombard range to be) and the unit will now have the ability to bombard up to the range you set.

After setting the bombard range, you need to set the Bombard Strength, by putting a value in this tag:
Code: 
<iAirCombat>0</iAirCombat>
Typically you will want to set this as the same basic strength of your unit, though you can set it at whatever you like.

Finally you need to set a value for the limit to bombard damage. This is expressed as a percent with 100 being able to kill a unit through bombarding, and 1 meaning you cannot harm a unit that is more then 1% injured. This is the tag:
Code: 
<iAirCombatLimit>0</iAirCombatLimit>

You can do this with any and all land and sea domain units..
Another bonus to setting artillery bombard through the XML and not via the bugged DCM method, is that the AI has a better understanding of the function.

A core without DCM would also be fine by me overall if it's easier, and also in case removing those components alone don't fix the bug. Course if it's too much work I understand, I honestly don't know how hard it is to compile a .dll
 
I'm all for fixing the cannot-bombard-in-friendly-territory-bug in DCM. One question about this XML fix, though... does it resolve the bombardment by the same rules as the DCM rules?
 
I'm not exactly sure what the DCM rules are, so I can't really answer that. What it does is allows a unit to make a first strike type attack on a target. The range is set by the airrange tag, strength by the airstrength tag (typically you'd set this to be the default strength of the unit), and maximum damage allowed to target set as a % by the aircombatlimit tag.
 
@Phungus
Would love to help with sorting out the DCM bombardment issue and any other bug by releasing sub-builds. Your suggestions are good. The problem is when. At the moment I'm working on Inquisitions for RevDCM according to our list of specific requirements for it. Have the time for only one thing at a time! Once Dresdon releases his patch, a lot of things will happen very quickly.
Cheers.
 
@LordGek
Ok thanks. I am now more busy. There is one unresolved component. Jdog normally will release a Revolutions with both better AI and Dresdon. If he hasn't done it in the next couple of days, I will do it myself including BUG 3.5.
Cheers.
 
:lol: I have started trying out some things to kill the bombardment bug. So at least we can share the load... :)
 
glider1 said:
@LordGek
Ok thanks. I am now more busy. There is one unresolved component. Jdog normally will release a Revolutions with both better AI and Dresdon. If he hasn't done it in the next couple of days, I will do it myself including BUG 3.5.
Cheers.
Click to expand...

The fact he was so actively involved in both of these efforts, I'm sure the Jdog will deliver in a timely manner!
 
Okay, I've posted a solution to the bombardment bug in Dale's thread. :)
 
Ninja2 said:
Okay, I've posted a solution to the bombardment bug in Dale's thread. :)
Click to expand...

Thanks Ninja! Once it's time to compile the new RevolutionDCM core, your work will be re-tested and acknowledged! How do you think you can go on the two bugs in stack attack?!!? ie)

1) Interface can be lost but not all the time
2) Seige can do ridiculous amounts of damage in some cases

(1) could be harder to find than (2) because (1) crosses over with python. However (2) I think is related to a logical error confined to the SDK code and should be relatively easy to track down. I think it is to do with multiple execution of seige damage code between the looping code in ranged bombardment AND the looping code in stack attack.

If nothing more, thanks anyway!
Cheers.
 
I can always have a look... :) I have never used the Stack Attack feature, so I have zero experience in its quirks. Under what circumstances does siege cause too much damage?

@phungus: What is wrong with archer bombardment? I don't use that component either.
 
Ninja2 said:
@phungus: What is wrong with archer bombardment? I don't use that component either.
Click to expand...

Well since you found the bug, probably nothing. I was just concerned it might have been the cause of the bug, along with artillery bombard. I think it's kind of a redundant component since it can be added through the XML as stated above.
 
@Ninja
Thanks for your interest. Once I can single out the specific issue in stack attack with a save game, we could possibly solve it once and for all at the point. There's nothing to gain wasting your time until then.
Cheers.
 
phungus420 said:
I think it's kind of a redundant component since it can be added through the XML as stated above.
Click to expand...

Just to confirm in case I'm confused, you are saying that archer bombardment and ranged bombardment code can be effected through nothing but XML yes? I think I can see how that might be done. You must be referring to human to human play without an AI obviously.

Cheers.
 
Here's a release prior to integration with BUG 3.5. Comments welcome. Once a new Revolutions version is released, BUG migration willl then happen and an official release will be out. Mean time enjoy. I will not be able to do any more work on RevDCM for a few days.

v0.96:
- Updated to Revolution 1.64b
- Updated to Better BTS AI 0.41B (includes Dresdon unofficial patch 0.21)
- Updated to Super Spies 1.3 (see readme)
- Included Ninja2's bug find regarding not being able to bombard from friendly territory (thanks!)

Congrats to all you Americans for a truly great election day!
Cheers.
 
Thanks for getting this out. Where are the Super Spies and Inquisitions add ons?
 
Super Spies is built in (check out the various readme's). Inquisitions is not finished but is coming along nicely according to our discussions about it. I'd be interested to hear what you think about this 0.96 test build. I know that it's stable, but haven't been able to test it in detail.
Cheers.
 
I read the readme. Is there a way to disable Super Spies? I like it, but I've been offering the WolfRevolution mod so far with this component being optional, and I'd like to leave it that way if possible. Also was the last version of inquisitions add on compatible with this build? Again I don't play with the previous version of inquisitions as I don't like the purging of holy cities. I'll be giving the new one a try once you release it for sure. I'd like to know though if the previous 0.95.1 RevDCM build inquisition add on works with RevDCM 0.96 so that I can continue offering it as an add on for WolfRevolution. It would just seem weird to me to update WolfRev, and remove an optional add on that seems fairly popular at the same time.
 
@Phungus
This 0.96 build is more of a test build for us to try out for bug fixes and stability. There are a *heap* of changes to the unit AI especially around aerial warfare and Revolutions needs testing around the minor civ option as well. I would save your efforts making new releases until something concrete comes in both Revolution and RevolutionDCM. Only a suggestion because 0.96 is basically the real thing.

In terms of Super Spies, the promotion tree cannot be turned off. I would very much like to add it permanently to the core though and this is an "attempt". A lot of the AI is better bts anyway and the promotions are very cool and don't seem to break the game. The extra missions are all turned off and controllable via xml. Also, there are no extra units or buildings added to the core because of it. I'd like to reduce the workload of having to update inquisitions, nextwar and super spies as addons. As far as I'm concerned, spies should have promotions in the base game anyway.

You are the first to say that you think SS should not be in the core. I wonder how many others?

Cheers.
 
You must log in or register to reply here.

Similar threads

primem0ver
Genetic Era Mod - Repost... and Revival?
Replies
15
Views
1K
keldath
keldath
W
Trying to create shortcuts to individual mods on Steam Deck - what am I doing wrong?
Replies
1
Views
275
lymond
lymond
f1rpo
Taurus
2 3
Replies
48
Views
5K
f1rpo
f1rpo
G
spawnunit
Replies
3
Views
229
globosud
G
M
Installation Problem
Replies
2
Views
319
Metaltooth
M
Top Bottom