incremental patch discussion

[Ahriman]

Great job. I don;'t understand the code very well, but are we confident that this doesn't affect any other issues? Like the attempts to make the AI more likely to unload its soldiers from transports when it moves over land?

We'll also need to test, to make sure that the AI doesn't end up just futilely suiciding its suspensors and thopters against city defenses, rather than primarily using them to harass and only attacking cities against heavily weakened defenders.
Otherwise we might find that we were better off with the city atatck disabled (except for the Monitor).

Also, can I make a shout-out for thinking about slavery (remove whipping, maybe other changes) and/or catchbasin water penalty?
The AI really does spend a lot of its game suboptimally using slavery civic and whipping away its population (also suboptimal, since water is the binding factor here, whereas in vanilla where whipping was designed for happy-cap is the binding factor).

[Another thought: can we make whipping a Harkonnen-only feature, and then increase its hammer yield? Maybe make slavery a Harkonnen-only civic if needed.]

 

[Deliverator]

Great job. I don;'t understand the code very well, but are we confident that this doesn't affect any other issues? Like the attempts to make the AI more likely to unload its soldiers from transports when it moves over land?

To be honest, I don't understand the purpose of the newer block of code too well, but I can read koma's original logic which effectively means that if the unit is All-Terrain then there is no such thing as a move being an amphibious move. The code that replaced it doesn't look like a considered change for Dune Wars, but rather a unthinking merge from RevDCM/BBAI I guess. This code is not AI related code at all, it just controls whether it is possible for a group of units (or single unit) to make a particular move. So I'm fairly sure it won't make AI decision making any better or worse.

We'll also need to test, to make sure that the AI doesn't end up just futilely suiciding its suspensors and thopters against city defenses, rather than primarily using them to harass and only attacking cities against heavily weakened defenders.

Agreed. The bug has meant that the AI has been unable to throw away its Thopters/Suspensors even if it wanted to.

Also, can I make a shout-out for thinking about slavery (remove whipping, maybe other changes) and/or catchbasin water penalty?

On slavery, the best solution would obviously be to make the AI limit its whipping as would the human player. Despite my new found ability to change and compile the SDK I wouldn't know where to start with that...

The catchbasin changes seem fair to me. We all the recent goings on, I haven't really swept through all the feedback we've had in a systematic way.

Another thought: can we make whipping a Harkonnen-only feature, and then increase its hammer yield? Maybe make slavery a Harkonnen-only civic if needed.

Now that the tech tree work is pretty much done (I know there are some outstanding issues), my view is that the next thing to do is to review where we are up to with faction differentiation and flavour. There have been a few ideas floating around for the Harkonnen, I'll try and collect together and we can discuss in the Civs thread.

 

[Ahriman]

code that replaced it doesn't look like a considered change for Dune Wars, but rather a unthinking merge from RevDCM/BBAI I guess

Ok, then unwinding sounds good.

The bug has meant that the AI has been unable to throw away its Thopters/Suspensors even if it wanted to.

I'll try some testing tonight or over the weekend.

On slavery, the best solution would obviously be to make the AI limit its whipping as would the human player

My problem is, with water as scarce as it is, I'm not sure that its *ever* optimal to whip, with the sole exceptions of wonder completion (the AI does this; I hate it how it magically sees that I'm 2 turns away from completing and then whips its own wonder to get done first) and whipping out a defensive unit in a threatened city (ie equivalent to drafting - or homeworld unit purchase).

I was never a huge whip user in vanilla, but my understanding was that it was mostly used in cities with large food bonus tiles, where even a size ~3 city could be pulling in a net of 5-6 food per turn. You just don't really get this in DuneWars. Water is much more scarece than vanilla food, you don't have cities getting 2-3 food from every tile + improvement value + bonuses like wheat/corn/rice or pigs available in the very early game.

So in Dunewars your long term economy is nearly always better served by not whipping.

Also:
Do we know much about the civic selection AI? It would be much easier to get AIs to use/not use slavery or to pick between Paradise and Spice futures if we understood that code a bit better. I think the problem with Paradise is that it doesn't offer anything that the AI actually understands well (just the buildings, with +happy but negative water), whereas Spice offers an improvement boost and an extra unit and a building.

 

