1.5 Feedback

[Deliverator]

yes it is.

1. Open Unitinfos.xml
2. Find the Settler
3. Change iCost to a bigger number

That's what I thought, but it's not that simple I believe. You can try playing with that number, but Settler iCost is set to zero by default. They and Workers have a special way of working where food and production totalled goes into building. I could be wrong, but I think if you set it to a positive then Settlers will behave just like other units and food will not be contributed to building. All I could find was this info:

The basic Value is:
iDefineName>BASE_CITY_GROWTH_THRESHOLD
iDefineIntVal>2
File: GlobalDefines.xml (assets directory)

This value affect City growth and Setller build time!

iDefineName>CITY_GROWTH_MULTIPLIER
iDefineIntVal>20
File: GlobalDefines.xml (assets directory)

This value affect City growth only!

iGrowthPercent>
File: CIV4GameSpeedInfo.xml (assets\GameInfo directory)

Affects city growth and settler build time!

Base on the BASE_CITY_GROWTH_THRESHOLD!

I don't have time to play with this myself until the weekend. We obviously want a way to increase Settler build without affecting the City growth rate.

 

[Ahriman]

We obviously want a way to increase Settler build without affecting the City growth rate.

It wouldn't be a tragedy if we slowed the city growth rate for the first few levels eg up to pop 5). The concentration of water resources into only a few tiles for a city, and the high value bonus resources, mean that cities in Dunewars grow *much* faster than in vanilla.
Or we could also tone the water cache "saves 50% water" down to say 30% (and take Deathstill down to 40%), its really a no-brainer as the first building.

 

[Deliverator]

Don't forget that the city square gives a minimum of 3 water which is 1 more than vanilla. We could reverse this change.

 

[Ahriman]

Don't forget that the city square gives a minimum of 3 water which is 1 more than vanilla. We could reverse this change.

Possibly, but I kinda like that one, since other tiles won't be generating anything until you research the first water tech and start building windtraps or dew collectors.

 

[davidlallen]

how does the tlelaxu plague mechanic work?

I attacked them, and somewhere along the way noticed that all my troops had the plague, which doesn't seem to go away. made it impossible to continue a war. and it's still on them now. is there any way to get rid of it, or be immune to it ?

Each unit which is involved in a combat with a Tleilaxu unit has a percent chance to catch the plague. Each unit which has the plague has the same percent chance to spread to another unit. Only units of civs which are at war with Tleilaxu can catch or spread the plague. As soon as you make peace, all units will be cured. Also, all units in cities with hospitals or a Suk Academy are cured.

Also, if a unit with the plague enters a city, that city will have an invisible building called Tleilaxu Plague, which gives -2 health, but the building does not spread plague.

It has been suggested to reduce the percent chance of transmission, which is a constant in the DuneWars.py file; search for "transmit percent". It has been suggested that certain units such as walkers and hornets should be immune to the plague. It has been suggested that once a unit has had the plague for some number of turns, say 10 turns, it should recover, and then be immune for some number of turns. These are all good suggestions which have not been implemented yet.

The idea of these civilization unique abilities is that every civ should have an ability which is painful like this. You can see the list in the "Unique Abilities" section of the Dune Wars concept tab of the civilopedia. Some civs do not have this type of ability implemented yet. The goal is actually to make the other civ UA stronger, so that they balance, rather than to make all the UA weak. This is one nice feature of FFH, which took a long time to do; each civ has a powerful ability which is balanced with other civs' abilities.

 

[davidlallen]

Also note that there are some "hidden" benefits from Arrakis spice civic; for example, it radically reduces the chance that a spice resource will disappear when you harvest it

Well, hidden information is a bad thing. This really needs some text in there to mention it, I think.

It is not hidden, but perhaps there are other places it could be mentioned. It is mentioned in the hover help for the civic. I could add a mention in the Spice section of the Dune Wars concepts tab of the civilopedia. Are there other places it should be mentioned?

 

[koma13]

It is not hidden, but perhaps there are other places it could be mentioned. It is mentioned in the hover help for the civic. I could add a mention in the Spice section of the Dune Wars concepts tab of the civilopedia. Are there other places it should be mentioned?

