Dune Wars 1.9 Final Release Feedback

[ChrisAdams3997]

David or Deliverator, do you know if inquisitions was ever fully implemented and functioning? I've found the code placing the button, which we know works fine (mostly - it lacks any help text it seems), but there doesn't seem to be any actual connection linking the button to the rest of the inquisitions python. It just uses a WIDGET_GENERAL which doesn't help me much. Most widgets point to some spot in the dll where it tells the game to "do" something. I've got no idea what, if anything, the button is telling the game engine.

Now, I'm a C++ modder and python stuff always looks chaotic and a bit harder to follow to me (DuneWars.py is a pleasant exception to this ). If I have my way, I'd just merge in the RevDCM inquisitions code and just ignore the python modules, but I don't want to jump the gun and do all that work if there is a simple fix using the existing code.

 

[God-Emperor]

The functioning of the button is linked to the "665, 665" part of the data for the button when it is set up in CvMainInterface.py.

The numbers are used in the handleInput function in the same CvMainInterface.py to determine what button was pushed.

The handleINput function then sends the modNetMessage with a message ID of 691 (and some additional data) when it encounters that particular pair of numbers in the data it gets.

Every modNetMessage should be handled in an event manager somewhere. BUG allows multiple handlers in multiple files to be registered for any event. There is one registered in InquisitionEvents.py that deals with message ID 691. That should be where the magic happens, assuming that BUG is loading that file and therefore getting that event handler for the mod net message registered.

 

[davidlallen]

Deliverator will have to answer. The inquisitor code is part of RevDCM. The RevDCM team rewrote this code at one point to move it from python to C++. After that, deliverator merged parts of the RevDCM code into DW. Possibly this broke at that time; or perhaps this code was tricky and some other DW change after that lost a key link in the code chain.

 

[ChrisAdams3997]

The functioning of the button is linked to the "665, 665" part of the data for the button when it is set up in CvMainInterface.py.

The numbers are used in the handleInput function in the same CvMainInterface.py to determine what button was pushed.

The handleINput function then sends the modNetMessage with a message ID of 691 (and some additional data) when it encounters that particular pair of numbers in the data it gets.

Every modNetMessage should be handled in an event manager somewhere. BUG allows multiple handlers in multiple files to be registered for any event. There is one registered in InquisitionEvents.py that deals with message ID 691. That should be where the magic happens, assuming that BUG is loading that file and therefore getting that event handler for the mod net message registered.

Thanks God-Emporer, that confirms some of my suspicions. I'd traced the call to 'Inquisition.doInquisitorPersecution' in InquisitionEvents.py, and figured it had something to do with the modNetMessage ID and the 651 in the button code, but, as I said, I'm a C++ modder and all this modNetMessage, and even worse, EventHandler stuff is all foreign to me.

Deliverator will have to answer. The inquisitor code is part of RevDCM. The RevDCM team rewrote this code at one point to move it from python to C++. After that, deliverator merged parts of the RevDCM code into DW. Possibly this broke at that time; or perhaps this code was tricky and some other DW change after that lost a key link in the code chain.

That's what I'd have thought too, which is why I was so surprised to find no inquisition code in the dll. I've been all over the RevDCM codebase in previous projects and knew more or less what I was looking for, but he didn't bring over the inquisition code. But going back to God-Emperor's post, this is what I found in BugEventManager.py:

# DuneWars
DuneWars.DuneWars(self, "")
#InquisitionEvents.InquisitionEvents(self)

So as he suggested, it's not being registered here. The real question is why it was commented out... It could have been because of a problem that needed fixing, or Deliverator was possibly considering merging the RevDCM inquisition code and therefore disabled it. So I'll have to uncomment it and see what happens.

 

[Deliverator]

That's what I'd have thought too, which is why I was so surprised to find no inquisition code in the dll. I've been all over the RevDCM codebase in previous projects and knew more or less what I was looking for, but he didn't bring over the inquisition code. But going back to God-Emperor's post, this is what I found in BugEventManager.py:

I think, from memory, this might be to do with the fact that I rebuilt Dune Wars 1.9.1 on Better BUG AI rather than RevDCM. Re-implementing Inquisitions using my adapted version of OrionVeteran's Inquisitions Mod was on my to-do list, but it seems never got to-done in the BBAI version. I think I got side-tracked into other things like making multiplayer work.

I think my working adaptation of Orion's Inquisitions is in one of the relatively recent versions of Dune Wars, perhaps 1.9 itself. I'll take a look when I get a chance.

 

[ChrisAdams3997]

Thanks Deliverator, if you find it let me know. I'm working on getting the new patch out in the next week and I'd like to cross that off the list .

Chris

 

[ChrisAdams3997]

I've been plugging at the zeal promo tags (deciphering the maxCombatStregth() function that adds up all the combat bonuses was tougher than I expected) and should have them implemented and working. The whole thing was in a very half finished state and I had to write most of it from the bottom up (other than adding the tags).

ForeignPlotModifier:

