Deliverator
Graphical Hackificator
This thread is for feedback on Dune Wars version 1.3. All feedback welcome, be it good, bad or ambivalent. 
Dune Wars 1.3 Feedback
- Thread starter Deliverator
- Start date
davidlallen
Deity
(replies to feedback on "new convert" thread, redirected here)
I don't know this one. I don't use this file. Anybody?
Agree. Deliverator will add a graphic.
Unfortunately we have not updated the events at all. I always play with events off, we should cleanup this whole file at some point. For now "don't use events" should go into the release note.
There is some text which is hard-coded to refer to certain things. It may be possible to find these somewhere in the xml/text files. This is one, from the tech tree; another is "Allows working water tiles". The effect is the correct one, but the text needs to be fixed.
If anybody finds additional text which needs to be updated, please let us know and we can hunt them down. (The text, not the playtesters
On the other hand, here is where we did update one of the texts. This used to say "Remove Jungle", but jungle => salt and you "desalinate" it. We should make sure the same name, "Salt Pan", is used in both places.
Pfeffersack said:
I don't know this one. I don't use this file. Anybody?
Agree. Deliverator will add a graphic.
Unfortunately we have not updated the events at all. I always play with events off, we should cleanup this whole file at some point. For now "don't use events" should go into the release note.
There is some text which is hard-coded to refer to certain things. It may be possible to find these somewhere in the xml/text files. This is one, from the tech tree; another is "Allows working water tiles". The effect is the correct one, but the text needs to be fixed.
If anybody finds additional text which needs to be updated, please let us know and we can hunt them down. (The text, not the playtesters
On the other hand, here is where we did update one of the texts. This used to say "Remove Jungle", but jungle => salt and you "desalinate" it. We should make sure the same name, "Salt Pan", is used in both places.
davidlallen
Deity
DA01. Sapho button is missing ("BONUS_SHEEP") I think keldath already noticed this.
DA02. The City Wind Trap gives no water. It "appears" to have no effect at all. It actually gives fresh water around the city, but this is in python so there is no message about it. Should the CWT give a similar bonus to what the normal WT gives? That, combined with the 3 water for a normal city, may make it too easy.
DA03. The Sand Verbena bonus allows both a drip farm and a camp ("enclosure", I think) to be built, but they appear to give different benefits. Not sure if that is on purpose.
DA04. Need a "water consumed" icon to replace the bread with a nibble out of it, in the city screen at the top where it shows your population growth rate.
DA05. Maybe I had an easy start location, but I had 20 water income by very early. I had two groundwaters, two hills (for wind traps) and a sand verbena in my starting BFC. On the other hand, I couldn't get my health above 4 until I got nutrient convoy. If we get a lot of feedback that water is easy and health is hard, we may need to tune slightly.
DA06. When I built my spice corp, I had 5 gold income, but zero city expense. It is supposed to cancel out -- that is, you are supposed to get 5 gold income but 5 gold expense from "corporate payments". Is anybody getting the 5 gold expense? This makes the amount of early game gold too high.
DA07. I notice the monument only gives +1 culture vs +2 in vanilla. That means the second city takes forever to expand its BFC (without creative). Is there a reason for this? Possibly a side effect of deleting one of the other early culture buildings, but I vote to put it back to +2 culture.
DA02. The City Wind Trap gives no water. It "appears" to have no effect at all. It actually gives fresh water around the city, but this is in python so there is no message about it. Should the CWT give a similar bonus to what the normal WT gives? That, combined with the 3 water for a normal city, may make it too easy.
DA03. The Sand Verbena bonus allows both a drip farm and a camp ("enclosure", I think) to be built, but they appear to give different benefits. Not sure if that is on purpose.
DA04. Need a "water consumed" icon to replace the bread with a nibble out of it, in the city screen at the top where it shows your population growth rate.
DA05. Maybe I had an easy start location, but I had 20 water income by very early. I had two groundwaters, two hills (for wind traps) and a sand verbena in my starting BFC. On the other hand, I couldn't get my health above 4 until I got nutrient convoy. If we get a lot of feedback that water is easy and health is hard, we may need to tune slightly.
DA06. When I built my spice corp, I had 5 gold income, but zero city expense. It is supposed to cancel out -- that is, you are supposed to get 5 gold income but 5 gold expense from "corporate payments". Is anybody getting the 5 gold expense? This makes the amount of early game gold too high.
DA07. I notice the monument only gives +1 culture vs +2 in vanilla. That means the second city takes forever to expand its BFC (without creative). Is there a reason for this? Possibly a side effect of deleting one of the other early culture buildings, but I vote to put it back to +2 culture.
hey guys,
been busy with study to final exam..
great work you guys did so far,
the new fedykeen units, cities map and more.
one thing though...
are we sure we wanna have a thread for every version? wont it create multiple threads in the future?
shouldnt we use "bug thread" for that...?
but, that's just me...
next week ill get back on some Sirius dune work.
lets make 1.4 version a blast
been busy with study to final exam..
great work you guys did so far,
the new fedykeen units, cities map and more.
one thing though...
are we sure we wanna have a thread for every version? wont it create multiple threads in the future?
shouldnt we use "bug thread" for that...?
but, that's just me...
next week ill get back on some Sirius dune work.
lets make 1.4 version a blast
davidlallen
Deity
Most of the mods with sub-forums start a new thread for each major version. That way, if a new player joins up, they can read what people have already reported on the current version, without having to wade through dozens/hundreds of posts about decisions which have already been made in previous versions.
Ahriman
Tyrant
Extracting the 1.3 sound file gives about 30 "file is broken" messages.
Loading the 1.3 mod gives me about 20 or so tag failures when loading xml, including all the leaders. No leaders show up in the mod.
*edit*
I did one atypical thing; I installed the mode before installing 3.19 by accident (the installation was open in another window), then deleted the dune wars folder and reinstalled.
*edit2*
Dumb question, the 1.3 was supposed to be a standalone right, not installed over some previous version?
*edit3*
Deleted and reinstalled the core mod again, but not the sound file, and it works fine.
Maybe the sound file over-wrote some important files by accident?
Loading the 1.3 mod gives me about 20 or so tag failures when loading xml, including all the leaders. No leaders show up in the mod.
*edit*
I did one atypical thing; I installed the mode before installing 3.19 by accident (the installation was open in another window), then deleted the dune wars folder and reinstalled.
*edit2*
Dumb question, the 1.3 was supposed to be a standalone right, not installed over some previous version?
*edit3*
Deleted and reinstalled the core mod again, but not the sound file, and it works fine.
Maybe the sound file over-wrote some important files by accident?
davidlallen
Deity
Please make sure 3.19 is working by itself, then delete your mods\dune wars folder, then install 1.3. This is how I did it, and the game came up first time.
Ahriman
Tyrant
I already did that. It works now, but *doesn't* work if I install the v1.3 Sounds file.
davidlallen
Deity
I am strange, I always play with sound off. It works this way, for sure.
Deliverator
Graphical Hackificator
davidlallen
Deity
Not sure which is the best thread to discuss about runtime performance, but here is what I found.
I did several runs to experiment with runtime. I am not sure exactly what I proved. Perhaps I should have taken a more formal approach. I used the same map, standard size archipelago, and autoplayed 100 turns. Here are the runs, the time in seconds, and what was different about each one.
In (b,c,d), I tried to display as much of the map as possible by turning on ctrl-z and going out to maximum view size (before the clouds appear). In (c,d,g) I replaced some of the nif files with the empty.nif Deliverator made. In (e,f,g) I started autoplay and then immediately minimized the game with alt-tab so it was not actually drawing anything. In (f) I disabled the python so there were no storms, worms or spice displayed. This makes the game play totally differently due to no commerce income, so it is not a perfect test.
I can draw a couple of easy conclusions. First, if you are autoplaying, minimize! It's 40% faster (a vs e). Second, comparing b-c and b-d, the spice seems to make a pretty substantial difference in runtime; the worm and storm together make a much smaller difference. I will retry with the new graphics deliverator has just put up.
It is hard to analyze what (e,f,g) together mean. If it is minimized and no graphics are being drawn, then you would think (e,g) should have the same runtime. Perhaps this time is spent preparing graphics, which are not displayed after all. But the python is clearly doing the same thing in both, so this 10 seconds cannot be attributed to python runtime. The other 10 seconds between (f,g) is due to two factors, python runtime, and the fact that the civs basically starve to death from lack of commerce income. I can't think of any way to separate these. Let's say it is 50/50. Then the additional runtime of all the python is 5 sec, against 127 sec of total runtime. To really understand the impact, we would have to re-implement all this in sdk and see what the runtime of that is; let us say it is 0 sec. Then python accounts for 5 sec of 127 sec or about 3%. I am OK with that.
I did several runs to experiment with runtime. I am not sure exactly what I proved. Perhaps I should have taken a more formal approach. I used the same map, standard size archipelago, and autoplayed 100 turns. Here are the runs, the time in seconds, and what was different about each one.
Code:
a 127 Normal
b 159 Ctrl-z+zoom
c 113 Ctrl-z+zoom, empty spice nif
d 141 Ctrl-z+zoom, empty storm and worm nif
e 77 Minimize
f 56 Minimize, python off
g 67 Minimize, all three nif emptyIn (b,c,d), I tried to display as much of the map as possible by turning on ctrl-z and going out to maximum view size (before the clouds appear). In (c,d,g) I replaced some of the nif files with the empty.nif Deliverator made. In (e,f,g) I started autoplay and then immediately minimized the game with alt-tab so it was not actually drawing anything. In (f) I disabled the python so there were no storms, worms or spice displayed. This makes the game play totally differently due to no commerce income, so it is not a perfect test.
I can draw a couple of easy conclusions. First, if you are autoplaying, minimize! It's 40% faster (a vs e). Second, comparing b-c and b-d, the spice seems to make a pretty substantial difference in runtime; the worm and storm together make a much smaller difference. I will retry with the new graphics deliverator has just put up.
It is hard to analyze what (e,f,g) together mean. If it is minimized and no graphics are being drawn, then you would think (e,g) should have the same runtime. Perhaps this time is spent preparing graphics, which are not displayed after all. But the python is clearly doing the same thing in both, so this 10 seconds cannot be attributed to python runtime. The other 10 seconds between (f,g) is due to two factors, python runtime, and the fact that the civs basically starve to death from lack of commerce income. I can't think of any way to separate these. Let's say it is 50/50. Then the additional runtime of all the python is 5 sec, against 127 sec of total runtime. To really understand the impact, we would have to re-implement all this in sdk and see what the runtime of that is; let us say it is 0 sec. Then python accounts for 5 sec of 127 sec or about 3%. I am OK with that.
Deliverator
Graphical Hackificator
In patch 1.3.1, I have removed the attachable effects from the spice - it made a noticeable difference on my machine.
Ahriman
Tyrant
Initial impressions; there is a *wide* variance in civ power. I think this comes from variance in tile yields.
First, some civs start in areas of badlands that can't be cottaged, and so are commerce poor.
Second, there is a big variation between the water plants and the water supplies, but these come from differences in the value of their improvements.
My *guess* is that the map generation script tries to have fairly even unimproved tile yields across the planet (with some areas slightly better and other areas slightly worse) and then locate civs start point in areas that have good food supply and at least 1-2 hills nearby.
This is problematic when some of the food sources only get 2 water or so from complexes on them, but the groundwater sources get much larger yields from wells.
Civs that started near groundwater grew much faster than those that started near barrel cactus.
Possible solutions:
a) Have the Well and Complex improvements give similar tile yield bonuses, and represent any other small variation in the value of bonus resources with variation in their base tile yield.
b) Remove many of the flatland terrain restrictions, so cottages and solar farms can be built on all or most of the basic terrain types.
First, some civs start in areas of badlands that can't be cottaged, and so are commerce poor.
Second, there is a big variation between the water plants and the water supplies, but these come from differences in the value of their improvements.
My *guess* is that the map generation script tries to have fairly even unimproved tile yields across the planet (with some areas slightly better and other areas slightly worse) and then locate civs start point in areas that have good food supply and at least 1-2 hills nearby.
This is problematic when some of the food sources only get 2 water or so from complexes on them, but the groundwater sources get much larger yields from wells.
Civs that started near groundwater grew much faster than those that started near barrel cactus.
Possible solutions:
a) Have the Well and Complex improvements give similar tile yield bonuses, and represent any other small variation in the value of bonus resources with variation in their base tile yield.
b) Remove many of the flatland terrain restrictions, so cottages and solar farms can be built on all or most of the basic terrain types.
Deliverator
Graphical Hackificator
I'd vote for this one. Plus maybe I can further tune the placement of bonuses.
davidlallen
Deity
Interesting points. I think groundwater distribution is the most worrisome of those feedbacks. I would vote against equalizing the bonus of the well and the complex; the well is supposed to provide a lot of water, while the complex represents getting a little dew off the leaves of things. There is an argument to make the complex *cost* water. So perhaps we have to more carefully normalize the groundwaters available to each civ.
Deliverator
Graphical Hackificator
If you think the starts are too varied now, you should play 1.3.1 with the new polar terrain. 
Ahriman
Tyrant
Maybe the solution there is to have everyone start at the poles; half near the north pole, half near the south pole? And then they expand out towards the middle.
I also don't think that the tundra replacement badlands near the poles with better tiles near the equator makes much sense given Arrakis geography.
davidlallen
Deity
deliverator said:
In my local version with the Terraform Counter, I have defined vanilla plains and grassland. These are also added to the map especially around start positions. I suspect that the mapscript function normalizeAddFoodBonuses is adding my terrain, and also adding your terrain. There are two possible solutions, neither is perfect.
1. In the mapscript, add a line at the end:
def normalizeAddFoodBonuses(): return
This prevents any new food bonus from being added near you, which may be too strong. It seems this does improve terrains, even though from the name you would guess that it only adds resources.
2. I have written a python function inside onGameStart which finds the Terraform terrains and puts them back to our mod's terrain for grassland and plains. I can add the polar ice terrain to this check. It's easy to add but my DuneWars.py is in the middle of some revisions right now. Perhaps tomorrow morning I can make a 1.3.2 which includes your 1.3.1a and also converts polar ice back to arid.
I think we need a more permanent solution to prevent our special purpose terrains from being placed by the default mapscripts. Cephalo is our local mapscript expert and he does not know of a way to do this. I suspect the answer lies inside vanilla CvMapGeneratorUtil.py.
davidlallen
Deity
Using 1.3.1a, the time of run (b), with the full map displayed at max viewing size, is reduced from 159 sec to 124 sec. So that is a significant improvement. Thanks!
Deliverator
Graphical Hackificator
In 1.3.1, I always seem to start in the polar terrain - so much so that it can't be a coincidence. In BonusInfos.xml I have only set groundwater to be normalized, but I'm not sure there's a bit difference with or without it.
Stubbing out normalizeAddFoodBonuses seems a good way to go for now.