[davidlallen]

I'll post a 1-7-2-6 patch shortly, with the new DLL, source code, plus the Monitor/Great Convention python and an art fix. Then I think we are set to release 1.7.3.

Awesome! Yes, I will pack up this stuff into 1.7.3. Since 1.7.1 and 1.7.2 had different bad bugs, I don't think I will put other speculative changes in. We can try some of those in 1.7.3.1.

I like the idea of slavery as a Harkonnen-only civic with some special bonus. I have not experimented carefully, but it seems that in autoplay games, Harkonnen often winds up at the bottom in score. If slavery decreases population, as found by Ahriman, this is worse for Hark because it is their favorite civic.

I don't think a civic can be restricted by civilization today, and I don't think a leaderhead trait can enable whipping; but maybe we can make this a good unique ability for them. It is certainly supported in canon.

 

[Praylak]

In my past few games I've had with 1.7.3, the Harkonnens seem to consistenly be at the bottom as well. I even tried them with a few go's to 150-200 turns or so, and I was having a hell of a time with them, as in not good. Can't put my finger on it, but I think the slavery civic hurts them more than the gain.

UPDATE: Ok so my last game now they are in 3rd place. I'm playing Ix, and we share a common landmass. They are holding quite firm in the arms race with me. So I don't know now. I guess you need more than just a few games to do a real assessment of any faction.

 

[Deliverator]

Incremental Patch 1.7.3.1

Install Sequence: 1.7 -> 1.7.3 -> 1.7.3.1

The purpose of this patch is merge in the TheLadiesOgre's TLOTags modcomp (version 0.40). This is the closest attempt I've seen to bring some of the Fall Further promotions functionality into standard BTS. There a few useful tags that this modcomp adds to promotions such as pillage on move and respawning.

The full list of new XML tags is here:

Spoiler :

CVPromotionInfo
<bAutoAcquire>: If a unit possesses all of the prereqs for a promotion tagged with this, the unit will automatically recieve this promotion (however, they will not recieve the promotion until they have enough experience unless the promotion is also tagged <bNoXP> (i.e. the choice is forced unless also tagged <bNoXP>))

<bDefensiveVictoryMove>: If this is set to 1, whenever the unit wins while defending, they will gain one point of movement.*

<bFreeDrop>: If this is set to 1, paradropping does not act as an attack or cost any movement and the unit can drop onto FoW tiles. (In addition to being available with a promotion, I have also given this to Paratroopers by default)

<bIsMechOnly>: If this is set to 1, this promotion will only be offered to units which are <bMechanized>.

<bIsNoMechs>: If this is set to 1, this promotion will not be offered to units which are <bMechanized>.

<bMustMaintain>: If for any reason the prereqs for this promotion are no longer met, the unit will lose it.

<bNoXP>: This promotion is free (so long as the prereqs are met).

<bOffensiveVictoryMove>: If this is set to 1, whenever the unit wins while attacking, they will gain one point of movement.*

<bOneUp>: If this is set to 1, a unit that is given this promotion will get an "extra life".

<bPillageCulture>: If this is set to 1, the unit will pillage culture (ala IDW) whenever they pillage a tile.

<bPillageEspionage>: If this is set to 1, the unit will recieve espionage points (vs. the owner of the tile) whenever they pillage a tile.

<bPillageMarauder>: If this is set to 1, the unit will pillage twice (if possible) whenever they pillage a tile.

<bPillageOnMove>: If this is set to 1, the unit will pillage (free of charge concerning attack/movement) whenever they move to a new tile that is applicable.

<bPillageOnVictory>: If this is set to 1, the unit will recieve the profits of pillaging (though with no tile improvement loss) on a combat victory.

<bPillageResearch>: If this is set to 1, the unit will pillage research (toward their current research tech) whenever they pillage a tile.

<bStackEffect>: This promotion may be purchased as many times as the player sees fit.

<iAirCombatLimitChange>: Whatever number is entered here will be applied to the units Air Combat Limit.

<iCollateralDamageLimitChange>: Whatever number is entered here will be applied to the units Collateral Damage Limit.

<iCollateralDamageMaxUnitsChange>: Whatever number is entered here will be applied to the units Collateral Damage Max Units Limit.