I think it would be cool if you can see, how many turns are left before a spice bonus will vanish (when hovering over tile).

 

[Deliverator]

Possibly, but I kinda like that one, since other tiles won't be generating anything until you research the first water tech and start building windtraps or dew collectors.

I agree which is why I changed it in the first place. Let's not change it then.

 

[davidlallen]

I think it would be cool if you can see, how many turns are left before a spice bonus will vanish (when hovering over tile).

It has a random percent of disappearing each turn. It used to be that there were three density levels which would decay; but that did not seem to add anything. Would it reflect ""reality"" for the spice to announce how much longer it will be workable? In the American West, there were huge copper or silver mines which were suddenly "played out".

 

[Ahriman]

It has a random percent of disappearing each turn.

I think it works fine like this.

In the American West, there were huge copper or silver mines which were suddenly "played out".

And in South Africa, and basically anywhere else that mining occurred.

 

[koma13]

Would it reflect ""reality"" for the spice to announce how much longer it will be workable?

You could say the same about knowing how many turns are left before getting a new tech, bug mods gp bar or combat chances...

I think it works fine like this.

I think it only works fine for fast game speeds. I don't know how often I started building a harvester and spice vanished before I had finished it, or just a few turns after... Very annoying, especially in early game.

 

[davidlallen]

You could say the same about knowing how many turns are left before getting a new tech, bug mods gp bar or combat chances...

I suppose that is true. If people think it is important, we could re-implement the way spice decay works, so that it takes a constant number of turns. Then we could put it into the hover help. The advantage of the random number is that we do not need to keep any "state" for the plot, so the code is simpler.

 

[davidlallen]

I think it only works fine for fast game speeds. I don't know how often I started building a harvester and spice vanished before I had finished it, or just a few turns after... Very annoying, especially in early game.

This can be solved by adjusting the percent chance based on game speed. You have suggested that, and I apologize that I have not implemented that yet. In the python how-to, I have given information about how the decay rate can be tuned by editing DuneWars.py.

 

[davidlallen]

One thing I have not taken the opportunity to explore is "linking" the stage 1-3 improvements the way hamlet-cottage-village-town are linked. This may reduce the number of buttons. It should also allow a storm/worm to reduce the improvement by one level instead of destroying it all at once.

This discussion was around posts 105-113. I have now explored this, and as far as xml-only changes go, there is no good opportunity. Of course "anything is possible" with sdk changes, if it is important enough. In xml, there are two hooks to play with: vanilla ImprovementUpgrade/ImprovementPillage, which is how cottage->town upgrades work and pillage downgrades work; and jeckel's mod for ImprovementRequired, which can limit one improvement from being built, unless it is on top of some other improvement.

In DW today, IU/IP is not used and IR is used for turbines only. So you cannot build a turbine 2 except on top of a turbine 1.

I have also explored how worker build buttons appear. It seems that when you enter an era, all the build buttons for that era appear, even if you do not have the tech. So when you enter the era which contains the tech for deep mines, even if you do not have the deep mining tech, you still get the worker button. This puts one small limit on the number of worker buttons that appear. I could not find any hint of a way to obsolete worker build buttons. You could argue this should not happen anyway, in case the player wants to build some improvement fast, instead of building the best possible improvement.

I tried using IU/IP to link mines the same way cottage->town is linked. Even when I set the iUpgradeTime to 0 or -1, the surface mine upgrades to a deep mine after 1 turn. In the sdk code, there is a function like "max(upgrade time, 1)" and no check for zero or negative. So you cannot prevent automatic upgrading. Also as soon as you use this, there is no way to have the build buttons for the upgraded improvements. This means you would only ever get a surface mine build button, no matter how high your tech. That isn't a dealbreaker but the automatic upgrade after 1 turn is a dealbreaker.

So, without sdk changes, we cannot use IU/IP to downgrade higher level improvements to lower level ones. Although this sdk change would not be rocket science, it appears about 20 places would need to be changed, because the computation to display help text "Will upgrade to X in Y turns" appears many places and is involved in AI decisions about what to build. Also, the upper level build buttons would need to be enabled, and I did not trace out where that would happen.