This one works mostly like you'd expect, if you're on foreign owned soil, you get x% combat bonus (attack and defense). The other caveat I've put in is that on unowned plots where enemy culture (culture of civs you are at war with) is greater than 1/3 of total culture and greater than your team's culture in the plot it still applies.

This is so if you burn down a city, you don't suddenly lose the bonus on those plots no longer covered by the enemy civ.

ForeignCityModifier:

This bonus applies to attacking and defending cities where enemy culture is greater than 30%. As the amount of enemy culture in the city goes up, so does the amount of the bonus, up to the max. I've made a significant change from how this was original coded (which was never finished of course). That 7% at zeal 2 from before would have given up to a 70% bonus as it was multiplied by (enemy culture/10)... (100/10)*7 = 70% max bonus. This was a little illogical.

Now the xml value represents the maximum bonus (given 90% or more enemy culture), and drops linearly as your culture increases, until the bonus becomes 0 when enemy culture reaches 30% or lower. It may sound complicated reading this (since I'm going into the technical side of it), but in practice it's very simple - the more enemy culture, the more bonus they get. Plain and simple.

The thing I'm worried about is it becoming too powerful for defending occupied cities with high enemy culture. So it's possible (given testing) I need to cut the bonus in half for defending. Zeal promoted units should be first and foremost all about attacking and conquering, let others hold it afterwards. Though they should still be well motivated to defend what they've recently conquered.

I've also rebalanced the zeal promos' bonuses a bit, and worked on the ai values for choosing it (which will probably need more tweaking after getting some testing in).

Here is the current setup for the promos:

Spoiler :

<PromotionInfo>
	<Type>PROMOTION_ZEAL1</Type>
	<Description>TXT_KEY_PROMOTION_ZEAL1</Description>
	<Sound>AS2D_IF_LEVELUP</Sound>
	<TechPrereq>TECH_FANATICISM</TechPrereq>
	<iAttackPercent>10</iAttackPercent>
	<iDefensePercent>-10</iDefensePercent>
	<iForeignCityModifier>25</iForeignCityModifier>
	<iForeignPlotModifier>7</iForeignPlotModifier>
	<UnitCombats>
		<UnitCombat>
			<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
			<bUnitCombat>1</bUnitCombat>
		</UnitCombat>
	</UnitCombats>
	<Button>,Art/Interface/Buttons/Promotions/Combat1.dds,Art/Interface/Buttons/dunepromoatlas2.dds,1,3</Button>
</PromotionInfo>
<PromotionInfo>
	<Type>PROMOTION_ZEAL2</Type>
	<Description>TXT_KEY_PROMOTION_ZEAL2</Description>
	<Sound>AS2D_IF_LEVELUP</Sound>
	<PromotionPrereq>PROMOTION_ZEAL1</PromotionPrereq>
	<TechPrereq>TECH_DIVINE_MANDATE</TechPrereq>
	<StateReligionPrereq>RELIGION_MAHDI</StateReligionPrereq>
	<bMustMaintain>1</bMustMaintain>
	<iAttackPercent>8</iAttackPercent>
	<iForeignCityModifier>35</iForeignCityModifier>
	<iForeignPlotModifier>5</iForeignPlotModifier>
	<UnitCombats>
		<UnitCombat>
			<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
			<bUnitCombat>1</bUnitCombat>
		</UnitCombat>
	</UnitCombats>
	<Button>,Art/Interface/Buttons/Promotions/Combat1.dds,Art/Interface/Buttons/dunepromoatlas2.dds,2,3</Button>
</PromotionInfo>
<PromotionInfo>
	<Type>PROMOTION_ZEAL3</Type>
	<Description>TXT_KEY_PROMOTION_ZEAL3</Description>
	<Sound>AS2D_IF_LEVELUP</Sound>
	<PromotionPrereq>PROMOTION_ZEAL2</PromotionPrereq>
	<TechPrereq>TECH_PRESCIENCE</TechPrereq>
	<StateReligionPrereq>RELIGION_MAHDI</StateReligionPrereq>
	<bBlitz>1</bBlitz>
	<bMustMaintain>1</bMustMaintain>
	<bOffensiveVictoryMove>1</bOffensiveVictoryMove>
	<iAttackPercent>7</iAttackPercent>
	<iVictoryHeal>25</iVictoryHeal>
	<UnitCombats>
		<UnitCombat>
			<UnitCombatType>UNITCOMBAT_MELEE</UnitCombatType>
			<bUnitCombat>1</bUnitCombat>
		</UnitCombat>
	</UnitCombats>
	<Button>,Art/Interface/Buttons/Promotions/Combat1.dds,Art/Interface/Buttons/dunepromoatlas2.dds,3,3</Button>
</PromotionInfo>

I'm trying to make this worthwhile to take in lieu of the CityRaider promo line that IMO competes with it. It needs to have a different feel from it and reasons to choose it over CityRaider that just anybody can get. Any thoughts on this are welcome.

After I add in the text for the tags and run a quick play test to make sure I didn't bring in any obvious crashes , I'd like to release a 1.9.4 beta (to check that it's all working like I think it is before the true 1.9.4 release) in the next day or two, so keep your eyes open .

Chris