<iCombatLimitChange>: Whatever number is entered here will be applied to the units Combat Limit (thus making it possible to kill with collateral damage if the % goes over 100%).

<iExtraDropRange>: Whatever number is entered here will be applied to the units drop range (thus giving units previously unable to paradrop the ability to do so; Note: Animations still needed).

<iExtraStrength>: Whatever number is entered here will be applied to the units base strength.

<iSurvivorChance>: Whatever number is entered here will be the chance that the unit has to survive a combat loss.

<iVictoryAdjacentHeal>: Whatever number is entered here will be the chance that the unit has to give one turn's worth of healing to all friendly units on an adjacent tile on a combat victory (offensive or defensive).

<iVictoryHeal>: Whatever number is entered here will be the chance that the unit has to heal (one turn's worth) on a combat victory.

<iVictoryStackHeal>: Whatever number is entered here will be the chance that the unit has to give one turn's worth of healing to all units on the same tile on a combat victory (offensive or defensive).

<PrereqCivic>: One of these civics is required to take this promotion (multiple entries may be made).

* I have not seen either of these give more than one point of movement per turn.

CvTerrainInfo

<bRequiresFlatlands>: Cloned from improvements, if this is set to 1 the terrain type will only be found on flatlands.

<iHealthPercent>: cloned from features, the number entered here will modify a city's healthiness (similar to jungles only now it is the actual terrain instead of the feature on the terrain).

<iTurnDamage>: cloned from features, the number entered here will be the damage that a unit takes per turn on this terrain (similar to fallout only as above)

**All new fields added to CvTerrainInfos currently default to 0**

CvUnitInfo
<bFreeDrop>: As noted above, this is also a unit tag which I have set to 1 for paratroopers by default.

<PrereqCivic>: This civic is required to train this unit.

There are some interesting possibilities with these. We should now be able implement the ghola respawning now via XML; we could make Salt or Deep Desert damaging to units; have promos only available to certain Civics; and I'm sure there are other ideas.

Since this was a big SDK merge I thought I'd only make one small change to try this out. I've created a Promotion called Marauder which is the pillage on move promo. The Razzia Raider has been reduced to 8 strength, had its withdrawn bonus removed, but now starts with Marauder. I've stuck Marauder at the tech Jihad and it follows on from Combat 1 - I haven't put any thought into this but these settings are easy changed via XML.

It seems to work fine, but it would be good to get further testing against this new SDK/DLL. Be on the look out for anything weird going on (well weirder than usual).

Download Link

 

[Ahriman]

we could make Salt or Deep Desert damaging to units;

I'd vote against this, I think its likely to mess up the AI.

The Razzia Raider has been reduced to 8 strength, had its withdrawn bonus removed, but now starts with Marauder

Nice. I'd probably still leave it with a small withdraw chance. But Marauder sounds great.

I've stuck Marauder at the tech Jihad and it follows on from Combat 1 - I haven't put any thought into this but these settings are easy changed via XML

Hmm. I would lean towards having Marauder be unselectable, to make the units that have it more interesting and purposeful.

 

[Ahriman]

I concur

Ok. The attached files include the following changes:

Spoiler :

AHR 201 (partial), blocked Sardaukar Noukker for all factions except Corrino.
Still need to consider adding an Imperial Levy heavy trooper with no upkeep cost.

AHR213 Scorpion strengths tweaked (light/med/heavy to 15/18/22 from 16/22/22)

AHR214
Harkonnen Devastator 2 moves to 1 move (its a super-heavy.
Tweak strength 30 -> 28.

Lasgun strength/first strike tweaks.

Reduce cathedral costs for Shai-Hulad, CHOAM, Imperial 300->200 hammers (they're over-priced atm).

Reduce Political center cost 450 -> 300.

AHR215
Move crystal reveal to mining.

Add +1 commerce to ice driller at water economy.

[Later benefits will come from superseding the driller with a Melting Lens improvement.]

Tweak mine yields (diamond commerce yield was falling from a level 2 mine).

Hopefully these can get merged into the next version.

The other changes warrant some discussion, or I'm not sure how to do.

 

[davidlallen]

@ Ahriman, I recommend to read the first content post in my new thread on howto build a release. If you can create zipfiles which have the proper directory structure, it will be much easier for others to merge your changes. Also, this type of zipfile could be directly used as an incremental patch.

 

[dusckr87]

@ Ahriman, I recommend to read the first content post in my new thread on howto build a release. If you can create zipfiles which have the proper directory structure, it will be much easier for others to merge your changes. Also, this type of zipfile could be directly used as an incremental patch.

I zipped Ahriman's changes and put them into a new folder structure if this will help.

Edit: deleted attachment---see post #1112 for why

 

[davidlallen]

Thanks! But some of the files in Ahriman's zip and some of the files in deliverator's zip are the same file, such as unitinfos. If somebody installs deliverator's first, and then Ahriman's, some of deliverator's changes will be wiped out. Putting the files into the proper directories makes it *easier* to merge, but the merge still has to be done.

 

[dusckr87]

Thanks! But some of the files in Ahriman's zip and some of the files in deliverator's zip are the same file, such as unitinfos. If somebody installs deliverator's first, and then Ahriman's, some of deliverator's changes will be wiped out. Putting the files into the proper directories makes it *easier* to merge, but the merge still has to be done.

Well, "quicker" not really "easier". I didn't catch that one file had the same name but didn't include the previous changes. My bad.

 

[keldath]

Deliverator, my my you have been busy...

great job with all those xml tags!


****

i know you i annoy you guys a lot with the sdk, and bbai, but i cant help my self, i feel like doing something for the mod,

so ill just update you guys:

in continue to the debate on making a fresh dll for dune, and taking what you wrote about it,
ive been working on a clean dll, with only what dune needs - meaning - im removing revolution code, and basing the dll on 2 things only : bbai + bug, things that we all like right?

so ive started with the mod that did that for us: http://forums.civfanatics.com/showthread.php?t=354019 - which does exactly that.

i have added all of the dune code , by david, cephalo and the rest. as i went through, most of the new bbai - doesnt changes stuff near the important dune code - like transports and such, so it was an easy merge - just copy paste.

ive used the latest 1.7.3.1 dll code.

after i finish i will give it a try, and play a little to see if its going well,

i bet that you guys, would accept going into this new dll, since it will spare us updating sdk code, and fear instability with revolution code.
im sure bbai 0.90 only adds to the game so it is the most important part, so basically bbai will be the only thing we will "need" to update.

i hope you guys like this idea - i havnt failed you before with sdk, took me a while to convince you to go from revdcm 2.5 to 2.61....

id love to know what you guys think.

kel.

 

[Ahriman]

I am no expert at all on the sdk files (so discount my comments appropriately), but wasn't it one of the revdmc updates that broke suspensor/thopters and cities?

Blind updating is what got us into this trouble.

If you can separate out just the features that we really want, then I think that would be hugely valuable. That would allow us to stop blindly following any external updates, and only adapt any features that we really want.

But we need to be careful about BBAI, what is good AI for vanilla is not necessarily good AI for Dune Wars.

[I note we seem to have lost whatever changes we had that made the AI unload transports instantly, many times in game I am able to destroy transports on land tiles.
It is possible I suppose that the transports are still en route to some other target city, but its still problematic that they can be destroyed so easily.
Also, this may be entirely unrelated to the various sdk plugin mods we've added.]

 

[keldath]

If you can separate out just the features that we really want

yeah thats my main goal, im tired of updating the game every time... so i want to have a dune dll with the stuff we like.

bbai brings a lot to the game, perhaps, if i get help from d&d on the sdk, they could go over it a bit and see that the new stuff doesn't hurt dune, and ajust it, we could determine a final sdk (for outside modcomps - jimprovement and the rest). so the only thing we will update - is the stuff that we (d&d will add).

[I note we seem to have lost whatever changes we had that made the AI unload transports instantly, many times in game I am able to destroy transports on land tiles.
It is possible I suppose that the transports are still en route to some other target city, but its still problematic that they can be destroyed so easily.
Also, this may be entirely unrelated to the various sdk plugin mods we've added.]

well - that i dont know the cause for, i bet david would know.
__________________


**
as for dales code - ive also removed this - and i found a nice way to make ranged bombardment for units using vanilla bts code - all we have to do is set an air range to land units + aircombat - and bang you have a ranged attack (though it wont be collateral - only close attack will be) this will also will be a kind of a clean up for the mod, but that's just a suggestion since i can easly add dales code.

 

[Deliverator]

Deliverator, my my you have been busy...
great job with all those xml tags!

Thanks keldath. I have much more sympathy with you and the difficulties of merging having done this. There were a couple of points where I had to basically rename variables and combine logic a bit, but mostly it was OK. Obviously, where there is no conflict or overlap in the code merging is relatively safe, but you have to be careful to (ideally) understand what the code is doing when there are conflicts. Ideally, I would only add in the tags that we are specifically interested in right now, but since I'm pretty new to this SDK business it was simpler to take the lot.

so ill just update you guys:

in continue to the debate on making a fresh dll for dune, and taking what you wrote about it,
ive been working on a clean dll, with only what dune needs - meaning - im removing revolution code, and basing the dll on 2 things only : bbai + bug, things that we all like right?

so ive started with the mod that did that for us: http://forums.civfanatics.com/showthread.php?t=354019 - which does exactly that.

i have added all of the dune code , by david, cephalo and the rest. as i went through, most of the new bbai - doesnt changes stuff near the important dune code - like transports and such, so it was an easy merge - just copy paste.

Now, that I've got to grips will compiling the SDK myself. I don't think it is too unfeasible to make a new SDK without Revolutions. I was actually thinking of doing it the other way around to you and cutting out all the code commented as Revolutions. Your approach might be cleaner. I think we should be very careful that the Dune Wars specific code by koma, david and cephalo stays as it is (which it sounds like you are doing).

Getting rid of the Revolutions stuff would be worthwhile just to be free of the clutter, but I still think we want JCultureControl, Mountains Back to Service, and a few others.

Do people want Dale's Combat Mod? I'm a bit indifferent about it myself.

As I said before, cutting out the Revolutions stuff out of 1.7.3.1 might be more feasible. Not sure.

If you get a working version that can play a fair number of turns autoplay, then post a link and we can try it out.

i cant help my self, i feel like doing something for the mod

That is understandable. You created the first Dune Wars after all. There are other easier and probably more fun ways to contribute as well as merging the SDK though...

I note we seem to have lost whatever changes we had that made the AI unload transports instantly, many times in game I am able to destroy transports on land tiles.
It is possible I suppose that the transports are still en route to some other target city, but its still problematic that they can be destroyed so easily.
Also, this may be entirely unrelated to the various sdk plugin mods we've added.

I guess this is on version 1.7.3.1? Can you or anyone remember a version where this worked? I'm pretty sure this was david's code, but I don't know if it's python or SDK. Either way it shouldn't be too hard to establish why this functionality has gone AWOL.

Blind updating is what got us into this trouble.

I would say that, more specifically, it is making a wrong choice when there is a conflict in the merge. My principle would be to leave code that has been specifically tailored for Dune Wars untouched, even if that means we leave sections what we are merging in out. For example, I had to leave some of TheLadiesOgre's code relatiing to city placement AI out because david has completely rewritten that function for Dune Wars so there is no point bringing it in. If we want our city placement logic to understand terrain health/unhealth then the best way is to write that in ourselves.

 

[Ahriman]

Do people want Dale's Combat Mod? I'm a bit indifferent about it myself.

We have some units with a ranged combat attack, which IIRC comes from this?
It doesn't work very well though here, they seem to miss way more often than their theoretical "accuracy" score would entail.

I guess this is on version 1.7.3.1? Can you or anyone remember a version where this worked? I'm pretty sure this was david's code, but I don't know if it's python or SDK. Either way it shouldn't be too hard to establish why this functionality has gone AWOL.

Yes, though this isn't new. To clarify; it is not necessarily the case that something has broken; my understanding of the code was that the transport was supposed to unload immediately only if it was adjacent to the target city. I can't observe the AI's target always, so its possible that in all the cases I am able to eliminate transports without them being unloaded first, that they were en route to somewhere else, so the unload condition hadn't been met.

I do think I have seen *some* cases of the AI unloading as soon as it hits land.

 

[keldath]

I think we should be very careful that the Dune Wars specific code by koma, david and cephalo stays as it is (which it sounds like you are doing).

yes, im being 120% carefull, i checked each file i merged twice to make sure i havnt missed a single line, cause david and the others worked very neatly, and marked out all the parts, all you have to do is search for - koma, david, cephalo or dune, so its easy. in one of the earlier versions 14-5, i have compared dune code to vanilla and marked every dune change the guys did, cause due to past experience (been merging files since warlords), its a must do - know your changes .
so im doing the best i can not to miss anything, even though it consumes a lot of time.

Getting rid of the Revolutions stuff would be worthwhile just to be free of the clutter, but I still think we want JCultureControl, Mountains Back to Service, and a few others.

offcourse, we use though two and j improvement code in dune, so they stayed in as well.

as for dale - for my self i can say that i only used ranged bombardment, thats fun, but, bts has a nice ranged mechanism built into it, so we can use this one easily.
again, i going with the clean code theme.

revolution have a lot of stuff in it - many python files, xml that dune just dont need, so, i think the best thing is to get rid of all the extra baggage we are carrying...

and sure, once i will complete the process, and test it, ill upload a link for you guys to do a second test.

That is understandable. You created the first Dune Wars after all. There are other easier and probably more fun ways to contribute as well as merging the SDK though...

well, been away from active civing, but im kinda back (since i started to play mp game with a friend on my overlord 2 mod.
so maybe there's something more i can do, but the sdk thing, is like a bug that's sits on me


the city code david replaced - yeah i saw it - and i left the original marked out , just to remind in the future that david rewrote it.

 

[Deliverator]

We have some units with a ranged combat attack, which IIRC comes from this?
It doesn't work very well though here, they seem to miss way more often than their theoretical "accuracy" score would entail.

These are probably the two bits of Dale's Combat Mod, that I've actually been aware of in Dune Wars:

Airbomb Missions
There are five different air-bombing missions for air units. "Airbomb defenses" allows you to bombard plot improvements or city defense percentage. "Airbomb buildings" allows you to attempt to destroy one of the city's buildings. "Airbomb Factories" allows you to attempt to destroy one of the city's production buildings. "Port airbomb" allows you to attempt to damage a ship in the port, with a chance to sink her. "Strategic Airbomb" allows you to attempt to damage the current production project of the city. The airbomb missions are all subject to air interceptions.

Ranged Bombardment allows siege units to bombard in the field (as opposed to only bombarding cities). By selecting the bombard icon you can select whether to bombard units, improvements or cities. As well, bombarding is possible from a range. Thus in Road to War, standard artillery will be able to bombard into adjacent plots, whilst heavy artillery can bombard into plots up to 2 plots away.

Do people like or use the Airbomb missions? The Port airbomb one doesn't really make sense.

From what I read in the DCM thread Accuracy should work as we expect:

A catapult tries to bombard an enemy 1 tile away, it has a 50% accuracy rate, so 1 in 2 times the catapult will miss and thus end up doing no damage to the unit.

From a quick glance at the code, it looks like RevolutionDCM has made a number of modifications to Dale's original version. A few comments pulled from the code:

// RevolutionDCM - only difference to standard city bombardment is to scale back
// bombard damage according to distance from the city.

// Give a reduced chance of range bombarding city defenders by default

// Occasionally give city bombard a better chance at hitting city defenders if the city defenses
// are still bombardable. This produces differentiation from standard bombard that seige also have
// available to them as an option, and compensates range bombard for not lowering city defenses.

// standard odds made worse if greater than one tile out

// RevolutionDCM - change proposal to ranged bombardment. Only collateral damage can be issued.


// Field bombard case. If bombarding from a city, odds of success are reduced
// For the sake of game balance by default.

Whether all these tweaks are documented anywhere but in the code I don't know, but there seems to be more complexity to the implementation of Ranged Bombardment we currently have than I thought.

 

[Ahriman]

Following Deliverator using David's tool on the tech tree, please see attached.

Era values tweaked, and a couple of minor tech cost changes (though nothing major; this could still be done)

All the new techs had classical era, which was messing up offworld trade somewhat.