Hi Keldath, Good to hear from you. :)

I don't have particularly strong feelings about merging in RevDCM either way, but I'm not especially convinced that it is worth it since we don't use any of the Rev features. There is always I risk that doing this kind of merging can create the kind of issues we had with the Multiple Production modcomp. I think it might be better to consider Dune Wars branched off from RevDCM and only cherry pick the changes and fixes that interest us, rather than keep automatically updating when new versions are released.

I think it might be better to consider Dune Wars branched off from RevDCM and only cherry pick the changes and fixes that interest us, rather than keep automatically updating when new versions are released.

I agree. If there is a compelling feature we want, we can update. Otherwise the risks of bug introduction seem to outweight the potential benefits.

Is there anything particularly useful in the latest version?

It would also be great if someone could merge in embryo's post 999 fix.

yeah i know d,

im not to fond of the rev stuff,
i merged it mainly for ai 0.84, and new bug/

also theres some usfull new tags there - like ciivic preq for units, and some more.

i leave it to your decision guys, i just felt like doing it ..you know :)

After some searching, I found the release note for revdcm 2.71 here (http://forums.civfanatics.com/showthread.php?t=262937). Previously we had 2.6; the version was updated in DW 1.7 and the details are here (http://forums.civfanatics.com/showpost.php?p=8725093&postcount=15). It seems that 2.71 makes multiplayer "better" but it is still not really working. That would be a "killer app" worth updating for.

Let's stay with 2.6 for now; but when we decide to move to 1.8 it may be worth considering.

I will add embryodead's three lines into the dll and post an update, probably 12 hours from now. I guess that will be 1.7.2.4. I'll include the source code in that too, so it doesn't get out of sync.

I'll also look into the dynamic tech tree stuff. The other alternative is to spread out the X coordinate of the techs. Your tree is very densely packed and contains many branches, so the routing problem is hard. Individual line overlaps can often be solved by making sure that all the destination techs are at the same x position, and sometimes by moving a tech up or down by one. However, in a very dense tree, there isn't enough room for that.

Of course, simplifying the tech tree by deleting a number of mid-game techs would make the routing easier also.

Of course, simplifying the tech tree by deleting a number of mid-game techs would make the routing easier also.

I think that the visuals of arrows are relatively unimportant compared to the gameplay consequences of actual techs.

Which techs do you consider candidates for removal? I don't think there are too many obvious ones, Deliverator has removed or merged many of the less interesting techs already.

I don't have any specific candidates, I was just observing that the tech tree looks very dense and complicated.

I'll also look into the dynamic tech tree stuff. The other alternative is to spread out the X coordinate of the techs. Your tree is very densely packed and contains many branches, so the routing problem is hard. Individual line overlaps can often be solved by making sure that all the destination techs are at the same x position, and sometimes by moving a tech up or down by one. However, in a very dense tree, there isn't enough room for that.

I know the current tech tree is a bit cramped, but with NeseryozniyVET's algorithm there is zero crossover and it looks pretty good I think. Spreading out along the X-axis is a possibility I suppose, but I'm not sure you'd be able to fix the crossovers that way. We could introduce vertical scrolling and more rows as some mods have done, but I'm not a huge fan of that either. Overall I think using NeseryozniyVET's algorithm is not a bad solution.

Yes, the tech tree is fairly dense around the middle, but I don't think it is too complicated. We aiming to keep gameplay interesting throughout the entire course of a game. The number and progression of techs needs to be considered separately from the cosmetic presentation of them in the tech tree in my opinion.

I was just observing that the tech tree looks very dense and complicated.

I think this is a good thing. Lots of flavor, lots of strategic options, lots of replay value.

One of my tech-tree design goals was to have something different from vanilla, which tends to force you into getting roughly the same techs in the same order every day.

A couple things I noticed:

Wind turbines produce more minerals that mines, and can be built on hills (I'm pretty sure I saw the icon there, at least), so it doesn't seem worthwhile at the moment to even build mines at all except for special resources. (Unless wind turbines could be built on hills before the patch as well, in which case it's still an issue that I missed.) Were you going to switch turbines to be a more commerce oriented improvement, and make them hills only?


Fremen still don't get mysticism starting out. I remember reading that you were going ot do this, and I'm guessing you probably will in the future, but this post will just point this out to make sure.


The new religion buildings aren't in the civilopedia religion articles. They are elsewhere in there, and as far as I know they work fine, but adding them might be useful for a future patch to keep things updated for people who aren't paying complete attention.

Wind turbines produce more minerals that mines, and can be built on hills (I'm pretty sure I saw the icon there, at least), so it doesn't seem worthwhile at the moment to even build mines at all except for special resources. (Unless wind turbines could be built on hills before the patch as well, in which case it's still an issue that I missed.) Were you going to switch turbines to be a more commerce oriented improvement, and make them hills only?

Turbines and solar plants weren't really getting much play before.
Under the new system, yes it is intended that you dont' build mines except on bonus resources, and that you use windtraps or turbines on mesa, and then cottages or solar plants on flat, and then mines on bonuses.
You can also build mines on mesa as a short-term change before you get the turbines tech.

Turbines used to be flatland only, and tended to be dominated by solar plant + cottage mix. The logical argument is; there is wind on mesa tops (for turbines), and shelter in sinks (for solar plants)

I don't want to make turbines commerce oriented, because that detracts from cottages. Cottages and spice should be the main commerce providers.

Fremen still don't get mysticism starting out. I remember reading that you were going ot do this, and I'm guessing you probably will in the future, but this post will just point this out to make sure.
They *did* in one of my files, I guess that change got lost in the merges?
Leaderhead file from http://forums.civfanatics.com/showpost.php?p=9000630&postcount=954 had that change.
Intention was that Fremen start with Mysticism and Desert survival, but still also start with a (single) Fremen scout (they can't build more until they get Exploration tech).

The new religion buildings aren't in the civilopedia religion articles. They are elsewhere in there, and as far as I know they work fine, but adding them might be useful for a future patch to keep things updated for people who aren't paying complete attention.
We should do that eventually, once we are satisfied with our "third tier" religion choices for each religion.

Let's see how many different patches we can get going at one time. I had added embryodead's AI change for spice palaces in 1.7.1.2. He pointed out that it wasn't quite complete and suggested three more lines to add in the sdk code. I have incorporated that change. I guess this will have to be 1.7.1.3. I have lost track of which 1.7.2.x patches it may be compatible with; some of the patches use "spice corporations" and some use "spice palaces". This is compatible with any patch using "spice palaces".

The patch contains only cvgamecoredll.dll plus all of the source files changed since 1.7.

In related news, I have looked into the dynamic tech chooser. In order to make it work, only one small change to Dune Wars/assets/config/init.xml seems needed. When I load the mod using the dynamic tech chooser, I get errors about a missing function resetTechPrefs and about parsing init.xml at lines 114 and 115. The init.xml at lines 114 and 115 is calling resetTechPrefs, so these two problems are related. In your init.xml you can find the lines (the line numbers could be different):

<event type="OnLoad" module="CvTechChooser" function="resetTechPrefs"/>
<event type="GameStart" module="CvTechChooser" function="resetTechPrefs"/>

I commented out those two lines (xml commenting is <!-- and --> but you knew that). It seems to work fine. So I guess you can replace CvTechChooser once you make this small change in your init.xml. I tried it a little, and it seems to work fine.

It would be great if the first post in this thread included all the incremental patches or at least a link to the post for them.

Thanks for the suggestion. This thread is to facilitate interchange of temporary results between the developers. You are welcome to try out these patches and give us feedback; but the point is that these are not mainstream, documented, tested releases. When we have a release which is ready, it will be posted in the welcome thread and the download database.

The large number of techs may seem overwhelming at first, but after a few games and some time studying it, it is fine. I went most of a game without getting mysticism and the following techs and still did fine. I prefer more techs to less (Final Frontier), though each having a purpose and weight can make up for a shortfall.
It forces a choice between various technologies that improve infrastructure, buildings, and other stuff versus getting a high tech war machine (that you may not be able to support without the right infrastructure).
I quite enjoy playing and most of the time having tech to trade for with the AI, that never happens in other games, such as Fall From Heaven (and it's mods, which bugs the hell out of me). Being the technological leader is fun, but the challenge of keeping up is better.

And of course, all from my view.

Installed David's patch from post 1011.

Now I get a ton of python errors when trying to start a game.

AttributeError: DuneWars instance has no attribute 'dFreshl'

AttributeError: DuneWars instance has no attribute 'dSandU'

AttributeError: DuneWars instance has no attribute 'iBwine'

And then: (attached)

Python error log:

Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 246, in onImprovementBuilt
File "DuneWars", line 443, in Initialize
File "DuneWars", line 436, in GetCheckInfo
File "DuneWars", line 671, in DebugPrint
IOError: [Errno 13] Permission denied: 'c:\\stats.csv'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 249, in onImprovementBuilt
AttributeError: DuneWars instance has no attribute 'dFreshI'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 372, in onUnitCreated
File "DuneWars", line 739, in FremenPromotion
AttributeError: DuneWars instance has no attribute 'dSandU'
Traceback (most recent call last):
File "BugEventManager", line 361, in _handleDefaultEvent
File "DuneWars", line 339, in onGameStart
File "DuneWars", line 322, in onGameLoad
File "DuneWars", line 1579, in ContractStart
AttributeError: DuneWars instance has no attribute 'iBWine'
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 967, in forceScreenUpdate

File "CvMainInterface", line 3283, in updateScreen

File "DuneWars", line 65, in StormDraw

File "DuneWars", line 1460, in StormDraw

AttributeError: DuneWars instance has no attribute 'iUpdateTimer'
ERR: Python function forceScreenUpdate failed, module CvScreensInterface

Installed David's patch from post 1011. [...]
File "DuneWars", line 671, in DebugPrint
IOError: [Errno 13] Permission denied: 'c:\\stats.csv'

This has happened to you before, but the files in post 1011 cannot be responsible. The function DebugPrint has gotten turned back on. This is in the DuneWars.py python file, and there is no python in the files I posted. Please edit DuneWars.py to work around this by adding the line in red:

# Print a debug message to file
def DebugPrint(self, txt):
return
f = open(self.DebugFilename, "a")
f.write(txt + "\n")

Please make sure the line has the exact same white space as the following line, that is, it must start with two tabs. (Cut and paste the previous line and then edit, to make sure.)

Did this.
Try stating a game, during game creation the game freezes and gives (in a separate Window):
Program Execution problem:
This program has encountered a problem and needs to be closed. Do you wish to save a diagnostic file?

Have to End Task BTS.

Python log empty.

I can try reinstalling a clean version if you can't reproduce.

What is 1-7-1-3 installable over? You mentioned in post 1004 you were going to make a 1-7-2-4?

Perhaps we should just make a clean 1-7-3?

You guys could probably make a good use a version control system like Git or Subversion. It'd take care of all code organization, keeping everything up-to-date.

Restarted everything, and it seems to work fine. How bizarre.

You guys could probably make a good use a version control system like Git or Subversion.

Thanks for the suggestion. There is a lot of overhead in setting it up and using it, and it would probably prevent those who are not professional programmers from submitting much. The main problem right now is that I am not putting much time into my patches, so they have some new files but mostly old files, and they do not play together well with deliverator's patches.

Incremental Patch 1.7.2.4

Install Sequence: 1.7 -> 1.7.2 -> 1.7.2.4

Game Changes

+ Include embryodead's fix for the Spice Palaces from david's patch 1.7.1.3

+ Atreides now start with Exploration, Fremen with Mysticism/Desert Survival and a free Scout, as per Ahriman's recent XML changes

+ Laza Tiger no longer replaces Master Guardsman, now has national limit 5, still only available to Corrino. Added penalty versus Suspensors (they already have penalties to City Attack and Defense)

+ Included NeseryozniyVET's Dynamic Tech Advisor. Commented out two lines in Config/init.xml as advised.


Art Changes

+ Changed the Main Menu a bit. The moons are now smaller and should no longer flicker on some orbits. I've also added a little slide show of images to help set the Dunish flavour - I plan to add a few more.

+ Reskinned the Water Enviroment backdrop for the Pedia.

+ New Unit Art for Harkonnen Howitzer, Fish Speaker, Laza Tiger, No Ship, Monitor Warship, All Suspensors apart from Carrier

Download Link (http://www.mediafire.com/?mzqguhyviyz)

Edit: You will need to install 1.7.2.5 (http://forums.civfanatics.com/showpost.php?p=9047193&postcount=1030) over this otherwise there will be Python errors.

Nice!
I've been doing a bit of manual testing, I think everything is shaping up very nicely. For ages we worried that a spice economy wasn't strong enough, but from testing I think now a spice economy is if anything stronger than a terraforming economy (for human players); the spice silos make a huge difference, and you don't have the big diplomacy penalties that you get from arrakis paradise civic (because the AI all choose arrakis spice unless forced to do otherwise by Favorite Civic in leaderhead).
I'm wondering if we should reduce the catchbasin penalty down to -2 water, and eventually add some forests that can spawn in sink tiles with a +1h bonus. Terraforming economies can end up mildly hammer-poor, because the grassland produces no hammers.

*edit*
The monitor warship looks like its *buildable* with the Atomics tech. Intention was for it to come only from completing the projects. Is this just placeholder until the Project work is completed?
The graphic looks badass though; I like that its BIG.

*edit*
The monitor warship looks like its *buildable* with the Atomics tech. Intention was for it to come only from completing the projects. Is this just placeholder until the Project work is completed?

Yes, just placeholder. I'm sure I can figure out the Python from looking at the Kwizatz Haderach projects unless david fancies doing it. Also, the Great Convention Breached/Atomics stuff is outstanding.

Also, this line needs to removed from the file DuneWays.py in 1.7.2.4:
self.iBClass = self.GetCheckInfo("BUILDINGCLASS_HOUSE_CORP")

I'm pretty sure this is responsible for all the Python errors you and I have been experiencing. I'll attach the amended file to this post shortly.

I've attached the DuneWars.py fix for 1.7.2.4 to the patch post. Or you can just delete that line from DuneWars.py yourself...

Also, does anyone know how to stop CivilizationIV.ini getting perpertually overwritten. I'm on a different PC to my usual one and I keep having to re-save my settings. Setting it to read-only doesn't seem to work.

awesome work deliverator, i really like the crafts, where did you get the idea for the models?

they are very dunish!

***
on my usual note, i just wanna let you guys know, that ill keep updating dune to revdcm as it goes on the versions (i make test for stability and such) i may not be active on the forum, but every morning i stop by here... so once you guys want to upgrade this (don't forget it has bbai), be sure to tell me and ill upload the mod (its for my own fun..)

keep up the great work...soon this mod will be more fun then dune 2, if its not already is.

Greetings friends. I've noticed that all units have "unitname pedia stub" for their background so I attempted to fix it a bit.

Check the attachment, it has Background info for Laza tigers, Mentats, Slaves and Sayyadinas. If such level of "stub" is ok for you, I will work on other units as well.

P.S. Also "Erron in EndGameTurn event handler ..." error appears every turn even in 1.7.2.4. Do you know how can I fix it by myself before the next patch and which problems may hide within it?

I see that the error causes at least "landing stage" bonuses not to appear for selection.

I get no Python errors in 1.7.2.4 (landing stage worked too), just minor graphical glitches so far: the missing rocket trooper texture is still not included in the patch (though I have it) and CHOAM holy city icon is cut off. EDIT: Also polar rockforms are missing NIFs.

i also had the python error and now its gone with 1.7.2.4, perhaps you did not install the patches currently.

Incremental Patch 1.7.2.5

Requires 1.7.2.4 to be installed first

Install Sequence: 1.7 -> 1.7.2 -> 1.7.2.4 -> 1.7.2.5

+ Fixed remaining Python errors relating to the removal of Spice Corporations

Religion Icons/Gamefont:
+ Fixed CHOAM holy city gamefont
+ Brightened-up Shai Hulud religion icon and gamefont
+ Made Mahdi gamefont background consistent with new icon, still to fix Mahdi building icons

+ Minor fix to Great Processor icon

Download Link (http://www.mediafire.com/download.php?1zymzwtm3iy)

the missing rocket trooper texture is still not included in the patch (though I have it) ... Also polar rockforms are missing NIFs.

Are you definitely installing Patch 1.7.2 before you install incremental patch 1.7.2.4 embryodead?

Both these items were added between 1.7 and 1.7.2, and I have tested with a clean install and can't reproduce your problem... :confused:

i also had the python error and now its gone with 1.7.2.4, perhaps you did not install the patches currently.

Just to clarify, 1.7.2.4 DOES have Python errors. That's why I posted the hotfixed DuneWars.py.

You can now install 1.7.2.5 to make them go away.

It's strange, I've got that "handler" error with a hotfix... I will try 1.7.2.5 now.

What do you think about pedia help I've offered?

It's strange, I've got that "handler" error with a hotfix... I will try 1.7.2.5 now.

Even the hotfix still has errors unfortunately - I'll take it down and point people to 1.7.2.5.

Are you definitely installing Patch 1.7.2 before you install incremental patch 1.7.2.4 embryodead?

Both these items were added between 1.7 and 1.7.2, and I have tested with a clean install and can't reproduce your problem... :confused:

Yes, 1.7, 1.7.1, 1.7.2 and incremental patches - could it be because I installed them by unzipping the exes? (main installer won't run saying I already have DW installed etc.) EDIT: I'll just delete everything and install it normally then let you know.

I am running 1.7.2.4 without the hotfix and without any (obvious?) errors, for a couple of hundred turns.

I haven't looked at your 'Pedia stuff, but any contributions are very welcome and much appreciated.

Shall I take 1.7.2.5 and make it into a 1.7.3 release?

Edit: I have taken 1.7.2.5 and made it into a 1.7.3 release. Since the 1.7.2 release had such a severe bug, and there are at least 6 patches floating around in the last week, I have put up a test version of 1.7.3 at this link (http://www.mediafire.com/download.php?mnkmjymmzmi). No matter which patches you have installed or not, this one should go over it and fix everything. It contains all the files which have been touched since 1.7. The file size is 10 MB.

If several people can confirm that this is working for them, then I will announce it.

main installer won't run saying I already have DW installed etc.

I am not familiar with this problem. When the main installer detects a previous version, it does not prevent you from re-installing. What goes wrong for you when you just tell the installer to continue?

Has anybody else experienced a similar problem?

Just to clarify, 1.7.2.4 DOES have Python errors. That's why I posted the hotfixed DuneWars.py.

You can now install 1.7.2.5 to make them go away.

i know, i had them before your fix.

thanks guys.

Shall I take 1.7.2.5 and make it into a 1.7.3 release?

Edit: I have taken 1.7.2.5 and made it into a 1.7.3 release. Since the 1.7.2 release had such a severe bug, and there are at least 6 patches floating around in the last week, I have put up a test version of 1.7.3 at this link (http://www.mediafire.com/download.php?mnkmjymmzmi). No matter which patches you have installed or not, this one should go over it and fix everything. It contains all the files which have been touched since 1.7. The file size is 10 MB.

If several people can confirm that this is working for them, then I will announce it.

Is it too late to ask you to remake 1.7.3 with this new version of DuneWars.py? I have added the functionality for the Monitor Warship projects and the Great Convention Breached wonder. This pretty much completes the tech tree rework (although there is polishing required).

In addition to using this updated DuneWars.py, the PrereqTech for the UNIT_MONITOR_WARSHIP in unit infos needs to be set to NONE so that it cannot be built by conventional means.

Eh, it's a bit dumb to ask it for the third time, but nobody seems to notice my main question. Is anybody working on Pedia stubs or can I do it freely?

Eh, it's a bit dumb to ask it for the third time, but nobody seems to notice my main question. Is anybody working on Pedia stubs or can I do it freely?

Go for it, Deon. No-one else is doing any stuff to the pedia at the moment as far as I know. It would be good to get more content fleshed out as we have added/changed quite a few units, buildings and techs recently.

Also, we have a pedia thread (http://forums.civfanatics.com/showthread.php?t=342258) that we can use for pedia-related discussions just to keep this thread about patches and releases.

Thank you, I missed it. I will post updated text files there then.

Let's get confirmation that this 1.7.3 has no painful bugs. I can add other simple stuff into it, such as your python and the new pedia text by Deon. Once we get confirmation, then I will release it.

I approve the info that 1.7.2.5 plus the fix for Monitor Warship posted by Deliverator work fine for me and there're no more errors. Thank you very much.

Gave the 1.7.3 beta a quick test and all looks good. Both the AI and I were building spice harvesters. Spice palaces work fine. All art looks as expected.

Wait, I can build monitor ships right away. What else should I change to disallow it?

I am not familiar with this problem. When the main installer detects a previous version, it does not prevent you from re-installing. What goes wrong for you when you just tell the installer to continue?

Has anybody else experienced a similar problem?

Well, now that I clicked OK I see you're right, but the installer is rather confusing. When I run it I get this popup: "Dune Wars is already installed. Do you wish to uninstall? OK/Cancel". Clicking cancel exits the installer; when I clicked OK... it installs the mod :crazyeye:

With 1.7.3 installed the normal way - the art files I reported missing are all in place. If I install the same patch manually by unzipping - they are missing. That will teach me to use EXEs only, but it's weird. Sorry for the trouble.

I think there's one side-effect to my fix, if so, sorry for the trouble again :p It seems the AI values the spice too high in the trade window - I don't know how much it was ready to pay for it with corps, but I can get 1 luxury or health resource for 1 spice, or 6gp/turn (probably more, that was all the AI had at that point). Doesn't affect the AI but it's abusable by human player, I guess. The AI should not be happy to pay more than 3-4gp/turn - matter of fine tuning the values to make sure it's about that number (which I can do).

When I run it I get this popup: "Dune Wars is already installed. Do you wish to uninstall? OK/Cancel".

I have thought that this is a bit confusing myself. Often I will rename my current Dune Wars folder to keep it from being overwritten, then, when I run the installer, I get this popup even though (technically) Dune Wars is no longer installed due to the renaming.

Deliverator, can you comment on the Monitor Warship issue please? :)

When I run it I get this popup: "Dune Wars is already installed. Do you wish to uninstall? OK/Cancel". Clicking cancel exits the installer; when I clicked OK... it installs the mod :crazyeye:

Yes, the installer is from phungus420. I do not understand the technology, I just edit some variables in his "nullsoft installer script" and run it. Supposedly, if you have a previous version installed, it should delete it. I think the installer adds a registry key which says whether the mod is installed, rather than looking at files. I don't think I can fix this, and phungus420 doesn't have much time/interest to spend on the installer.

I think there's one side-effect to my fix, if so, sorry for the trouble again :p It seems the AI values the spice too high in the trade window - I don't know how much it was ready to pay for it with corps, but I can get 1 luxury or health resource for 1 spice, or 6gp/turn (probably more, that was all the AI had at that point). Doesn't affect the AI but it's abusable by human player, I guess. The AI should not be happy to pay more than 3-4gp/turn - matter of fine tuning the values to make sure it's about that number (which I can do).

If you are going to tweak something, there are suggestions by orlanth a few posts back (http://forums.civfanatics.com/showthread.php?p=8956217#post8956217). As a human player, I can't imagine a situation where I would trade something to get spice; so perhaps the AI should just never offer or accept it.

If you are going to tweak something, there are suggestions by orlanth a few posts back (http://forums.civfanatics.com/showthread.php?p=8956217#post8956217). As a human player, I can't imagine a situation where I would trade something to get spice; so perhaps the AI should just never offer or accept it.

I remember reading the problem with the suggested iAIObjective is that it alters settler AI, making AI want to settle near spice. For tweaking I just mean to scale the spice value down with the number of cities, just as it worked with corps.

Just checked the 1.7 version and the AI was willing to buy spice but only for 2 gp / turn - that's about enough to stop the human from trading it.

Tested on the same Atreides PYL WBSave 200 turns. Harvesters are built like before, but the AI will only pay 2-4gp/turn for spice (it's a straight copy of corp formula now).

EDIT: disregard this and just change the iAiTradeModifier for spice in the CIV4BonusInfos.XML to -100, that's simple and stops spice from being traded altogether, without affecting harvesters.

In addition to using this updated DuneWars.py, the PrereqTech for the UNIT_MONITOR_WARSHIP in unit infos needs to be set to NONE so that it cannot be built by conventional means.

But NONE will make it avaliable from the start.

For some reason my monitor warships are unable to attack cities. Is it supposed to be so and why?

I definitely think the best solution for Spice is to have the AI never trade it away or trade for it. Is that possible? Too easy to exploit otherwise, by selling above its value or below its value.

Monitor should be able to attack cities. A bunch of thopter and suspensor units have had a cannot attack cities tag activated by accident. I haven't tested in latest versions which ones still have the problem.

But where is it? I see no arppropriate tag in XML. It can freely destroy enemies around a city but cannot get those inside of the city.

A bunch of thopter and suspensor units have had a cannot attack cities tag activated by accident. I haven't tested in latest versions which ones still have the problem.

I don't think the problem is as simple as activating a "cannot attack cities" tag in the xml. Which specific tag do you have in mind? I think for some reason, no DOMAIN_SEA unit (thopter, suspensor) cannot attack cities. This has to be related to all terrain units somehow, but I am not sure how. Offhand, I think something may have gone wrong in the 1.7 merge to new versions of BUG and RevDCM. I am pretty sure that every "sea" unit, in every version since 1.7, has had this problem, but I have not confirmed it.

I don't think the problem is as simple as activating a "cannot attack cities" tag in the xml

I have no particular evidence on this, I thought you had said it was an xml tag when I mentioned something about the hawk thopter. You are probably correct.

I seem to remember being able to attack cities with thopters at some point in the past at least, so I think this has been somewhere introduced along the way.

1.7 seems plausible.

I've confirmed it with several units; suspensor gunship, hawk thopter, suspensor destroyer.

I tried it and all all-terrain units cannot do it. A bit sad heh.

Hm. Does anybody have an archive of pre-1.7, say 1.6.1, to try? I am pretty sure it worked sometime. In 1.7 there was a big merge of RevDCM, etc, and that is the only thing I can think of which may have changed this. One of the all-terrain changes may have been merged incorrectly.

Testing Davids recent 1.7.3 merge patch. Just a few things..
Is it just my install or does the religion screen not display properly now?
Spice as a corporation income no longer displays on my economy screen.

Other than those, the new changes are awesome. I havent tested the vehicles vs cities yet. I was using Hardened Bladesmen for my city attacks.

In 1.7.3 (as in 1.7.1) there are no more spice corps. They briefly re-appeared in 1.7.2. If you hover the mouse over your palace, in the list of buildings in the city screen, you should see spice commerce income based on the number of spice resources you control. Is this working for you?

Units do have an XML tag which can prevent them from capturing a city: the bNoCapture tag, if it is 1 then the unit can not capture a city (it is used by the helicopter gunship unit in regular BtS).

Note that this does not prevent the unit from attacking other units in a city. It can wipe out every unit in the city, it just can't capture the city itself. If you can not attack the units in the city, then having this tag set to 1 can not be the problem.

Thanks for the reminder. The units in question do not have bNoCapture set, so I do not think this is the problem.

Hm. Does anybody have an archive of pre-1.7, say 1.6.1, to try? I am pretty sure it worked sometime. In 1.7 there was a big merge of RevDCM, etc, and that is the only thing I can think of which may have changed this. One of the all-terrain changes may have been merged incorrectly.

The ModDB download page (http://www.moddb.com/mods/dune-wars/downloads) is now a handy archive of old Dune Wars versions.

Edit: I can confirm that you can attack cities with Suspensors and Thopters in 1.6.1.

It looks like some code blocks ships (DOMAIN_SEA) units from entering rival cities at war. I think ships behave in the same way in BtS too, so it's something you've "fixed" and forgot to look after it when you merged RevDCM stuff :).

I am not sure about +3 commerce for a palance per 1 spice resource. I've played 5 or 6 games and didn't try to go an anti-spice route, but I've noticed that with a spice-route you can spam as many cities as you want, because if they grab some more spice, they outpay themselves from the beginning.

Also because it's not :gold: but :commerce:, it means that more spice resources speed up research significally, leaving non-spicers behind.

I think it was not possible to do the same with a "common" economics, and also it means that "polotical" trait (+3 culture/turn) is may be the best trait in the game because your new cities start to bring you spice immediately.

In 1.6.4, I can still attack cities with Suspensors and Thopters. In 1.7, I cannot.

From the 1.7 changelog, one of these two seems most like to have caused this.

Internal changes
* Updated to the latest version 2.61 of RevDCM, version 0.82 of Better BTS AI, and version 4.2 of BUG with version 1.0 of BULL (ported after extensive work by keldath). There are a number of gameplay and interface changes in these. You may easily spot the "Show Hidden Attitude" diplomacy mod and the "Building Actual Effects" city screen mod.
* Added Lead From Behind modcomp (by UncutDragon, merged by keldath)
This is making me increasingly opposed to making any further merges of RevDCM, Better AI or anything else unless there is a really strong reason to do so. Even then I would rather we just merge a small section of relevant code since the mod is now very different to vanilla and we just don't know how wide-ranging changes will affect Dune Wars. As david originally pointed out in this post (http://forums.civfanatics.com/showpost.php?p=8565212&postcount=520), there wasn't really a compelling reason to merge this stuff in the first place, apart from (possibly) the Better BTS AI stuff.

I definitely think the best solution for Spice is to have the AI never trade it away or trade for it. Is that possible? Too easy to exploit otherwise, by selling above its value or below its value.

Sure, and actually it's easier than I thought, disregard my fix from previous post :). Just change the iAiTradeModifier in the CIV4BonusInfos.XML to -100 (was +15 which was actually making the AI pay more). Problem solved. The AI won't give it away and won't pay a dime for it either. Harvesters unaffected.

Yeah, I was quite amazed when I've found the RevDCM as a part of this mod. I really love Revolutions aspect of BtS mods, but I don't think that it can be easily put into Dune universe. It needs a lot of tweaks and "fixes" to follow the Dune feel and ethics, right now it feels to be a bit detached and inconsistent from the whole "polished" stylish content/look of the mod.

hey guys,

following the revdcm discussion, ive been thinking , on making a new fresh dll file, with just the stuff needed for dune.

but i wonder what parts are needed,

do you wish to use the better ai with it full code? or just parts?

and dales code, do we need it also?

Culture control is nice but I find it useful only with "fixed borders" possibility, otherwise cultural influence takes the lands back pretty quickly.

I think culturally influenced war is very good. I think it makes a big difference, when you're fighting and pillaging over a heavily culture-clashing border area.

Political trait is intended to give you more spice (that's kinda the main idea; superior political skills give you more influence over claiming spice quotas), but its one of those traits (like imperialistic) that is fantastic in the early game, but is quickly outclassed. I don't think its too strong.
I can make a pretty good case for almost any of the traits being a "best" trait.

Well, it's "best" because it allows you to grab as much spice as possible and quickly outtech rivals. However at higher difficulties AI gets more bonuses to research and it's not that important anymore.

Aggresive trait is the best because it lets you blitz a nearby opponent in the early game (barracks + aggressive trait means you can instantly get Improved Shields promotion, for +30% strength vs guardsmen).

Philosophical trait is the best because it lets you set up a crazy-powerful specialist economy. Add in Meritocracy, Faufreluches and Water discipline and keep settling great people in place for large bonuses.

Similarly, Financial trait lets you set up a pretty sick Cottage economy; 3 commerce instantly from cottages adjacent to wells. Add in Private Property civic, terraformed tiles, Hereditary rule and get super-cities with huge income.

Imperialist trait is the best because it lets you REx like mad, taking a huge amount of land.

Mechanized trait is the best because it effectively gives 2 free promotions (combat and flanking) to all your suspensors and vehicles, letting you build up an army of quads and suspensor gunships and pillage nearby foes into oblivion.

etc.

Even with Political trait, you still have to have the workers to actually build the harvesters, and if they're doing that they're not building windtraps and dew collectors and wells to grow your economy. And Political trait is pretty much obsolete by the end of the early game.

Just change the iAiTradeModifier in the CIV4BonusInfos.XML to -100 (was +15 which was actually making the AI pay more). Problem solved. The AI won't give it away and won't pay a dime for it either. Harvesters unaffected.

Great, we will put that in at the first opportunity.

I wonder, is it designed that way that the only avaliable mech which does not require Ixian Weaponry is Cymek? Or did you just forget to put the prereq in?

following the revdcm discussion, ive been thinking , on making a new fresh dll file, with just the stuff needed for dune.

but i wonder what parts are needed,


This is a good question. There is some stuff we definitely don't want; some stuff we definitely do want; and some stuff which is debatable.

BUG/BULL seem worthwhile. I was against it at first but I like some of the extra information. That is independent of RevDCM itself.

Super Spies is required, for a lot of the espionage mechanics. I think the new missions are cool but I don't hear much feedback about them.

I *think* that BBAI is very helpful in getting workers to build the right improvements; but also, several parts of our DW-specific code are wrapped around BBAI (all terrain attack; some parts of the BG spy missions) so removing it would be hard anyway.

AIAutoPlay and Change Player are very handy for debugging but they are part of BBAI so integrating BBAI would be sufficient.

To me, influence driven war is debatable. I know Ahriman likes it. I never see any useful effect myself.

A lot of the other stuff like barbarian civs, dynamic civ names, etc. is not really useful for DW.

It is "known" that RevDCM has broken multiplayer, and it is "believed" that BBAI is OK for multiplayer by itself, although there is some debate. Getting back to a build where multiplayer works would make some players happy.

At this point, I am not sure which is harder, removing RevDCM or finding the point bug which has crept in. Perhaps the best approach would be to take the 1.6.5 source code, find the changes which are marked by me, or cephalo as all-terrain related, and make sure all of them are in the 1.7 source code.

I totally support Davidlallen's post from a player's point of view. BUG/BULL is awesome, I simply love how it feeds the important info to me, makes the gameplay easier and more satisfying.

Super Spies is the thing which I don't get why is not included in vanilla BtS. It's a must for me, makes these "spy" units more personalized and adds more immersion. Without it all spies are the same and are worth of nothing as units while with Super Spies you are actually afraid of your high-level spy being caught because you cannot replace it at once.

I don't know anything about BBAI but right now AI is quite good so I guess it's needed :).

IDW is debatable for me too but if Ahriman likes it then it's cool. I don't notice a major impact of it (probably because I tend to lead quick wars) but it's a nice mechanic I like in BtS mods.

Barbarian civs and dynamic city names make no point for me because, well, Dune Wars is not about development of new civs, it's about a struggle of existant ones.

I wonder, is it designed that way that the only avaliable mech which does not require Ixian Weaponry is Cymek? Or did you just forget to put the prereq in?

Yes, intended.

The Cymek is a religious unit for the Technocracy religion; it is actually a cyborg.

Whereas the various other "mech" units are Ixian faction UUs, some of which can also be built by non-Ixians if they trade for the Ixian Weaponry tech. These are vehicles with pilots.

I think the new missions are cool but I don't hear much feedback about them.
I haven't been testing out espionage much.
I have used the Incite Revolt ability, which is nasty because it removes all city defenses for the turn - whicih is of course the turn that I invade it with everything. Its nasty.

The AI never uses any of them against me. The only AI spy actions I ever suffer are the occasional destroyed improvement, which does nothnig in the long-run. And sometimes steal treasury, which takes a small amount of gold (waste of EPs).

I think the problem is: the AI wastes all its EPs on low-value missions, and so never actually gets big enough EP accumulations to use nastier missions.

I wonder if what we should do is remove many/most of the spy missions, really leaving each particular spy with only a small number of missions to choose from, either cheap missions or expensive missions.

So: Saboteurs can only destroy buildings, and are the only ones who can do this, so we can make the Sabotage Building mission cheap.
Split the BG missions into "cheap" missions (the diplomacy influence ones) and "expensive" missions (city takeover, faction-wide anarchy); give the former to a Sister unit, and the latter to the Reverend Mother unit.

We could make a Harkonnen Traitor spy unit, whose only ability was the 1-turn incite revolt

The Facedancers could have poison/plague missions only.

Ecaz could have a steal treasury mission.
Fremen could have some kind of water stealing mission.

As current, Atreides left without, but with superior espionage resistance (through higher EP point income).

I think the advanced espionage options would be more interestnig and flavorful if they were tied more closely to their intended faction, and a narrower scope might make it easier to force the AI to use them.

Cutting away the low-impact missions would be a big help.

To me, influence driven war is debatable. I know Ahriman likes it. I never see any useful effect myself.
Often it can be valuable to engage in "pillage wars", where you don't have the strength to take enemy cities, but go around pillaging their improvements, particularly with quads or thopters or suspensors. Its nice to see this extending your borders into the pillaged tiles - and to have the reverse occur if you over-extend and get your pillaging units destroyed.

I don't care that much though, I wouldn't be that upset if we lost it.

A lot of the other stuff like barbarian civs, dynamic civ names, etc. is not really useful for DW.
Agreed. We had some ideas floating around about getting Jacurutu/water-stealer Fremen, but I can't think of a good way to actually implement it. A couple of barbarian-only Fremnish units would be able to get this flavor across without needing the barbarian civ mechanics.
But barbarians are never going to be a real threat beyond the very early game unless we can make them spawn in desert tiles, or inside cultural borders (eg through event).

At this point, I am not sure which is harder, removing RevDCM or finding the point bug which has crept in.
I don't envy this task, sounds tricky.

The Cymek is a religious unit for the Technocracy religion; it is actually a cyborg.
Yes, I know that Cymek are mechanical bodies controlled by a human brain, I just missed that they require Technocracy religion to be built (is it represented in Pedia?). Thank you for clarifying.

, in the list of buildings in the city screen, you should see spice commerce income based on the number of spice resources you control. Is this working for you?

Ah, yes it does.

RE: Spice

I find spice income is irratic at best as the worms are doing a good job at reminding me its not a steady fixed income. Unless your running serfdom, which I never do if another civic is available, its quite a time investment for workers to rebuild all those harvesters, (playing at epic gamespeed). I haven't found a way to effectively counter them at this stage. I think this is one of the elements that balances out the large value of spice.

Part of why Serfdom is a good civic :-)

If you use Arrakis Spice civic, then you can build Spice Workers, who have high movement and build rate, but can only build harvesters. A couple of those can keep the depredations of worms down to a minimum.

Yeah, with spice workers worms are nothing :).

I wonder if "thumper" promotion does anything.

Please move any general 1.7 game feedback to the 1.7 feedback thread.

<sorry double-post due to internet errors>

At this point, I am not sure which is harder, removing RevDCM or finding the point bug which has crept in. Perhaps the best approach would be to take the 1.6.5 source code, find the changes which are marked by me, or cephalo as all-terrain related, and make sure all of them are in the 1.7 source code.

I think we should release 1.7.3 anyway as planned. The fact that it has taken so long to notice that Thopters and Suspensors can't attack cities proves the mod is playable without that feature, and 1.7.2 is quite nastily bugged. People can always use the Monitor Warship for worm hunting...

Making a new SDK might take some time.

On thopters and suspensors vs. cities: I thought it was a deliberate feature, to represent that these units were open terrain units rather than city attackers.

Though I can see how having a monitor ship not able ot attack cities would be a problem.

On thopters and suspensors vs. cities: I thought it was a deliberate feature, to represent that these units were open terrain units rather than city attackers.

Ah-ha! It is not a bug, it is a feature!

Many units do get a percent penalty on attacking cities. This is a bigger problem, they cannot even target units in cities. This is not on purpose.

This is not on purpose.

I'd gotten this from the previous posts, I was just pointing out how it would not get noticed.

Actually I've noticed it the first game I played. Oh well, whatever :).

Just remove City Raider promotions from those units then please. AI promotes them and wastes promotions.

following the revdcm discussion, ive been thinking , on making a new fresh dll file, with just the stuff needed for dune.

but i wonder what parts are needed,


Perhaps the best approach would be to take the 1.6.5 source code, find the changes which are marked by me, or cephalo as all-terrain related, and make sure all of them are in the 1.7 source code.

I think that making a fresh DLL is going to be far harder. I'm fairly sure we have other modcomps like Mountains Back to Service (used for Mesa) and JCultureControl (which I think we use for something - can't remember what). Also, it is arguably only the Revolutions part of RevDCM that we don't want - I guess we'd still want the Dale's Combat Mod part for airbombing and artillery options.

Comparing 1.6.5 with 1.7.3 code, the function CvUnit::canMoveInto seems like the most likely issue. There are a few tweaks there that I could see causing issues for units with DOMAIN_SEA like the Thopters and Suspensors.

I have managed to build my first vanilla SDK, so I am currently attempting to build my first Dune Wars one to test the theory by rolling back just this function.

Sounds very promising, good job.

Mmmm. Doesn't seem to be that one, even with that function rolled back to how it was in 1.6.5 I still can't attack cities with Thopters. I figured it had to be something in CvUnit because that is where the code that decides whether a unit can attack or move seems to be, but now I'm a bit stumped.

Well, I've eliminated the possibility that it is anything to do with CvUnit:canMoveInto at least. Even if I stub it out like this...

bool CvUnit::canMoveInto(const CvPlot* pPlot, bool bAttack, bool bDeclareWar, bool bIgnoreLoad) const
{
return true;
}

... my thopters still can't attack cities. Will continue hunting tomorrow... if anyone has any suggestions let me know as I'm completely new to this code. I still have a feeling it is either to do with a change to DOMAIN_SEA units or canMoveAllTerrain units.

At least I've learned how to compile my own DLL this evening. :)

No closer to finding the problem. I have asked for some pointers on the SDK forum.

I have however further diagnosed the problem. The Thopters/Suspensors cannot even enter an undefended enemy city, so it is not specifically to do with attacking.

DOMAIN_SEA units cannot capture an enemy city, even if the city has no defenders. My guess would be a change related to naval bombardment is the culprit for why thopters and suspensers cannot attack a city. Hope this helps.

Gotcha. The methodical approach has yielded fruit in the end...

Basically, this rather crucial bit of logic from koma that determines whether a group is attempting an amphibious assault...

bool CvSelectionGroup::isAmphibPlot(const CvPlot* pPlot) const
{
bool bFriendly = true;
CvUnit* pUnit = getHeadUnit();
if (NULL != pUnit)
{
bFriendly = pPlot->isFriendlyCity(*pUnit, true);
}

// Dune Wars Mod Transporter koma13 START
//return ((getDomainType() == DOMAIN_SEA) && pPlot->isCoastalLand() && !bFriendly);
return ((getDomainType() == DOMAIN_SEA) && pPlot->isCoastalLand() && !bFriendly && !(pUnit->canMoveAllTerrain()));
// Dune Wars Mod Transporter koma13 END
}

...has been replaced with this...

bool CvSelectionGroup::isAmphibPlot(const CvPlot* pPlot) const
{
bool bFriendly = true;
CvUnit* pUnit = getHeadUnit();
if (NULL != pUnit)
{
bFriendly = pPlot->isFriendlyCity(*pUnit, true);
}

// Dune Wars Mod Transporter koma13 START
//return ((getDomainType() == DOMAIN_SEA) && pPlot->isCoastalLand() && !bFriendly);
//this is koma's line: disabled for now
//return ((getDomainType() == DOMAIN_SEA) && pPlot->isCoastalLand() && !bFriendly && !(pUnit->canMoveAllTerrain()));
// Dune Wars Mod Transporter koma13 END
//return ((getDomainType() == DOMAIN_SEA) && pPlot->isCoastalLand() && !bFriendly && !canMoveAllTerrain());

if (getDomainType() == DOMAIN_SEA)
{

if (pPlot->isCity() && !bFriendly && (pPlot->isCoastalLand() || pPlot->isWater() || canMoveAllTerrain()))
{
return true;
}
return (pPlot->isCoastalLand() && !bFriendly && !canMoveAllTerrain());
}
return false;
}

I've reverted this back to how it was in DW 1.6.5, plus I've reverted a few other bits of koma's logic that looked like they got overwritten just to be on the safe side. Thopters and Suspensors can now not only attack, but also capture cities. Hurrah.

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. :)

Incremental Patch 1.7.2.6

Install Sequence: 1.7 -> 1.7.2 -> 1.7.2.4 (http://forums.civfanatics.com/showpost.php?p=9045517&postcount=1021) -> 1.7.2.5 (http://forums.civfanatics.com/showpost.php?p=9047193&postcount=1030) -> 1.7.2.6

+ Thopters and Suspensors can attack and capture cities again!

+ Monitor Warship can no longer be built conventionally - you must build the 5 Monitor Projects then it will appear in your capital city.

+ Building the Great Convention Breached! Wonder now gives 3 Atomics in your capital city.

+ CHOAM Headquarters weakened, now only provides +2 commerce per Spice.

+ The iAITradeModifier has been set to -100 for the Spice to stop the AI doing any trades involving spice.

+ Fixed Main Menu slide show and added 3 new slides

Download Link (http://www.mediafire.com/download.php?zb1rn0jwdm1)

Hopefully david will be so kind as to bag this up as 1.7.3 soon...

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.]

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.

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.

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.

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.

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 (http://forums.civfanatics.com/showthread.php?t=333969) (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:
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 (http://www.mediafire.com/download.php?zyyjk41in4i)

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.

I concur

Ok. The attached files include the following changes:


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.

@ 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.

@ 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

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.

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.

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.

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.]

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, 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.

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.

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.

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, (http://forums.civfanatics.com/showthread.php?t=257210) 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.

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.

dont worry, i can merge dales code without a problem - ive checked some mods that imported dales code with the revolution modifications without revolution stuff.
(merged mod for example). that why i wrote that i can add dales code easily.
plus i have the original dales code for 3.19.

merging dale is my specially :)

yeah some of the missions are not in use.
the accuracy - well that's a feature that i really like.

ok then ill put it in.

another thing,
i see that david wrote some stuff ontop of super spies, espionage diplomacy and another, so i think we need this part too.

Do people like or use the Airbomb missions?

I use the airbomb terrain mission, as does the AI. If you don't have interceptors up, your improvements can get blown away by bombers.

I think bombers are already very good, so I wouldn't cry if we lost them.

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.
Weird changes, it really seems designed for a bombard system beyond our purposes.

I don't mind losing bombard, but we might then rework the siege units without it. I think we already have some rework issues; the AI (correctly) recognizes that rocket launchers and missile launchers are often better than shield troopers.

I rarely see many shield troopers, the AI tends to use vehicles, guardsmen and siege units instead.

I suspect though that this is a mix of tech cost issues (shield troopers have a lot of pre-req techs to get through) and maybe too much city attack bonus on the siege units.

In short, we could lose the DCM ranged bombardment, I don't think it works well for our purposes and it is quite complex.

*edit*
If Keldath likes it we should keep it; I'm happy to defer.

i see that david wrote some stuff ontop of super spies, espionage diplomacy and another, so i think we need this part too.

Yeah, super spies we definitely want. We are discussing some changes to espionage units in the civs thread.

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

Cool. Thanks.

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

I recall that in 1.7.2.1 I integrated your changes to add religion flavors to the tech tree, but that was not in 1.7.2.2. Are the religion flavors in the current tech file? If not it may be worthwhile to re-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.

This is why I write detailed release notes. Please see this comment in 1.7.1:

+ In the 1.7.0.2 patch, I added a capability for the AI to unload transports on land if there is any threat; but it frequently causes a hang, so this is removed from 1.7.1.

The original code by Sephi is very simple. Please see this post (http://forums.civfanatics.com/showpost.php?p=8727378&postcount=28) and the following discussion. In order to reduce the changes to header files, I put the code in a different place than he suggested, and my change did not work. I never analyzed exactly why. It may be worthwhile to just put his code, where he suggested in the first place.

It doesn't work very well though here, they seem to miss way more often than their theoretical "accuracy" score would entail.My experience (1.7.2.x) is that the theoretical 'accuracy' doesn't match the actual results. I have 'new random seed on reload' set (yes I cheat:)) in the options, and even with >70% probability to range attack successfully, the ranged attack misses, no matter how many times I reload. Ranged attacks make sense, add a fun element to playing, and should be made to work correctly IMO.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.The player can move transports and then unload any land units with remaining movement points. Is the AI loading land units and then moving? That would explain why the units are not being unloaded. If possible to code, maybe transports should NOT move prior to the loaded units being able to move.

The player can move transports and then unload any land units with remaining movement points.

There is a long discussion following the link I gave above. Basically, the human can move, unload, wait for other players to attack, reload and then move. This is not cheating, although it is a little strange, and it is the best way we can find to implement land transport. The AI never thinks to unload when it can. So we just need to upgrade the AI to do the same unloading "trick" that the human player can do.

Are the religion flavors in the current tech file? If not it may be worthwhile to re-add.

Yes, they were in one of my changes above that tweaked tech costs I re-added them and they were merged in, they are in 1.7.3 (I think?).
[Though; Technocracy flavors seem to be missing, probably because when re-adding them I only looked for Flavor_Religion entries, and the Technocracy techs didn't have one, and there is an error with Theocracy where the Qizarate flavor is listed twice; I will fix these when I get a chance.]

This is why I write detailed release notes. Please see this comment in 1.7.1:
Sorry, must have missed that one.

It may be worthwhile to just put his code, where he suggested in the first place.
This sounds like it is worth looking into.

The original code by Sephi is very simple. Please see this post (http://forums.civfanatics.com/showpost.php?p=8727378&postcount=28) and the following discussion. In order to reduce the changes to header files, I put the code in a different place than he suggested, and my change did not work. I never analyzed exactly why. It may be worthwhile to just put his code, where he suggested in the first place.

I tried doing the change as originally suggested by Sephi, but the game seems to go to an infinite loop at the very start of the game. I presume there is a common circumstance where his for loop can loop forever.

Though; Technocracy flavors seem to be missing

Technocracy flavors fixed.

I'm done making changes for the next patch and will post it within the next 24 hours. It's a biggie, so it will take a little bit of writing up.

Awesome! I look forward to giving it some playtesting tomorrow.

Incremental Patch 1.7.3.2

Install sequence: 1.7 -> 1.7.3 -> 1.7.3.2
(Can also be installed over 1.7.3.1)

A bumper load of changes....

Moisture and Terraforming

+ Fresh Water is rebranded as Moisture
+ There is a new tag in Civ4ImprovementInfos called iAddsFreshWaterInRadius. A value of -1 means the improvement adds no Moisture to tiles, a value of zero means the improvement adds Moisture only to its own tile, a value of 1 means that Moisture is added to the improvement tile and 8 surrounding tiles, a value of 2 means that Moisture is added to a BFC around the improvement tile. The diagram shows what happens for value 3.

http://forums.civfanatics.com/attachment.php?attachmentid=249875&stc=1&d=1271540677
+ Shallow Well and Wind Trap add Moisture to only their tile (radius = 0). Deep Well and Aquabore have the moisture radius set to 1.
+ A new Moisture Lens improvement is available, can only be built on the Polar Ice bonus, provides +3 water, +2 commerce, adds moisture in a 2 tile radius (BFC). Polar terrain will now terraform straight to grassland (Perhaps Polar Desert Waste should change to Desert Waste too? Although this is actually a terrain downgrade it would look more natural...)
+ Catchbasin now adds moisture in a 2 tile radius (BFC) and Reservoir of Liet in a 3 tile radius.
+ Because each tile now has an internal count of how many times moisture has been added to it, the removal of improvements and buildings should leave moisture in place if there is an overlapping source. (There may still be issues with the removal of individual buildings, the final remedy for this will be to add an iAddsFreshWaterInRadius to BuildingInfos and deal with the adding and removal of moisture in the SDK rather than Python, as has been done for Improvements).
+ Terraforming can occur on any tile that has moisture.
+ Civ4TerrainInfos has a new tag, bWormFriendly which is only set to 1 (=true) for Deep Desert and Desert Waste. This controls whether spice can appear on a terrain and whether worms can enter it. This is also used to switch Sandrider units to being wormless on non-worm-friendly tiles (i.e. Polar Desert Waste).
+ The test for whether spice or worms can appear in a tile is not longer based on whether the tile is adjacent to fresh water, but whether the plot contains Moisture. This is I feel much more transparent particularly to new players. If spice disappears then I can mouse over the tile and see that it is because the tile now has Moisture in it. For a tile to have spice and worms entering it must have worm friendly terrain and no moisture. (Sandrider units will still have the worm graphic on moistured Desert Waste or Deep Desert as it was thought it would look odd otherwise.)
+ A Forest terrain feature has been added, movement cost +2, defence +50% as vanilla forests, also adds +0.50 health to nearby cities (In other words, two forests gives +1 health.) Forest will only appear on Grassland at the Sink elevation.
+ I have stopped the Open Water feature from being placed by Terraforming mostly because the Oasis graphic really doesn't work in Sink terrain. It seems that Open Water would most likely appear in Sinks and, with Forests, we'd have two different possibilities for Grassland upgrade features. Should we keep the Open Water feature? Or lose it and just keep the new forests?

Offworld Trade Goods

+ Semuta (controlled by Ecaz) now works by giving a Semuta Supplier building, gives 3 Semuta bonuses and collects +1 gold per Semuta Den. Semuta Dens give +2 happy, -1 gold to the city they are built in and may be built by anyone who has access to the Semuta resource either directly or via trade.
+ Slig (now controlled by the Tleilaxu) now works by giving a Slig Breeders building, gives 3 Slig bonuses and collects +1 gold per Slig Charcutery. Slig Charcutery gives +1 happy, -1 gold to the city they are built in and may be built by anyone who has access to the Slig resource apart from the Tleilaxu themselves.
+ The four civs that currently have a unique resource via Landing Stage (Ecaz - Semuta, Tleilaxu - Slig, Corrino - Sardaukar, Ix - Ixian Weaponry) are forced to pick their unique resource from their second landing stage if they do not pick it with their first. So, if I am Corrino I can take Sapho Juice from my first landing stage, but I must then pick Sardaukar from my second.
+ Unique resources for Atreides and Ordos and further development of offworld trade goods pending.

Art Changes

+ New unit art for a number of units; Soldier, Infantry, Great Prophet, Shai Hulud Sayyadina and Mentat by myself; Ducal Guard, Ducal Trooper, Bene Gesserit Instructress, Harkonnen and Ordos Heavy Troopers, Kindjal Infantry by Deon. For more see the Unit Art thread (http://forums.civfanatics.com/showpost.php?p=9108558&postcount=71).
+ Reorganized Vehicle and Siege Weapon art so it made a bit more sense. This includes new models for the Roller, Missile Launcher, Heavy Scorpion and Devastator.
+ Lots of new building buttons and some new tech buttons.

Other Changes

+ includes Ahriman's various XML tweaks and fixes since 1.7.3.
+ reduced the Fremen vehicle capture chance to 20% from 50%.
+ Added some more post-processing to Arrakis mapscript. Wherever any 2x2 square of flat ground with no adjacent Mesa tile will now have a Mesa added randomly within that 2x2. This is to reduce the amount of useless areas on the map.
+ Spice Purifier now gives 1 Spice and requires Spice, no longer removes all building unhealth.
+ Polar Water Shipper moved to Water Economy tech.
+ Irulan is now Protective rather than Charismatic.
+ Spice no longer slows down Sandriders.
+ New Remove Outcrop worker task available at Chemical Explosives. Yields some hammers just like chopping forests in vanilla.
+ Razzia Raider upgrades to Naib's Chosen
+ Palmery no longer provides Date bonus. (This is Dune Wars, not Date Wars... ;))
+ Renamed some units and buildings here and there for a bit more flavour.
+ I wasn't sure how to make the Marauder promotion unavailable so I've made it require Lead by Warlord.
+ Some XML tag renaming for ease of development
+ removed Ginaz Swordmaster unit.
+ Fixed RevDef.py reference to BUILDINGCLASS_WEATHER_SCANNER.
+ Removed all "Celebrity Happiness" functionality that was brought in with TLOTags in 1.7.3.1.

I'm bound to have missed something from the list, so let me know if you find anything weird or unexpected.

I have made an installer for 1.7.3.2.
Steps to install:
1. Download 1.7.3.2 installer here (http://www.mediafire.com/download.php?ndwtz04igym).
2. Delete or rename your Dune Wars directory.
3. Run dune-wars-1-7.exe. (Say "OK" to do you wish to uninstall)
4. Run dune-wars-patch-1-7-3.exe.
5. Run the newly downloaded dune-wars-patch-1-7-3-2-incremental.exe.

Before we bundle up 1.7.4, I think the pedia really needs some love...

Wow! An amazing set of stuff. I look forward to testing it out. Some thoughts:

+ Shallow Well and Wind Trap add Moisture to only their tile (radius = 0). Deep Well and Aquabore have the moisture radius set to 1.
Wind traps need to not add moisture. Otherwise fresh water becomes meaningless, because nearly every tile in the game is adjacent to either a well or a windtrap.
And cottage bonuses from irrigation do not require that the cottage tile has fresh water, merely that it is *irrigated*, it it is adjacent to a tile with fresh water.
[I see that range 0 shallow wells will make only their own tile subject to terraforming, rather than adjacent. This is fine.]

Polar terrain will now terraform straight to grassland (Perhaps Polar Desert Waste should change to Desert Waste too? Although this is actually a terrain downgrade it would look more natural...)
Polar desert waste should definitely not change to desert waste, that would kill polar cities. However, we could make a "coastal" grassland variant tile that they could change into that gave say 1w1h1c. Terraforming should never be a downgrade.
Also, lets make sure that the melting lens has a high build time (8 turns on normal? Maybe 12?)

+ Catchbasin now adds moisture in a 2 tile radius (BFC) and Reservoir of Liet in a 3 tile radius.
I'd leave the catchbasin at 1 tile. Otherwise it irrigates your whole big cross, so you get almost all the benefits from terraforming immediately. I think its better if full terraforming has to wait until reservoirs.
The best solution I think is for catchbasin to give the +1 happy, -1 or -2 water, and 1 range moisture.
Then Reservoirs gives +1 happy, -2 water, 3 range moisture.

Remember that at least half the benefit from catchbasins is their increase in your terraform probability.

The test for whether spice or worms can appear in a tile is not longer based on whether the tile is adjacent to fresh water, but whether the plot contains Moisture. This is I feel much more transparent particularly to new players.
Excellent! So shallow wells will not displace any spice, deep wells will displace spice in 1 tile radius.

+ A Forest terrain feature has been added, movement cost +2, defence +50% as vanilla forests, also adds +0.50 health to nearby cities (In other words, two forests gives +1 health.) Forest will only appear on Grassland at the Sink elevation.
I think it should probably only be +25% defense bonus. Otherwise great.
Also will need to check; make sure that you can still build improvements in the tile without destroying the forest. Otherwise we risk a situation where if the tile gets pillaged, you are unable to rebuild there.

Should we keep the Open Water feature? Or lose it and just keep the new forests?I think we should keep the open water feature; I like it. Its a feature, so it will be mutually exclusive with forests, which is fine. Its more a little lake, so it could occur on flatland or in sinks. Its pretty rare. The main purpose of the forest is of course flavor, but also to reassert the superiority of sinks over flatland, which is otherwise removed removed by terraforming because sink grassland is the same as flatland grassland (whereas graben is superior to flatland).

Semuta (controlled by Ecaz) now works by giving a Semuta Supplier building, gives 3 Semuta bonuses and collects +1 gold per Semuta Den.
And this is any Semuta den in the world?

+ Slig (now controlled by the Tleilaxu) now works by giving a Slig Breeders building, gives 3 Slig bonuses and collects +1 gold per Slig Charcutery. Slig Charcutery gives +1 happy, -1 gold to the city they are built in and may be built by anyone who has access to the Slig resource apart from the Tleilaxu themselves.
Hmm. Interesting. Charcutery feels a little weird (the french is charcuterie), but maybe I'll get used to it.

I wonder; maybe semuta and Slig resources should give no base bonus; just the ability to build extra very cheap buildings? We don't want to over-saturate with happiness possibilities.

+ Added some more post-processing to Arrakis mapscript. Wherever any 2x2 square of flat ground with no adjacent Mesa tile will now have a Mesa added randomly within that 2x2. This is to reduce the amount of useless areas on the map.
Interesting, I think this might be very good, we'll have to check to make sure we don't over-mesa.

New Remove Outcrop worker task available at Chemical Explosives. Yields some hammers just like chopping forests in vanilla.
Huh! Great solution! Will the AI use it? They should I guess, just by building an improvement over the top of it.

not Date Wars...
Maybe next mod?

Wind traps need to not add moisture. Otherwise fresh water becomes meaningless, because nearly every tile in the game is adjacent to either a well or a windtrap. And cottage bonuses from irrigation do not require that the cottage tile has fresh water, merely that it is *irrigated*, it it is adjacent to a tile with fresh water.

As far as I can see only Cottages that are actually on Moisture are showing up as Irrigated. Am I missing something? This image shows a Cottage within 1 and 2 tiles of an Aquabore and a Cottage next to Wind Trap. The moisture in the Wind Trap/Shallow Well is slightly redundant I suppose, its only functional effect would be enable terraforming in that tile. In fact, Wind Traps only appear on Mesa which can't be terraformed so the moisture is completely redundant.

http://forums.civfanatics.com/attachment.php?attachmentid=249882&stc=1&d=1271543463

The good thing is you can now easily change the iAddsFreshWaterInRadius in the XML and see how it plays. :)

Excellent! So shallow wells will not displace any spice, deep wells will displace spice in 1 tile radius.

That's right.

I think it should probably only be +25% defense bonus. Otherwise great.
Also will need to check; make sure that you can still build improvements in the tile without destroying the forest. Otherwise we risk a situation where if the tile gets pillaged, you are unable to rebuild there.

Haven't tested building improvements yet. The defense bonus is easily changed in the XML.

And this is any Semuta den in the world?

Yes.

Hmm. Interesting. Charcutery feels a little weird (the french is charcuterie), but maybe I'll get used to it.

I did have Charcuterie at first, but I thought Charcutery was a bit more Dune like for some reason - more medieval sounding. We might want to tweak the AITradeWeight of Slig to make the Tleilaxu trade it away more readily.

I wonder; maybe semuta and Slig resources should give no base bonus; just the ability to build extra very cheap buildings? We don't want to over-saturate with happiness possibilities.

I removed the base bonus from both already.

Interesting, I think this might be very good, we'll have to check to make sure we don't over-mesa.

Yes, let me know if it is too much. You've also mentioned removing the tiniest islands, if I can figure out a good algorithm for that I can do it.

Huh! Great solution! Will the AI use it? They should I guess, just by building an improvement over the top of it.

I presume the AI will use it. I don't know why it wouldn't.

I'd leave the catchbasin at 1 tile. Otherwise it irrigates your whole big cross, so you get almost all the benefits from terraforming immediately. I think its better if full terraforming has to wait until reservoirs.
The best solution I think is for catchbasin to give the +1 happy, -1 or -2 water, and 1 range moisture.
Then Reservoirs gives +1 happy, -2 water, 3 range moisture.

If you want to drop the Catchbasin to one tile radius then there are two lines in DuneWars.py that read "r = 2". If you change both of them to "r=1" then Catchbasins will only add moisture to a 1 tile radius.

Post now redundant.

Post now redundant.

As far as I can see only Cottages that are actually on Moisture are showing up as Irrigated. Am I missing something? This image shows a Cottage within 1 and 2 tiles of an Aquabore and a Cottage next to Wind Trap. The moisture in the Wind Trap/Shallow Well is slightly redundant I suppose, its only functional effect would be enable terraforming in that tile. In fact, Wind Traps only appear on Mesa which can't be terraformed so the moisture is completely redundant.

I haven't had a chance to test in-game yet, and perhaps I don't understand your moisture design properly.
Lets consider by comparison a vanilla Oasis. The Oasis provides fresh water in the tile of the oasis itself, which allows farms to be built (and gives them irrigation bonus with biology) in any tile adjacent to the oasis.
However, tiles adjacent to the oasis, though irrigated, do not have fresh water. A city adjacent to an oasis will get the fresh water health bonus, but a city that is 2 tiles away (ie adjacent to an adjacent tile) will not.

It looks from your screenshots like this is slightly different, and that moisture in a tile does not even provide irrigation in adjacent tiles.

In this case, the windtrap is fine but merely redundant. But the 0 range shallow well is a problem. Shallow wells *should* provide the commerce bonuses for cottages in adjacent tiles, IMO. This is a deliberate mechanic to get the AI to build cottages next to wells, and solar farms not adjacent to wells. Otherwise the AI doesn't tend to build cottages, and cottages are a bit too weak in the early game when compared to solar farms; remember the AI thinks that hammers are better than commerce.

So, best fix is probably to remove (redundant) moisture from windtrap (or keep it, I don't mind), but to return shallow well to range 1.

but I thought Charcutery was a bit more Dune like for some reason - more medieval sounding
I don't feel strongly in any case. Butcher doesn't feel right though. Slaughterhouse... maybe.
Is there a way we could get this building to provide gold for the Tleilaxu player rather than happy? They don't eat the Sligs. Very minor fluff issue though, might be simpler to leave it as is.

If you want to drop the Catchbasin to one tile radius then there are two lines in DuneWars.py that read "r = 2". If you change both of them to "r=1" then Catchbasins will only add moisture to a 1 tile radius.
Ok. I can test.

OK, here is a link to a new CvGameCoreDLL.dll that has the celebrity happiness stuff completely removed. Please overwrite the 1.7.3.2 file in Dune Wars/assets with this one.

Sorry, I don't understand how these files work. This file has a CvGameCoreDLL.dll file.

But my CvGameCoreDLL folder doesnt' have this file, it has a CvGameCoreDLL.h file??

Having pasted this in, the mod CTDs when trying to start a new game.

I will try reinstalling the whole mod.

Deleted entire mod, installed Dune Wars 1.7, 1.7.3, Patch 1.7.3.2.

Still get CTD when I start a new game.

Same here. I tried both DLLs and also ran Dune Wars as an admin (which I didn't have to do with 1.7.3).

Well, I was able to use both the new and old dll's fine. 1. Delete everything. 2. Install 1.7. 3. Install 1.7.3. 4. Install 1.7.3.2. (Be sure you get lots of messages about files being overwritten to make sure you are installing the zip into the right area. Watch your paths.)

This works fine. I tried both archipelago and arrakis maps, brought up the game and autoplayed 10 turns. Then I installed the new dll over the old one. Please note there is an original *file* with the exact name "Dune Wars/assets/cvgamecoredll.dll", and you want to unzip the new file on top of this one, so you get the message about overwriting the file. Ignore the *directory* "Dune Wars/cvgamecoredll", there is nothing to see there (waves hand.) I was able to run with this also.

Well, I was able to use both the new and old dll's fine. 1. Delete everything. 2. Install 1.7. 3. Install 1.7.3. 4. Install 1.7.3.2. (Be sure you get lots of messages about files being overwritten to make sure you are installing the zip into the right area. Watch your paths.)I did exactly this and still get CTD. FYI - I have installed incremental patches before and this is the first time this behavior has occured. I guess I'll have to just go back to 1.7.3. Too bad since the new material looks to be outstanding.

In 1.7.3.2, civchecker finds several problems.

1. Missing button (assets/xml/builds/build_melting_lens.dds) and a missing art file (assets/Art/Structures/Buildings/research_facility/assemblyhall.nif). These could cause a crash, but not at startup.

2. Undefined symbol UNIT_GINAZ_SWORDMASTER in assets/xml/units/civ4unitclassinfos.xml. This could cause a crash at startup, I suppose. But it doesn't for me. For people who are getting a crash, does the crash go away if you edit this file and remove the lines from UnitClassInfo to /UnitClassInfo around this symbol?

3. A previous problem has either re-appeared or was never fixed, in assets/python/revolution/revdefs.py is a reference to BUILDINGCLASS_WEATHER_SCANNER. I do not think this will cause any crash.

1. Missing button (assets/xml/builds/build_melting_lens.dds) and a missing art file (assets/Art/Structures/Buildings/research_facility/assemblyhall.nif). These could cause a crash, but not at startup.There was no folder 'builds' so I created one and copied/renamed a .dds file into it. There was no folder 'research_facility' so I created one and copied/renamed a .nif file into it.2. Undefined symbol UNIT_GINAZ_SWORDMASTER in assets/xml/units/civ4unitclassinfos.xml. This could cause a crash at startup, I suppose. But it doesn't for me. For people who are getting a crash, does the crash go away if you edit this file and remove the lines from UnitClassInfo to /UnitClassInfo around this symbol?Removed it from civ4unitclassinfos.xml and then removed it from civ4civilizationinfos. I still get a CTD.

I downloaded civchecker and ran it on my copy of Dune Wars 1.7.3.2. There were 851 art files in Dune Wars. There are 679 missing art files and 200 undefined symbols found. I uninstalled and then re-installed 1.7.3. Now civchecker shows 298 art files, 720 missing art files and 177 undefined symbols. Not sure what to make of this. Any suggestions on what to try next?

Ah, sorry about the mess. I need to remember to run civchecker...

Sorry, I don't understand how these files work. This file has a CvGameCoreDLL.dll file.

For future reference, CvGameCoreDLL.dll is the compiled SDK code. This sits in the folder Dune Wars/assets. The folder Dune Wars/CvGameCoreDLL contains the uncompiled C++ source code and is only useful for those wishing to work on SDK changes - it is not actually needed for the mod to run.

Now civchecker shows 298 art files, 720 missing art files and 177 undefined symbols.

To actually get these art errors to not show up you need to unpack the file dune-wars-17.fpk using the PakBuild utility. This is best done after you install 1.7 before installing any patches. If you do this then any remaining missing art are real issues.

To sort out the confusion and fix the issues I have made an installer for 1.7.3.2.
Steps to install:
1. Download 1.7.3.2 installer here (http://www.mediafire.com/download.php?ndwtz04igym).
2. Delete or rename your Dune Wars directory.
3. Run dune-wars-1-7.exe. (Say "OK" to do you wish to uninstall)
4. Run dune-wars-patch-1-7-3.exe.
5. Run the newly downloaded dune-wars-patch-1-7-3-2-incremental.exe.

Fixes in this installer version:
+ Fully removed Ginaz Swordmaster unit references from XML.
+ Fixed RevDef.py reference to BUILDINGCLASS_WEATHER_SCANNER.
+ Fixed missing art assets: missing button (assets/xml/builds/build_melting_lens.dds) and missing art file assets/Art/Structures/Buildings/research_facility/assemblyhall.nif)
+ Removed all "Celebrity Happiness" functionality that was brought in with TLOTags in 1.7.3.1.

1. Download 1.7.3.2 installer here.
2. Delete or rename your Dune Wars directory.
3. Run dune-wars-1-7.exe. (Say "OK" to do you wish to uninstall)
4. Run dune-wars-patch-1-7-3.exe.
5. Run the newly downloaded dune-wars-patch-1-7-3-2-incremental.exe.

Did all this. Still get CTD on starting a game (during the "initializing" phase).

Still get CTD. Is this patch compatible with Vista? What operating system are the screenshots taken from?

Did all this. Still get CTD on starting a game (during the "initializing" phase).

This is sad. If you use just 1.7.3 without the patch, does it (still) work?

We have had a problem before where some users don't have write access to their c:\ root directory, and there is a symbol which is undefined in the DW python. Then during startup, one of the python routines attempts to write a logfile into c:\ with the name of the missing symbol and fails. Usually it throws some kind of message about a write permission error. I have checked using 1.7.3.2 and this file is not being written and there is no undefined symbol in the DW python. (The logfile is only written regarding the DW python, not other python such as revdcm.)

I highly doubt this is the problem, but (a) deliverator, do you have any info in your file c:\stats.csv? (b) others who are having the crash may try editing assets/python/dunewars.py. Find the lines in black and add the line in red. Those are all tab characters at the start of the lines, make sure your text editor leaves them all as tabs.

# Print a debug message to file
def DebugPrint(self, txt):
return
f = open(self.DebugFilename, "a")

This problem should be caught by running civcheck before the release. But I have thought it would be better to throw these as alerts instead of printing to a file. That would draw more attention. The related python function is GetCheckInfo, which I wrote as a simple wrapper around gc.getInfoTypeForString. The wrapper can be changed to throw exceptions instead of calling DebugPrint.

Still get CTD. Is this patch compatible with Vista? What operating system are the screenshots taken from?

The operating system requirements are not going to change as the result of a patch. If 1.7.3 worked on your OS, then the OS is not the reason for any 1.7.3.2 failure.

This is sad. If you use just 1.7.3 without the patch, does it (still) work?

Yes.

Running as Administrator does not have any impact.

b) others who are having the crash may try editing assets/python/dunewars.py. Find the lines in black and add the line in red.
Tried this, no impact, same crash.

Edited Dune Wars.py but, as you suspected, that wasn't the problem. 1.7.3 still works after a fresh install. The crash occurs during the 'initialization' process. Has new code been added in 1.7.3.2 that would execute at that time? If so, maybe I could comment it out and see if that fixes the problem.

This seems like quite a strange issue. I have had some crashes during the mapscript initialization when I was working on the patch, but I don't get them at all now.

It would seem that it happens while the mapscript is running.

1. Does it happen with both mapscripts? Archipelago and Arrakis?
2. If you get a crash and then try again does it happen every time?

The only two things I can think of that have changed around terrain is the new Forest feature and the new tag for Terrain called bRequiresFlatlands which isn't set for any terrain. Could you post the contents of the logs directory so we can see what the last thing the mapscript was doing before the crash that might help. We can see if it is adding Terrain or Features or whatever.

I have Windows XP as does David I think. It would be odd if the operating system was making a difference somehow, but not impossible I suppose.

Did the 1.7.3.1 patch work for you guys? If not then it is definitely a problem with something in the TLOTags merge I did.

1. Does it happen with both mapscripts? Archipelago and Arrakis?
Yes.

2. If you get a crash and then try again does it happen every time?
It crashes *every* game. This is not an occasional thing.

Could you post the contents of the logs directory so we can see what the last thing the mapscript was doing before the crash that might help.
Which log files do you want? Here are the only logs that seemed to be updated by starting a game. (Attached.)

Did the 1.7.3.1 patch work for you guys?
I don't *think* I tried that one.

I can reinstall 1.7 -> 1.7.3 -> 1.7.3.1 and retest.

1.7.3.1 starts just fine. I'll try patching to 1.7.3.2 and see what happens.

1.7.3.1 seems bugged for me.

I did a clean install 1.7, 1.7.3, 1.7.3.1, and the mod has several XML errors for the new techs (supertensile materials etc) and then CTDs during the mod loading (as opposed to 1.7.3.2, which was causing CTD during new game loading).

This did not happen when I ran 1.7, 1.7.3, 1.7.3.2.

Could you try removing the entire FeatureInfo FEATURE_FOREST from Civ4FeatureInfos.xml and see if that makes a difference? This would cause python errors for terraforming, but it is worth seeing if the game at least starts.

This is tricky to diagnose since I cannot recreate.

Something else to try. I have uploaded my entire Dune Wars directory here (http://www.mediafire.com/download.php?m1mjixjmzgh). Delete or rename you existing Dune Wars folder and put this one in its place. If you still get an error then that will eliminate the fact that it is an install issue or a missing file change.

Did that and still get CTD. I have time to help debug anyway you think would be helpful. I fear that new features may have to be added one by one to find out where the problem is occuring. I don't think missing art files, etc. are the problem. Usually, CTD occurs from a logic problem (e.g. incorrect definitions, functions returning invalid or unexpected results etc.) That may not be the problem but 1.7.3 definitely works. If I knew the changes I wouldn't mind testing them out one by one. I have plenty of time. If this bug slips into 1.7.4 it would be a shame.

Mmmm. So that means there is something added between 1.7.3 and 1.7.3.2, probably between 1.7.3.1 and 1.7.3.2, that is causing a crash in Vista but not XP.

There are quite a few Python and SDK changes between 1.7.3.1 and 1.7.3.2. Adding them in one at a time could get time-consuming.

It would be good to narrow it down to a SDK or Python issue by doing the following:
1. Create a 1.7.3.2 install and rename the Dune Wars folder to Dune Wars-1.7.3.2.
2. Create a 1.7.3.1 install.
3. Delete or rename the assets/XML folder and the assets/art folder from the 1.7.3.1 install, and copy in the assets/XML folder and assets/art folder from the 1.7.3.2 install.

In other words, create an install the has the Python and SDK of 1.7.3.1 with the art and XML of 1.7.3.2. This could give some Python errors due to renaming of XML tags.

The point is to establish whether there is any issue with the XML and art changes that have been made.

OK, this sounds promising. It sounds like there might be an issue with compiling the SDK using Codeblocks (which is what I have been using) and Windows Vista. See this link (http://forums.civfanatics.com/showthread.php?t=314130).

I haven't yet posted the source changes for the last tweak I made to the code (removing the celebrity happiness stuff). If I do this perhaps david can compile a new DLL using the makefile and see if that DLL will work in Vista.

From Xienwolf in that linked thread:

Vista is more picky than XP is about some errors, like failure to initialize variables. So there is an error somewhere in your code, but XP is cool enough to let it fly. If you switch over to VS2008+ to compile a debug DLL you will probably find an Assert firing somewhere that is linked to your Vista issues. Otherwise it is nearly impossible to locate it without actually running on vista yourself.


Will using VS2005 or higher fix the Vista issue?

Not directly, but it can assist in finding minor "nuisances" (not enough of a bug to cause an XP crash, but enough of one to cause a Vista crash) without having to run Vista personally. Mostly this will happen with FAsserts, but sometimes the debug DLL will notice that something isn't quite right and it stops the program mid-flight to let you know.

Thinking about these points, I see two possible explanations for the Vista crashes from what we know.

1. One thing that changed between 1.7.3.1 and 1.7.3.2 was the introduction of the new tile variable that holds the amount of fresh water in a tile. Possibly, there is an initialization problem with that variable or some other C++ coding error that XP is OK with, but Vista cannot cope with.

AND/OR

2. Compiling using Codeblocks may result in a DLL that will work in XP, but not Vista. This seems less likely since the DLLs in 1.7.3 and 1.7.3.1 were both compiled by me in Codeblocks and have been reported working by Vista users.

OK, this sounds promising. It sounds like there might be an issue with compiling the SDK using Codeblocks (which is what I have been using) and Windows Vista.

The Visual Studio approach to compiling is also free, and described in a lot of detail in refar's guide. Was there a specific reason you picked codeblocks?

I can compile code to try stuff out in about 10 hours from now. But, I don't have vista, so I can upload a new dll which either JF or Ahriman (or others) will need to try.

For the record, I am using Vista, so this seems a promising line of inquiry.

The Visual Studio approach to compiling is also free, and described in a lot of detail in refar's guide. Was there a specific reason you picked codeblocks?

I read in Xienwolf's SDK modding guide that Codeblocks was easier for SDK newbies. Probably I should move to VS.

I can compile code to try stuff out in about 10 hours from now. But, I don't have vista, so I can upload a new dll which either JF or Ahriman (or others) will need to try.

I think this is a good plan. I'll see if I can spot any initialization problem in the code too. I can post the latest source within the next 4 hours.

When I first got Vista, I had a ton of problems with modding civ because how it handles the 'Program Files' directory. It doesn't actually let you write to those files, it only tricks you into thinking that you can. For example, if you edit a Civ file with notepad, and then with something else, Vista will maintain 2 copies of the file for each application, which of course leads to disaster if you thought your notepad changes would change something.

The installer might be writing 'fake' files instead of real files if the user does not have full write permissions on the Program Files directory. I can't remember the location where the fake files are stored. All I know is that anything you inside the Program Files directory can become extremely complicated.

OK, I have a new DLL. This was compiled in Visual Studio 2008. Also, there was definitely some dodgy code around the fresh water parameter which I have fixed.

(It seems to be worth using VS anyway since the compiled DLL is about 1.5MB smaller than the Codeblocks one.)

To test:
1. Delete or rename your Dune Wars directory.
2. Run dune-wars-1-7.exe. (Say "OK" to Do you wish to uninstall?)
3. Run dune-wars-patch-1-7-3.exe.
4. Run dune-wars-patch-1-7-3-2-incremental.exe (http://www.mediafire.com/download.php?ndwtz04igym).
5. Overwrite the file Dune Wars\Assets\CvGameCoreDLL.dll with the one in this ZIP file (http://www.mediafire.com/download.php?kyvynnmdyd5).

I'm hopeful this one will work in Vista...

Great, I will test this tonight (4-5 hours from now).

To test:
1. Delete or rename your Dune Wars directory.
2. Run dune-wars-1-7.exe. (Say "OK" to Do you wish to uninstall?)
3. Run dune-wars-patch-1-7-3.exe.
4. Run dune-wars-patch-1-7-3-2-incremental.exe.
5. Overwrite the file Dune Wars\Assets\CvGameCoreDLL.dll with the one in this ZIP file.


Followed this. 1-7-3 works fine.
Install 1-7-3-2. Load the mod; get a long string of XML errors on load: tech water_discipline, memory_Manipulated_Us, Memory_Political_Marriage.
Mod loads.
Start a game: CTD during initialization.

I followed the instructions in post #1168 and although I didn't get XML errors I still get CTD during initialization. So I tried compiling the DW SDK with Visual Studio 2008 and was successful:), but then found out it was 1.7 code when I started the game:( Doh!

Any thoughts on why I could be repeatedly getting XML errors on some installs that Jester isn't?

Maybe my version of 1-7-3 that I keep using is a beta version, or corrupt?

I followed the instructions in post #1168 and although I didn't get XML errors I still get CTD during initialization. So I tried compiling the DW SDK with Visual Studio 2008 and was successful, but then found out it was 1.7 code when I started the game Doh!

Sorry. I should have posted the up-to-date source for 1.7.3.2 as well. Here it is. (http://www.mediafire.com/download.php?xmzynrj1win)

If you can compile the latest source and still gets the CTD then there must still be a Vista-killing coding error in the C++ somewhere. I think that might still be the case. My changes in the code are commented Deliverator, but I haven't done more elaborate comments yet. Patch 1.7.3.1 contained all the source changes with it, so if you install that and rename it you can potentially do a diff to see what has changed between 1.7.3.1 and 1.7.3.2.

Any thoughts on why I could be repeatedly getting XML errors on some installs that Jester isn't?

Really don't know. It would suggest that you are ending up with an install that is missing some XML changes, but I'm not sure how this is happening. Possibly you do have the beta version of 1.7.3 - you can get the final version here (http://forums.civfanatics.com/downloads.php?do=file&id=14593).

If we can crack this bug then I suggest we put together a step release (1.8) to bring together all the patches that are floating around. It's a long time since 1.7 was released now.

I've found another possible error in the code. I think there needs to be a line added after line 18895 in CvInfos.cpp that reads:

if (isWormFriendly() == bDefault) m_bWormFriendly = pClassInfo->isWormFriendly();

I compiled the up-to-date source code for 1.7.3.2 with "if (isWormFriendly() == bDefault) m_bWormFriendly = pClassInfo->isWormFriendly();" added after line 18895 in CvInfos.cpp. I got no errors or warnings. Inserted new dll but still get CTD during initialization.

Just to make sure, I uninstalled Dune Wars and reinstalled 1.7. Using the source code from the 1.7 installer, I re-compiled the DLL (did get 1 warning from an unreferenced local variable) and replaced it. The game starts normally.

This would seem to indicate Vista-killing coding error(s) in the C++ somewhere in the 1.7.3.2 source. I will now try compiling 1.7.3.1 and see what I can find out.

I compiled the up-to-date source code for 1.7.3.2 with "if (isWormFriendly() == bDefault) m_bWormFriendly = pClassInfo->isWormFriendly();" added after line 18895 in CvInfos.cpp. I got no errors or warnings. Inserted new dll but still get CTD during initialization.

Just to make sure, I uninstalled Dune Wars and reinstalled 1.7. Using the source code from the 1.7 installer, I re-compiled the DLL (did get 1 warning from an unreferenced local variable) and replaced it. The game starts normally.

This would seem to indicate Vista-killing coding error(s) in the C++ somewhere in the 1.7.3.2 source. I will now try compiling 1.7.3.1 and see what I can find out.

Good on you for investigating, Jester Fool.

From memory, there are basically only 3 new areas of functionality added to the SDK between 1.7.3.1 and 1.7.3.2.
1. The bWormFriendly tag for TerrainInfos and the new Sandrider art switching logic.
2. The new system for fresh water.
3. The GlobalBuildingClassCommerce tags that makes the Semuta Supplier and Semuta Den work.

Given that the crash seems to happen on startup I would think that an issue with 1 or 2 is more likely to be the problem, but I could be wrong. If you remove either of 1 or 2 from the code, you will need to alter DuneWars.py to avoid Python errors. For 1 you could just switch isWormFriendly to isWater, for 2 it will be a bit more complication to revert back. Both isWormFriendly and isFreshWater are called from Python when the Spice is being placed at game start so I can see their being an issue there. Perhaps try removing isWormFriendly first.

I know it is possible to compile a debug DLL which might help pinpoint the crash. I've never done it myself though and I can't recreate the crash on XP anyway. There are details at the bottom of this guide (http://modiki.civfanatics.com/index.php/How_to_Install_the_SDK). It would be obviously much better if we can pinpoint the issue with the new features rather than just have to remove them because we can't get them to work in Vista.

Ran 1.7.3.1 with a re-compiled dll and everything worked fine - no problem there.

Although 1.7.3.2 compiles with no errors or warnings, compiling a debug version ends in a fatal error.CvUnit.cpp
CvUnit.cpp(12395) : error C2296: '>=' : illegal, left operand has type 'int (__thiscall CvUnit::* )(void) const'
CvUnit.cpp(12395) : error C2297: '>=' : illegal, right operand has type 'int (__thiscall CvUnit::* )(void) const'
NMAKE : fatal error U1077: '"C:/Program Files (x86)/Microsoft Visual C++ Toolkit 2003/bin/cl.exe"' : return code '0x2'
Stop.
Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"
Compiling 1.7.3.1 as a debug dll gets the same error as 1.7.3.2. However, the debug version of 1.7 works correctly. Does the 1.7.3 exe install the 1.7.3 source code? It might be helpful to see if a debug version can be made of the 1.7.3 source code.

I don't know C++ too well, but line 12395 in Unit.cpp looks like it could be wrong:

int CvUnit::getNoXPCount() const
{
return m_iNoXPCount;
}

bool CvUnit::isNoXP() const
{
return (getNoXPCount() > 0);
}

void CvUnit::changeNoXPCount(int iChange)
{
m_iNoXPCount += iChange;
FAssert(getNoXPCount >= 0);
}

Now, there is no variable called getNoXPCount so I think that line should be:

FAssert(getNoXPCount() >= 0);

The brackets seem to be missing.

In fact, I'm sure that line is wrong if you compare that function with CvUnit::CvUnit::changeOffensiveVictoryMoveCount or CvUnit::changeOneUpCount.

Perhaps with the change will make a difference or at least allow the Debug DLL to compile.

Also, Xienwolf said in that thread that incorrect FAssets can cause issues for Vista. I'm not even sure what the FAssert line does to be honest.

When compiling in normal mode, the text inside "FAssert()" is thrown away without even being looked at. That is why the missing parentheses are not caught in normal compiles. In debug compiles, that text is compiled, and that is why the errors are flagged. In debug compiles, all of these "assert" statements test assumptions that the developers are relying upon. For example, if there are 10 techs, it is an error to ask something about the tech with index -1 or the tech with index 11. The program may work, or it may crash, when these illegal index values are passed in. Without asserts, the runtime is slightly faster but there is no helpful message when these illegal values are passed. With asserts, the runtime is slightly slower and a message is printed whenever the illegal values are passed in.

Add the missing parentheses, and the debug version will compile. There is a lot of philosophical debate among programmers about the proper use of asserts, but it doesn't matter for the problem we are trying to solve.

Okay, Debug version working. These errors come up before the title screen (in order listed) -Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_IMPERIAL already exists
-------------------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_LANDSRAAD already exists
-------------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_IMPERIAL already exists
---------------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_TECHNOCRAT already exists
---------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_QIZARATE already exists
---------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_SHAIHULUD already exists
--------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_IMPERIAL already exists
-------------------
Assert Failed

File: CvGlobals.cpp
Line: 4025
Expression: iExisting==-1 || iExisting==idx || strcmp(szType, "ERROR")==0
Message: xml info type entry RELIGION_TLEILAXU already exists
------------------
Assert Failed

File: CvGlobals.cpp
Line: 3654
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: type FLAVOR_IMERIAL not found
-----------------
Assert Failed

File: CvGlobals.cpp
Line: 3654
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: type FLAVOR_IMERIAL not foundI then launched a game and these errors came up before CTD -Assert Failed

File: CvGlobals.cpp
Line: 3993
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type TERRAIN_TUNDRA not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
-------------------
Assert Failed

File: CvGlobals.cpp
Line: 3993
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type FEATURE_ICE not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
--------------------
Assert Failed

File: CvGlobals.cpp
Line: 3993
Expression: strcmp(szType, "NONE")==0 || strcmp(szType, "")==0
Message: info type FEATURE_JUNGLE not found, Current XML file is: xml\GameInfo/CIV4EspionageMissionInfo.xml
------------------
Assert Failed

File: CvGlobals.cpp
Line: 2003
Expression: eImprovementNum > -1
Message: Update *** I think I found the problem. Attached to the IDE this error comes up right before CTD -"Unhandled exception at 0x04217dfa (CvGameCoreDLL.dll) in Civ4BeyondSword.exe: 0xC0000005: Access violation reading location 0x88000180." The breakpoint is line 16183 in CvInfos.cpp

int CvImprovementInfo::getAddsFreshWaterInRadius() const
{
return m_iAddsFreshWaterInRadius; <-- this line
}

These asserts come using the 1.7.3.2 code, before the CTD. Which asserts come using a debug version of the 1.7.3 or 1.7.3.1 code? I know for sure that the religion asserts in the first spoiler come in any version, so those cannot be causing the CTD. If the asserts in the second spoiler also come in 1.7.3.1 without a CTD, then these are not the cause.

The fact that the messages list espionagemissions.xml is also misleading. I am surprised that these feature and terrain messages would come; they could be caused by either sdk code, or xml, or python. The best way is to "grep" (search in multiple files) in all the sdk files, xml files, and python files. The python is several directory levels deep, be sure to get them all. It is possible that these could cause a crash on startup, but before being too hopeful, please investigate whether the same messages occur with 1.7.3/1.7.3.1.

Update *** I think I found the problem. Attached to the IDE this error comes up right before CTD -"Unhandled exception at 0x04217dfa (CvGameCoreDLL.dll) in Civ4BeyondSword.exe: 0xC0000005: Access violation reading location 0x88000180." The breakpoint is line 16183 in CvInfos.cpp

int CvImprovementInfo::getAddsFreshWaterInRadius() const
{
return m_iAddsFreshWaterInRadius; <-- this line
}

This seems highly likely to be the issue since AddsFreshWaterInRadius stuff for improvements is new in 1.7.3.2. Well done. Now, how to fix?

From the "Access violation reading location" message it sounds like AddsFreshWaterInRadius is not properly initialized. I'm not sure why though, since there is a line setting a value for it in the constructor:
m_iAddsFreshWaterInRadius(-1),

Reviewing the code around iAddsFreshWaterInRadius the only thing that looks obviously odd is that the parameter has a getter but not a setter. To add the setter there should be a line after line 3591 in CvInfos.h that reads:
void setAddsFreshWaterInRadius(int i);

And after line 16185 in CvInfos.cpp:

void CvImprovementInfo::setAddsFreshWaterInRadius(int i)
{
m_iAddsFreshWaterInRadius = i;
}

I'm not sure that not having a setter could cause the Access Violation error, but it is possible. At the least, it is inconsistent with the other variables anyway. I pretty much added this variable by copying m_iCultureControlStrength, but I obviously missed the setter. If it's not the absence of the setter causing the issue, then I'm really not sure what is...

The best way is to "grep" (search in multiple files) in all the sdk files, xml files, and python files. The python is several directory levels deep, be sure to get them all.

I use the tool Agent Ransack (http://www.mythicsoft.com/page.aspx?type=agentransack&page=home). It is a really quick and powerful way for searching a lot of files for a certain piece of text.

hey guys,
whats up?

say, are you still having ctds over the latest version?

ive finished working on my own mod, so now im free to do some dune work, anything i can do for you guys?

I was able to make a debug version (includes all suggested code changes so far) and have started a game. However, in order to do so I had to make the following changes (in red) to CvPlot.cpp :// Remove fresh water from old improvement
// original code - int oldFreshWaterRadius = GC.getImprovementInfo(eOldImprovement).getAddsFres hWaterInRadius();
int oldFreshWaterRadius = -1; // JF - pretend to get value since at start of game this value should be -1 anyway
if ((eOldImprovement != NO_IMPROVEMENT) && (oldFreshWaterRadius >= 0))
{
changeFreshWaterInRadius(-1, oldFreshWaterRadius);
}

// Add fresh water for new improvement
// original code - int newFreshWaterRadius = GC.getImprovementInfo(eNewValue).getAddsFreshWater InRadius();
int newFreshWaterRadius = -1; // JF - disable for now
if ((eNewValue != NO_IMPROVEMENT) && (newFreshWaterRadius >= 0))
{
changeFreshWaterInRadius(1, newFreshWaterRadius);
}I don't know why the call to getAddsFreshWaterInRadius() during initialization crashes Vista but removing the call fixes the CTD. I'll let you know if any other problems come up in the debugger.

Looking at that code, JF, I think perhaps the problem is calling getFreshWaterInRadius when the value is NO_IMPROVEMENT. I can see that causing a crash. I think the code should check that the value is not NO_IMPROVEMENT first like this:

// Remove fresh water from old improvement
if (eOldImprovement != NO_IMPROVEMENT) {
int oldFreshWaterRadius = GC.getImprovementInfo(eOldImprovement).getAddsFres hWaterInRadius();
if (oldFreshWaterRadius >= 0) {
changeFreshWaterInRadius(-1, oldFreshWaterRadius);
}
}

// Add fresh water for new improvement
if (eNewValue != NO_IMPROVEMENT) {
int newFreshWaterRadius = GC.getImprovementInfo(eNewValue).getAddsFreshWater InRadius();
if (newFreshWaterRadius >= 0) {
changeFreshWaterInRadius(1, newFreshWaterRadius);
}
}

Also, l noticed that line 5771 in CvPlot.cpp should read:

changeFreshWaterInRadius(-1, 1);

rather than:

changeFreshWaterInRadius(1, -1);

Thanks Deliverator. The cumulative changes you suggested worked. The dll now works fine under Vista (and still has all the new material - can't wait to try it all out). I have attached a zip file with the recompiled dll.250266

So; if I install the post #1159 files and then change this dll, it should work?

This is what I did :
1. uninstalled Dune Wars (to be safe)
1. installed 1.7 exe
2. installed 1.7.3 exe
3. installed 1.7.3.2 exe
4. replaced old dll with the new one

It works! Great work guys.

Thanks Deliverator. The cumulative changes you suggested worked. The dll now works fine under Vista (and still has all the new material - can't wait to try it all out). I have attached a zip file with the recompiled dll.250266

It works! Great work guys.

Excellent!

Next time I make SDK changes I'll compile a debug dll and check thoroughly for any issues as Xienwolf suggests. I'm actually amazed that the code still worked in XP given the number of things that were wrong in the end...

Just so you know, Vista IS quite picky.:crazyeye: However, the Dune Wars mod is too good to let Vista ruin the party!;)

hey guys,

im working on cleaning the sdk from revdcm, i got something ready, but, i keep getting an "error",

when i start a game - in 1.7.3 and prior versions - we got on game start: mercenary mod :true, now, i keep getting the message after each autosave game,

any ideas why guys?

other then that its going well.

Right folks, I have version 1.8 all bundled up. Let's consider it Beta until we have confirmed it works OK in Vista, etc. I can test Steam vs non-Steam myself.

Changes in 1.8 since 1.7.3.2

+ Vista CTD should now (hopefully) be resolved, thanks to Jester Fool
+ Reverted main Ranged Bombardment calculation back to original Dale's Combat Mod code - this was completely over-tweaked by RevDCM it seems. Since Accuracy now seems to actually do what you'd expect I have revised the Accuracy values. Rocket Artillery can now do ranged bombardment with Range 2 and Accuracy 40%. Howitzer: Range 2, Accuracy 60%. Missile Launcher: Range 2, Accuracy 65%. Assault Cannon: Range 2, Accuracy 75%.
+ When a worm eats a harvester it will now break through the sand and disappear the following turn.
+ Reservoir and Catchbasin water penalty reduced to -2 water from -3.
+ Catchbasin now adds moisture in a 1-tile radius (down from 2).
+ Shallow Well now has a moisture radius of 1 (up from zero).
+ Wind Trap no longer adds moisture (this was redundant anyway).
+ Doubled Melting Lens build time to 800
+ Forest now gives 25% defense not 50%
+ Sayyadina, Instructress and Reverend Mother now have 100% more feminine order and select sounds.
+ Removed House Atomics project - this has been replaced by the Great Convention Breached! wonder
+ Lots of new Tech quotes for the Dune Encyclopedia
+ Added stub entries for Dune Encyclopedia where missing
+ Some other pedia-polishing, Staban Tuek replaces Sid Meier, etc.
+ Removed the Minor Civ Civilization and related Python code.
+ Replaced Dawn of Man text, RevolutionDCM popup no longer appears.
+ Default Land Percentage for Arrakis mapscript is now 24%
+ Slightly reduced the amount of Mesa placed by Arrakis
+ The worldpicker (the planet that appears if you start a game via Play Now!) now looks like Arrakis
+ Tweaked Goody Huts - be prepared for the occasional suprise
+ Removed NoBadGoodies from Scout Thopter and Fremen Scout. Seeing as it is unlikely that Goody Huts will be popped by any other unit that these two, you were highly unlikely to ever see bad Goody hut results.
+ Cymek (Technocracy), Fish Speaker (Qizarate), Commodities Exchange (CHOAM), Palmery (Shai-Hulud), Jihad Veterans Barracks (Mahdi) now all require their enabling religion to be present in the city.

Dune Wars 1.8 Link (http://forums.civfanatics.com/downloads.php?do=file&id=14706)

Nice! We might want to remove the city attack bonus on siege units since we're making them bombardment units (which is good; the AI keeps using them instead of melee, which are supposed to be the assault units). And we need to make shallow wells give moisture range 1, otherwise the AI won't properly build cottages (it builds turbines instead).

Nice! We might want to remove the city attack bonus on siege units since we're making them bombardment units (which is good; the AI keeps using them instead of melee, which are supposed to be the assault units). And we need to make shallow wells give moisture range 1, otherwise the AI won't properly build cottages (it builds turbines instead).

I'll fix the shallow wells radius for the final cut of 1.8.

Agree with tweaking the Siege Units too, but that can wait.

I've switched the link in the above post to a new dune-wars-1-8.exe that will hopefully be the final release.

The only changes from before are that the Shallow Well now has a moisture radius of 1 and the installed shortcuts also work for Steam installs.

I'll aim to release 1.8 properly in around 12 hours or so.

:) Started new game with 1.8 beta - works just fine. The new intro text is absolutely fantastic! The desert will have a new master soon enough...:mischief:

im working on cleaning the sdk from revdcm, i got something ready, but, i keep getting an "error",

when i start a game - in 1.7.3 and prior versions - we got on game start: mercenary mod :true, now, i keep getting the message after each autosave game,

any ideas why guys?

Hi Keldath. Unfortunately, I don't know much about how the code for mercenary mod and the homeworld screen works - it's all koma's stuff. I've downloaded the source for Better BUG AI and have been considering how to create a cleaned SDK myself. I thought the easiest way might be to remove all the Revolutions/RevDCM code from the current Dune Wars first, which might simplify the merge. Anyway, good luck with your efforts.

Deliverator hey bro,

well first of all, superb work with 1.8 and all of the cool stuff you added to the sdk, great work as usual.


im extremely happy that you got better bug ai, since you are a programmer and im not, i am certain that you'll be able to work out a clean sdk code much better then i.

i have tried over this weekend, but i stopped cause its too hard for me.

so we need some stuff from our current revdcm code:

- influence driven war.
- parts of dale code - ranged bombardment/naval bombardment - and maybe air mission code.
- bbai...
- tga indexing - this is the hard part for me - we us it for the fonts - it will be too much work to
re arrange the religions and bonuses fonts o match.

i cant think of anything else right now, but,

if your going to start - perhaps you can use my current code, which is merged with bbai 0.84 (revdcm 2.71), youll be able to compare it to better bug ai (latest), and then youll be able to see the different (updated) codes, along with revolution parts - thus the removing (of all the unneeded code) part much more easier for you.

after this we will still have python code to scrutinize, but i suspect that is the easier part.

i hope what ive made so far will help you, and i even more hoping that youll make a clean cut, that would be swell for dune wars.

goodluck and thanks for writing me,

again, great awesome work on 1.8.

I haven't tried 1.8 yet but it sounds great. When you want the final release, go ahead and put the release note onto the welcome thread; anybody can post there. It's also worthwhile to post in the modpack thread. (If we want to keep the modpack thread in the first page of results, we'll have to post something there every week or so.) Then I will update the first post on the welcome thread, and the first post on the modpack thread. I think those are the only two important things I "own", and it isn't important to "re-own" them right now.

I haven't tried 1.8 yet but it sounds great. When you want the final release, go ahead and put the release note onto the welcome thread; anybody can post there. It's also worthwhile to post in the modpack thread. (If we want to keep the modpack thread in the first page of results, we'll have to post something there every week or so.) Then I will update the first post on the welcome thread, and the first post on the modpack thread. I think those are the only two important things I "own", and it isn't important to "re-own" them right now.

Right, download database, Modpack thread, announcement thread, all done. If you can update the first posts that would be great.

Once ModDB approval has gone through - I'll post an article on there for further publicity.

Updated the modpack first post and welcome first post.

This incremental thread is useful, but it is now really long. Is it worthwhile to start a new one? "Post-1.8 patches"?

Is it worthwhile to start a new one? "Post-1.8 patches"?

Yes, a good plan I think. Page 61...