I was a little surprised to find that turbines are stacked with IR. That mod doesn't appear to cover everything, since the turbine 2 and turbine 3 buttons still appear greyed out when you have the tech. So if we added this, it would not reduce the number of buttons appearing. I cannot think of any strong reason to use this more.

In summary, there is some disagreement on whether changes in this area are important, and there is no easy change, so I am going to put this onto the back burner.

 

[Ahriman]

I know that it is possible at least: in some mods (Rise of Mankind I think?) there are mines that upgrade cottage style from shallow mine to deep mine, *and* have the deep mine buildable directly at a higher tech level.

But it sounds from your investigations like this requires sdk.

For me, the only change that would be worth getting is to have the downgrade one-level from pillage.
If that also needs to use a cottage upgrade mechanic, so be it, just set the upgrade time at 150-200 turns or something, but if that means that the upgraded version is not buildable, then its not worth doing this.
Its more important to have them be buildable than to have them drop down a stage when pillaged.

However, I see no real reason for a level 2 turbine to be buildable only on top of a level 1. We don't require that for mines or wells.

In terms of yield tuning:
At the moment, the AI only uses cottages and turbines; mines and solar farms are never worth building by the AI. The AI sees the -1 water from the solar farm, and thinks thats bad, and it doesn't understand that the -1 water only applies on tiles with water.
Also, the turbine currently requires construction time to upgrade, but the solar farm upgrades for free, making the turbine a bad investment.

My suggestions would be:
a) bring the level 2 turbine earlier in the tech-tree - maybe to the same tech as the deep mine?
b) Increase the surface/deep/core mine yields to +2/+3/+4 hammers. Reduce the extra bonus from bonus resources; currently a surfacemine on nitrates yields ~2 extra over a regular sufrace mine, while a core mine on nitrates yields ~4 extra over a regular surface mine, so the surface mine gives +3 hammers on a nitrates resource, while a core mine gives ~+7 hammers on a nitrates resource (not exact figures, I don't have the game here right now).
c) Remove the initial -1 water from solar farms, and have it added at the tech that gives the next +1 hammer. So solar farms are +2 hammers, and then get +1hammers -1 water from the tech that improves them.
So: rock/graben/rugged can have cottage, turbine or solar farm. Mesa can have mine or windtrap.

 

[zappara]

I know that it is possible at least: in some mods (Rise of Mankind I think?) there are mines that upgrade cottage style from shallow mine to deep mine, *and* have the deep mine buildable directly at a higher tech level.

But it sounds from your investigations like this requires sdk.

Yes, Rise of Mankind has improvements that upgrade and which also can be built once techs for them are gained ie. the earlier improvement type becomes "obsolete". This doesn't need any SDK changes - however I noticed that for some unknown reason this doesn't work with cottage->town upgrade path.

 

[davidlallen]

Yes, Rise of Mankind has improvements that upgrade and which also can be built once techs for them are gained ie. the earlier improvement type becomes "obsolete". This doesn't need any SDK changes - however I noticed that for some unknown reason this doesn't work with cottage->town upgrade path.

How is this written in the xml? I cannot figure out what tags would give this behavior.

 

[Ahriman]

Here is Civ4ImprovementInfos from Rise of Mankind if that helps.

Are there any other files that you'd also like?

 

[davidlallen]

Here is Civ4ImprovementInfos from Rise of Mankind if that helps.

I am not sure what Zappara means when he says there are no sdk changes. In this xml file, the mine upgrades to shaft mine, and the iUpgradeTime is set to 0. In vanilla, RevDCM and BUG, this causes the mine to upgrade automatically to a shaft mine after one turn, even if you do not have the tech. What this shows me is that others have done this sdk change, which is fine; in general untangling one sdk change from a large set of changes is complex. If it is important, we can do it, but I do not think it is easy.

 

[Ahriman]

What this shows me is that others have done this sdk change

Sounds plausible.

I think this fits into a "nice to have" category rather than an "important feature", so lets leave it for now, unless Zappara can somehow shed extra light on this.