*Latest version at the bottom of this post* v.0.52

--old info---

Ok, I have a first draft of a Dune map script that brings up many questions. I did a bit of research, and it turns out that most of Dune away from the poles is frequently battered by 350 mph sandstorms, and is basically uninhabitable. Because nearly all of the stories and conflict occur in the north pole, most of the maps of Dune you can find are polar oriented maps. Therefore, I went with a similar configuration for this map script.
http://forums.civfanatics.com/attachment.php?attachmentid=218626&stc=1&d=1245713721 http://forums.civfanatics.com/attachment.php?attachmentid=218625&stc=1&d=1245713721

The dune experiment went better than expected, and the existing desert terrain blends perfectly with the deep desert as long as you don't put coast around the dunes. The desert hills would look a bit better if there weren't the rocky bits in them, but overall I'm happy with the result.
http://forums.civfanatics.com/attachment.php?attachmentid=218627&stc=1&d=1245713721

I didn't place any bonuses, because I didn't want my dunes to have grasses and junk all over them for the screenshots. That stuff really shouldn't be in the deep desert anyway. Also, the only solid terrain type is 'arid' because we don't yet have any rules for how the different terrains form. It really helps the immersiveness and believability to have rules for this sort of thing, even if they aren't particularly realistic or accurate. One thing that I learned in my research is that very close to the north pole the sand has a water content that prevent's worms from going there and where water can be mined. That sounds like prime real estate to me, and we should probably have that in the mod for people to fight over.

Some initial comments on the old dune wars dev thread at this post (http://forums.civfanatics.com/showpost.php?p=8197646&postcount=419). More thoughts here, but no specific point yet. I think it is still early discussion.

Looking at the scanned map, it seems like there are rings of peaks around basins. This kind of reminds me of the standard FFH2 mapscript which builds valleys. When I play FFH2 I don't use that script because it seems to limit movement too much. Still, I guess we need some way to get hills/peaks inside the center part of the circle. Is it possible to just throw some code from another mapscript in here for that, without making it dune-specific?

I guess the polar cap where there is water is pretty tiny, compared to the area shown on the map, and worms could go anywhere else except peaks. I did some quick math and a polar region from 60 degrees up, is about 1/16 the surface area of the whole planet. If we go with a polar only map, the standard distance scale may not make too much sense; everything is really 16x closer together.

In terms of putting resources down onto the map, bonusinfos.xml has some settings for min/max latitude that makes fur, for example, only possible near the poles. When you build a polar map, do those ranges automatically get converted into circles of the right radius? Then all the resources can be limited into the 60 - 90 latitudes and they won't go onto the desert. If a lot of code needs to be written into the mapscript to do that, it is more of a problem.

Some initial comments on the old dune wars dev thread at this post (http://forums.civfanatics.com/showpost.php?p=8197646&postcount=419). More thoughts here, but no specific point yet. I think it is still early discussion.

Looking at the scanned map, it seems like there are rings of peaks around basins. This kind of reminds me of the standard FFH2 mapscript which builds valleys. When I play FFH2 I don't use that script because it seems to limit movement too much. Still, I guess we need some way to get hills/peaks inside the center part of the circle. Is it possible to just throw some code from another mapscript in here for that, without making it dune-specific?

I guess the polar cap where there is water is pretty tiny, compared to the area shown on the map, and worms could go anywhere else except peaks. I did some quick math and a polar region from 60 degrees up, is about 1/16 the surface area of the whole planet. If we go with a polar only map, the standard distance scale may not make too much sense; everything is really 16x closer together.

In terms of putting resources down onto the map, bonusinfos.xml has some settings for min/max latitude that makes fur, for example, only possible near the poles. When you build a polar map, do those ranges automatically get converted into circles of the right radius? Then all the resources can be limited into the 60 - 90 latitudes and they won't go onto the desert. If a lot of code needs to be written into the mapscript to do that, it is more of a problem.

There are no limits to what this map script can do as far as placement. I have made quite a few maps and I know the process in and out. If it's in the mod it can be put on the map in any way we choose.

The latitude settings for bonuses would have to be ignored, but that's not too difficult. One advantage you have when making a mod is that you don't have to be so general as you would be when making a game that's intended to be modded. We could make our own rules for placement of certain resources and ignore the xml entirely if we wanted. That makes it difficult for people to make a mod of this mod, but if it makes the mod better and it's easier for us then so be it.

Is it possible for you to take one or two more steps so we can trying playing games on the map? It would need to have hills (for windtraps) and bonuses placed by bonusinfos.xml. If you also put up your terraininfos and graphics files, I can modify a couple of lines in the python to put spice blows on your deep desert, which is critical for commerce.

I have a feeling the game will be quite different, but it's hard to predict how exactly.

davidallen's 'pie slice' analogy from the previous thread definately sums up the strategic situation on Dune. The water at the north pole is vital, but there is no shortage of desert sand on Dune!

That's something that we ought to recognize. The spice melange is of course very valueable in the sense that it only occurs on Arrakis. But, if you are already on Arrakis, you really have more spice than you could ever need; an inexhaustable supply. The only issue is getting rid of your competitors sharing the planet with you. In that struggle, it is water that is the key. I'm thinking that water is the real prize on Dune.

Is it possible for you to take one or two more steps so we can trying playing games on the map? It would need to have hills (for windtraps) and bonuses placed by bonusinfos.xml. If you also put up your terraininfos and graphics files, I can modify a couple of lines in the python to put spice blows on your deep desert, which is critical for commerce.

I have a feeling the game will be quite different, but it's hard to predict how exactly.

Would it be alright if we reserve 'desert' land terrain for the dunes? I can forbid bonus placement on the dunes, but it might be preferable to do that in the xml, in case you guys decide that are a few resources that should go there. Another issue will be map size. Since there is little habitable terrain on these maps, they are going to have to be large in order to mesh with the default amount of players. I'm going to have to play with that so everyones not starting on top of each other. I'll try to get a playable map ready tonight after work.

That's something that we ought to recognize. The spice melange is of course very valueable in the sense that it only occurs on Arrakis. But, if you are already on Arrakis, you really have more spice than you could ever need; an inexhaustable supply. The only issue is getting rid of your competitors sharing the planet with you. In that struggle, it is water that is the key. I'm thinking that water is the real prize on Dune.

Water is precious for its necessity, but the spice is also a vital necessity in the Dune universe. Among its many amazing properties, it prolongs life and enables the Navigators to bend space - enabling space travel. And on that subject...

I still like the two-map-space-and-Dune idea (http://forums.civfanatics.com/showpost.php?p=8125859&postcount=169), but as was pointed out it would probably require Lutefisk Mafia to join the mod to implement, maybe there is a compromise solution more along the lines of Tholish's Future Mod (http://forums.civfanatics.com/showthread.php?t=313196) where space is part of the map.

I'm thinking with Cephalo's polar map the outer edges of the map representing the hostile southern reaches of Dune will be redundant. Also, without the context of space and the other planets (Caladan, etc) this mod lacks something of the Dune atmosphere. Could we have the polar Dune map in the centre and a band of Final Frontier style space around the edge? This would make the game feel more like a board game (not a bad thing in my opinion), but would be great for theme. What do you think?

Edit: I did a crude mockup. See attached. I'm sure there would lots of challenges involved, but it could be interesting. Each House could have its homeworld.

Would it be alright if we reserve 'desert' land terrain for the dunes? I can forbid bonus placement on the dunes, but it might be preferable to do that in the xml, in case you guys decide that are a few resources that should go there. Another issue will be map size. Since there is little habitable terrain on these maps, they are going to have to be large in order to mesh with the default amount of players. I'm going to have to play with that so everyones not starting on top of each other. I'll try to get a playable map ready tonight after work.

What about the tile spice issue I raised here (http://forums.civfanatics.com/showpost.php?p=8198260&postcount=422)?

I'm thinking with Cephalo's polar map the outer edges of the map representing the hostile southern reaches of Dune will be redundant. Also, without the context of space and the other planets (Caladan, etc) this mod lacks something of the Dune atmosphere. Could we have the polar Dune map in the centre and a band of Final Frontier style space around the edge? This would make the game feel more like a board game (not a bad thing in my opinion), but would be great for theme. What do you think?

Edit: I did a crude mockup. See attached. I'm sure there would lots of challenges involved, but it could be interesting. Each House could have its homeworld.

I think that all you need is the graphics from FF and a special terrain type to put it in, and it ought to work. It might even look better if there was a transition terrain type that served as an atmosphere glow.

I like that there's lot's of desert, if for no reason than to convey that the deep desert is extremely vast. It doesn't really need to be utilized in full.


What about the tile spice issue I raised here?


We can put those tiles any old way you want. If you don't want them on the hills, we can put them on the flats. Or, if you want to design them as terrain graphics so they can be on hills, we can place them that way too.

We can put those tiles any old way you want. If you don't want them on the hills, we can put them on the flats. Or, if you want to design them as terrain graphics so they can be on hills, we can place them that way too.

Gameplay wise I'm not too concerned about the spice being on hills. It's just that my current graphical solution uses flat 3D tile NIFs - it wouldn't really work on hills or any uneven terrain.

I think in the book there are huge underground reservoirs in the southern deserts known only to the Fremen. Could be another interesting map idea.

Ok here is a semi-playable version of the map. I have a decent shield wall up now, and bonuses are placed using the default placement. What I do not have yet are proper terrain placement or feature placement, as those generally require rules that are as yet undecided. You might have to place those things in the WB for now.

Also starting positions are done the default way, and as such some people end up on some lonely dune near the equator, also they can end up on the wrong side of the shield wall which might be undesireable.

I tried your mapscript, and I have some feedback.

1. You did not include any new xml for terrains. It works, but what exactly did you do for dune placement? It seems to use the default terrains. If I had to guess, I would say you have made no graphics changes, but you are generating stripes of desert terrain among the deep desert terrain. Is that correct, or did I miss part of the effect?

2. I used the "regenerate map" option several times in a row. The bonuses do not appear to get cleared out in between times. So after generating three maps, practically every square had a bonus.

3. In some maps, the peaks are 3-4 squares thick. This seems somewhat overkill. Can you thin them out so that it is at most 2 squares thick?

4. What we seem to get is a "donut" of usable land. That is, there is a big donut hole of deep desert inside. Is this on purpose? The amount of usable land seems quite small. If possible, could you fill in the center with usable land? Maybe the shape of the land disk could be less regular, so you might get a crescent shape occasionally.

5. The percentage of the map which is deep desert, outside the shield wall, also seems high. Perhaps on a N x N map, only N / 5 of the map should be desert. That is, on 20 x 20 map, 2 squares of desert at the edges, and the inner land would have a useful diameter of 16. The land disk could be less than 16 diameter in places, but never more, so that there would be at least a thin ring of desert. There does not seem to be much benefit in making more than half the map desert which is essentially unusable.

6. There is a standard function somewhere which turns very small extents of ocean into fresh water lakes. I have disabled this in the Archipelago.py which is in version 1.1.2 and up of Dune Wars; see function normalizeAddLakes() at the end of the file. I recommend that you cut in this function to get rid of small patches of deep desert which show up as lakes with fresh water.

7. The graphics I have for "salt pan" are not great; but if you put down jungle in patches, you will get a "salt pan" effect. In vanilla, jungle (and also forest) give some variety to the terrain and force the player to make some tactical decisions. I'm not sure how forest should be allocated, but it may be interesting to aim to get a percentage of land coverage for "salt pan" which is equivalent to the percent coverage of jungle in vanilla.

8. In order to avoid resources on deep desert, you may wish to create a new terrain which is a copy of desert, but call it something different ("desert dune"?). You could place this one in the deep desert, and no bonuses would be placed upon it.

9. The vanilla mapscripts also place "rugged" terrain. Some of the resources are tuned to go on this. Could you add some of that? Maybe random distribution is sufficient, or it could be treated as "super-low hills" or something.

I tried your mapscript, and I have some feedback.

1. You did not include any new xml for terrains. It works, but what exactly did you do for dune placement? It seems to use the default terrains. If I had to guess, I would say you have made no graphics changes, but you are generating stripes of desert terrain among the deep desert terrain. Is that correct, or did I miss part of the effect?

2. I used the "regenerate map" option several times in a row. The bonuses do not appear to get cleared out in between times. So after generating three maps, practically every square had a bonus.

3. In some maps, the peaks are 3-4 squares thick. This seems somewhat overkill. Can you thin them out so that it is at most 2 squares thick?

4. What we seem to get is a "donut" of usable land. That is, there is a big donut hole of deep desert inside. Is this on purpose? The amount of usable land seems quite small. If possible, could you fill in the center with usable land? Maybe the shape of the land disk could be less regular, so you might get a crescent shape occasionally.

5. The percentage of the map which is deep desert, outside the shield wall, also seems high. Perhaps on a N x N map, only N / 5 of the map should be desert. That is, on 20 x 20 map, 2 squares of desert at the edges, and the inner land would have a useful diameter of 16. The land disk could be less than 16 diameter in places, but never more, so that there would be at least a thin ring of desert. There does not seem to be much benefit in making more than half the map desert which is essentially unusable.

6. There is a standard function somewhere which turns very small extents of ocean into fresh water lakes. I have disabled this in the Archipelago.py which is in version 1.1.2 and up of Dune Wars; see function normalizeAddLakes() at the end of the file. I recommend that you cut in this function to get rid of small patches of deep desert which show up as lakes with fresh water.

7. The graphics I have for "salt pan" are not great; but if you put down jungle in patches, you will get a "salt pan" effect. In vanilla, jungle (and also forest) give some variety to the terrain and force the player to make some tactical decisions. I'm not sure how forest should be allocated, but it may be interesting to aim to get a percentage of land coverage for "salt pan" which is equivalent to the percent coverage of jungle in vanilla.

8. In order to avoid resources on deep desert, you may wish to create a new terrain which is a copy of desert, but call it something different ("desert dune"?). You could place this one in the deep desert, and no bonuses would be placed upon it.

9. The vanilla mapscripts also place "rugged" terrain. Some of the resources are tuned to go on this. Could you add some of that? Maybe random distribution is sufficient, or it could be treated as "super-low hills" or something.

1. Yeah it's just desert and desert hills, laid out in a pattern guided by a sand ripple texture. I wrote a separate script to convert the data into a string that I could paste into the map script. That's what all those miles of numbers are for.

2. That might be something in the DLL, I have no bonus placement function in the script, so it's falling back on the default. I have no idea why it would not clear the bonuses.

3. I can probably thin that out.

4. I was hoping to put the 'water rich' terrain in the middle, but we don't have it yet. According to the dune map, there is still deep desert creeping up to the pole, and the worms are prevented only by the small circle of wet sand. You don't have to worry about storms on this sand, but worms can go up to the worm line. I was hoping to have separate continents arranged in a ring, but right now it's a donut. I'll keep working on that.

5. I often put alot of unusable terrain on my maps purely for atmosphere. I want people to feel that the deep desert is unfathomly big. I figure that as long as the map is big enough, and there's plenty of room to play on the donut, it shouldn't get in the way.

6. I think I did disable this. I usually don't use it on my maps.

7. I'll definately want to put that to use.

8. Yeah, I'm currently using desert for that. Really, it seems to me we could just reserve desert for that, and maybe change the name to 'deep desert' like the ocean. It seems clunky to has a terrain called 'desert' when were on a desert planet.

9. Yeah, maybe I can cue the different rocky terrains by altitude, and get a little diversity this way.

1. Yeah it's just desert and desert hills, laid out in a pattern guided by a sand ripple texture. I wrote a separate script to convert the data into a string that I could paste into the map script. That's what all those miles of numbers are for.

2. That might be something in the DLL, I have no bonus placement function in the script, so it's falling back on the default. I have no idea why it would not clear the bonuses.

3. I can probably thin that out.

4. I was hoping to put the 'water rich' terrain in the middle, but we don't have it yet. According to the dune map, there is still deep desert creeping up to the pole, and the worms are prevented only by the small circle of wet sand. You don't have to worry about storms on this sand, but worms can go up to the worm line. I was hoping to have separate continents arranged in a ring, but right now it's a donut. I'll keep working on that.

5. I often put alot of unusable terrain on my maps purely for atmosphere. I want people to feel that the deep desert is unfathomly big. I figure that as long as the map is big enough, and there's plenty of room to play on the donut, it shouldn't get in the way.

6. I think I did disable this. I usually don't use it on my maps.

7. I'll definately want to put that to use.

8. Yeah, I'm currently using desert for that. Really, it seems to me we could just reserve desert for that, and maybe change the name to 'deep desert' like the ocean. It seems clunky to has a terrain called 'desert' when were on a desert planet.

9. Yeah, maybe I can cue the different rocky terrains by altitude, and get a little diversity this way.

1. I think to get the look we want we need a dune feature that looks like dunes rather than hills. I don't know exactly how hills work (more new stuff to figure out - like there hasn't been enough on this mod!), but I think that would be best.

2. I believe this post (http://forums.civfanatics.com/showpost.php?p=7292110&postcount=27) from Dale is relevant. I used to refresh bonuses and goodie huts whether the map is generated or a scenario.

3. Yeah, I didn't particularly like the thick bands of mountains in Creation.py either. Perhaps there is a way to tackle this graphically by having more variation in the mountains. It might be good to customize the mountains to make them more Dunish.

4. How about we create two new terrains Polar Ice and Watered Sands, and then you can have concentric circles of each at the centre of the map. I'm happy to create some graphics.

How this would work in a game mechanics sense I'm not sure, but here's an idea. Did someone (johnny smith?) say that we could have different commerce types? The best model would be to have another commerce type of water. Some tiles produce water and some tiles (mainly the spice) produce gold. You need both. You need to have a presence to the south (the outer areas) to get gold (although there can be some deep desert/spice in the inner areas), but if you have access to the pole you get more water commerce. I'm not sure what is involved in this - but it is surely best to model spice/gold and water as separate yields.

I agree with david that the 'rock island' areas (Arid, Desert Plans) need to be more like Archipegalo, so concentric broken circles. I'm sure you can make the solidity/brokenness of the circles parametric - like the More Islands Less Islands option in your Faire Weather script (which was great).

5. I think it's a question of balance. To a certain extent it is not necessary to show the whole of the deep desert to tell the story that it is there. Also, the really big maps can be a performance issue in the late game for a lot of people. We want Dune Wars to be playable until the end I think.

How this would work in a game mechanics sense I'm not sure, but here's an idea. Did someone (johnny smith?) say that we could have different commerce types? The best model would be to have another commerce type of water. Some tiles produce water and some tiles (mainly the spice) produce gold. You need both. You need to have a presence to the south (the outer areas) to get gold (although there can be some deep desert/spice in the inner areas), but if you have access to the pole you get more water commerce. I'm not sure what is involved in this - but it is surely best to model spice/gold and water as separate yields.


I was thinking that a really simple way to handle water would be to simply change the name of 'food' to 'water'. In regular Civ4, the human need for water is kindof abstracted away, and you can build a fine city without explicit access to fresh water. In a Dune mod, maybe it makes sense to abstract food out of the picture and instead use water for growth. Otherwise you need to teach the AI how to use the extra commerce type, and you're adding complexity to the gameplay only to accomodate a fictional aspect of the setting, wich is probably a bad reason to do so.

I was also thinking that it might be interesting that instead of producing water to grow your population, you could import population from offworld at some cost and try to conserve water to prevent them from 'starving'. Maybe put negative production on terrain, so to work terrain you actually have to spend water. I figured this would make the mod stand out from other mods, but then again, you have to teach the AI how to prevent water shortages, and I probably don't have time for that myself.

As far as the big mountains are concerned, that's our shield wall, so it needs to be obvious I think. I can tone it down a bit though.

Changing the shape of the dunes will be alot of work. The plot types wich govern the shape of a tile are hard coded, and if you notice the resulting shape depends on the shape of every neighbor. If you want to use features instead of plottypes, you would still want to connect them up or else it would look bad to have a separate dune every square. Every attempt I've seen of using a feature to emulate landforms looked terrible.

Every attempt I've seen of using a feature to emulate landforms looked terrible.

Except for Deliverator's spice, of course. :-)

Renaming food to water has been suggested in most of the different dune dev threads. I think the windtrap mechanism we have already makes water a little bit of an issue, using the irrigation mechanism to ensure that spreading water must be planned. Right now the overall low food yield makes pop growth slow, so this effect is not very strong. Maybe it needs to be tuned so it gets in the player's way a *little* more.

I am not an expert on the books, but I don't think the polar cap was actually "wet" or "icy". I think it just had a trace more water than the rest of the planet. Keep in mind that if there had been a lot of water there, the sandtrout would have isolated it, like the rest of the water on the planet. I certainly don't remember any comments in the books about going there to get water. Maybe we can have a terrain type which is slightly different graphically, which we can use to prevent worms from travelling through.

I really like the water for food idea, I have to say. Windtraps and irrigated tiles then just produce water. It would be interesting just to switch the food graphic to water and start thinking in those terms. It could take us in some interesting directions.

I am going to create another release of the spice soon. I still have niggles with it, but I think I am up against some limitations of the game engine. Once this is done it should be quick to create a salt pans feature using the same approach. The only issue is height. I'd need to adjust the height depending on whether the salt pans should be at deep desert (sea) level or ground level.


Changing the shape of the dunes will be alot of work. The plot types wich govern the shape of a tile are hard coded, and if you notice the resulting shape depends on the shape of every neighbor. If you want to use features instead of plottypes, you would still want to connect them up or else it would look bad to have a separate dune every square. Every attempt I've seen of using a feature to emulate landforms looked terrible.

It is tricky, but there are options:
1. Reskin the desert hills to look more like dunes. This might be reasonably effective and would probably be the first thing to try.
2. Create a dunes feature. To get the tessalation for all the different combinations I could possibly smooth out the existing Iceshelf to look like dunes. The real problem is that units don't adjust their vertical position for features, so could appear up to their neck in sand.

Except for Deliverator's spice, of course. :-)

Renaming food to water has been suggested in most of the different dune dev threads. I think the windtrap mechanism we have already makes water a little bit of an issue, using the irrigation mechanism to ensure that spreading water must be planned. Right now the overall low food yield makes pop growth slow, so this effect is not very strong. Maybe it needs to be tuned so it gets in the player's way a *little* more.

I am not an expert on the books, but I don't think the polar cap was actually "wet" or "icy". I think it just had a trace more water than the rest of the planet. Keep in mind that if there had been a lot of water there, the sandtrout would have isolated it, like the rest of the water on the planet. I certainly don't remember any comments in the books about going there to get water. Maybe we can have a terrain type which is slightly different graphically, which we can use to prevent worms from travelling through.

If I remember correct, the polar regions had a more moist atmosphere compared to the rest of the planet, wich made it easier to extract water from. And the terrain was more rocky/hilly compared to the rest of the planet.
Changing food to water sounds best to represent the scarceniss from water. Windfalls should further only be buildeble on food and hill terrain.

For the next phase maybe I'll arrange the most fertile areas toward the pole. The trick will be to make it look like something naturally occuring. Concentric circles would probably look dumb. There has to be a second factor along with distance from the pole that would effect habitability. Any ideas?

For the next phase maybe I'll arrange the most fertile areas toward the pole. The trick will be to make it look like something naturally occuring. Concentric circles would probably look dumb. There has to be a second factor along with distance from the pole that would effect habitability. Any ideas?

You could create patches of mountainridges with fertile areas around it. Scattered around through the dessert.

well, if this is possible or useful at all, the worms are also driven away from the large cities due to their size and the fact that the ground is harder closer to the pole. (Was that at all useful?)

If I remember correct, the polar regions had a more moist atmosphere compared to the rest of the planet, wich made it easier to extract water from. And the terrain was more rocky/hilly compared to the rest of the planet.
Changing food to water sounds best to represent the scarceniss from water. Windfalls should further only be buildeble on food and hill terrain.

I have opened a separate thread (http://forums.civfanatics.com/showthread.php?t=325981) to discuss the pros and cons of changing food to water.

For the next phase maybe I'll arrange the most fertile areas toward the pole. The trick will be to make it look like something naturally occuring. Concentric circles would probably look dumb. There has to be a second factor along with distance from the pole that would effect habitability. Any ideas?

"As indicated by large salt flats, Arrakis once had lakes and oceans."

I'm wondering if you can simulate rivers carving out valleys and lakes in the landscape. The rivers could radiate in a random way out from the centre. The river valleys could be desert waste/deep desert and the ridges the fertile rock areas.

"As indicated by large salt flats, Arrakis once had lakes and oceans."

I'm wondering if you can simulate rivers carving out valleys and lakes in the landscape. The rivers could radiate in a random way out from the centre. The river valleys could be desert waste/deep desert and the ridges the fertile rock areas.

I kinda wish that we could de-couple 'sea' tiles from the PLOT_OCEAN plot type in the SDK. Salt flats and wet sand would look much better as PLOT_OCEAN's. I'd like the water vs. land travel to go by terrain type. That way I could also make the dunes be considered ocean.

EDIT: Is the source code included in the 'dune wars' folder? I'm at work so I can't check. I may be able to figure out if this can be done.

I believe Keldath has included it as a auto-unzip file called sdk.exe.

hi guys,

inded - the sdk is packed witihn the folder.


good job you guys.

I'll try to get updated version next week. I still want a chance to see what my options are for what I'm going to put on it.

I still want a chance to see what my options are for what I'm going to put on it.

This is an intriguing sentence. What do you mean exactly?

This is an intriguing sentence. What do you mean exactly?

I'm messing around with the dll so that water is tied to terrain type rather than plot type. I'm hoping that we can have land types lying low like ocean but walkable for salt flats, and water types for hills so the the dunes can be considered water by the AI.

So far it's half way working... I'm getting some weird results that I need to understand further to get things under control.

One thing that I was not expecting, is that hills and peaks can be placed directly on the ocean floor. I had thought that there were basically 4 different altitudes, but it doesn't work that way. If I use WB and place a peak on the deep desert, I get the peak shape with the deep desert texture! My understanding of the system has become unhinged lol.

EDIT: One thing that will need to be done is to get rid of the specularity of the water surface. If I make 'arid' in the ocean level, it blends with the water surface texture and changes the color in an unappealing way.

If you mean the sparkly sand sea, I'm not a big fan of it anyway...

Well, I don't think it's possible to remove the land water distinction. I was able to set isWater() according to terrain type, but the problem is that the graphics engine already uses terrain type to decide on the base altitude of land or water, and it happens outside of the dll.

I can set land terrain below the water line with WB, but when you save and then load the game, all the land types in the 'lowlands' will raise above the water line and all the water types will sink below the water line. That means we can't use the low altitude for salt flats like I wanted.

Interestingly, both base altitudes, water or land, can have peaks and hills. Just for fun I made the map script use peaks in the deep desert, and here is a screenshot. You can see the tips of the hill tops just peering above the water line! :lol:

No matter what happens, it would be nice to get rid of that visible water texture.

Uh, that's definetly interesting :).

Could we make the water completely transparent so that you basically just see the sea bed? I suppose the problem would be units then looking like they're hovering in the air, but that might be fixable.

Could we make the water completely transparent so that you basically just see the sea bed? I suppose the problem would be units then looking like they're hovering in the air, but that might be fixable.

Yeah, maybe we should leave it alone. It looks like I'm not going to be able to do some of the stuff I wanted.

Alright, I'm not ready to give up just yet. The problem I mentioned is purely graphical. If I make a different xml tag on the terrain infos to denote land other than the existing one, we can still have 'land' in the ocean basin that will be recognized as land be the AI. The old bWater tag will be used by the graphics engine as normal, while the new tag will decide if the map plot is water or land. That should work! That way we can have salt basins that are actually basins instead of plateaus.

Ah it's no good. I succesfully made it so that units and improvements could use the low land, but there's alot of important stuff that's not happening when you try to place a city on the lowlands. The city buildings don't show up and none of the tiles are workable. I may have to just make do with what we have.

The city buildings don't show up and none of the tiles are workable.The former is due to the CityLSystem and can be changed as far as I know and the latter is due to the lack of the unlocking technology - just give out the water tile working tech as start tech.

Cheers, LT.

The former is due to the CityLSystem and can be changed as far as I know and the latter is due to the lack of the unlocking technology - just give out the water tile working tech as start tech.

Cheers, LT.

Thanks LT, maybe there's a mod out there that places cities on ocean that I can look at.

The thing about working those tiles, I have the CvPlot::isWater function return my new flag for whether something is land or not. It should be viewed as land in that sense.

Well, maybe I don't want to be adding a whole bunch of complexity just to have lowland tiles. For now at least I'm going to work on a playable version of the map script, with the best tiles at the pole.

Another playable version would be cool, seeing as version 1.3 of the mod is not far off.

Water for Food is now implemented so if you want we could have a Polar Sink terrain than has a higher food (water) yield.

Another playable version would be cool, seeing as version 1.3 of the mod is not far off.

Water for Food is now implemented so if you want we could have a Polar Sink terrain than has a higher food (water) yield.

Here's my wish list on the terrain:

I want a land terrain called 'deep desert' that has the same bonuses as the 'ocean' deep desert.

I want a land terrain for polar ice, something that looks alot like deep desert but with ice in it. Make it look like it used to be deep desert but more wet or frozen. I'm thinking I might create some dunes at the pole of this terrain, since I can't really make a 'sink' at this time. This will be the juicy stuff that everyone wants access to.

You might get rid of the 'desert' terrain. It doesn't fit with this mod since were talking aobut different kinds of desert. I think the factory maps will respect that change and it shouldn't cause problems in case someone wants to play archipelago or whatever.

Over all. I would like to see all the rock terrains less garish. No bright orange terrain please! They should be different from one another so you can tell what you're looking at, but maybe less diverse in appearance than regular civ. Make the peaks a color that works well with all the rock terrain types. Purple mountains on the black 'rugged' terrain looks terrible.

Over all. I would like to see all the rock terrains less garish. No bright orange terrain please! They should be different from one another so you can tell what you're looking at, but maybe less diverse in appearance than regular civ. Make the peaks a color that works well with all the rock terrain types. Purple mountains on the black 'rugged' terrain looks terrible.

I think you may have quite an old version. The bright orange Arid terrain was recoloured by me a while back. The peaks can probably be retextured to make them look nicer.

I think you may have quite an old version. The bright orange Arid terrain was recoloured by me a while back. The peaks can probably be retextured to make them look nicer.

The one I was most concerned about was the 'desert plains'. In my version it's very bright orange. Really, I think it would be funner for all the terrains to named by some uninviting word for rocks. 'desert plains' seems to imply something you could homestead in.

Ah, that was what I meant. Desert Plains - not Arid. It is now a colour that blends in much more. The terrain to the left is the new Desert Plains. Renaming is easy - if we can think up a new one that is!

http://forums.civfanatics.com/attachment.php?attachmentid=219973&d=1246720120

A Polar land terrain sounds good. We can simply give it +1 or +2 water per tile. We could also have a version of the Groundwater bonus (Polar Aquifer?) that can only appear on Polar terrain that produces a bit more water than normal.

I want to add back the vanilla grass and plains terrain so that when terraformers start to work, some of the arid terrain upgrades to vanilla plains and ultimately vanilla grass. I have added the terrains into the xml with correct graphics as TERRAIN_TERRA_GRASS and TERRAIN_TERRA_PLAINS. Unfortunately the mapscripts all love to add this new terrain around starting positions. So we get arid and desert plains far from starting positions, and vanilla grass and plains near starting positions.

Is there a way to prevent mapscripts from ever using certain terrains?

I have tried adding:

def normalizeAddGoodTerrain(): return

to archipelago.py but that does not make any difference.

EDIT: I added an onGameStart which puts them all back, and this works unless you select "Regenerate Map". Maybe there is a different hack which would work better, but it seems like there should be a way to restrict some terrain from ever being generated. Also, there must be a step I am missing in terms of getting terrains to blend, as you can see in the attached screenshot. Does each of the N terrains have to define how it blends with the other N terrains? Blech.

I think it's the other way around. Starting positions are choosen next to new terrain (because they have better values I suppose). But strange that map scripts are using that new terrain at all. Normally you have to add the rules for new terrain manually in mapscripts to make it work. :confused:

There is also normalizeRemoveBadTerrain. In Arrakis.py all those normalization functions are together and disabled. Check there to make sure you got em all. Also, I don't have the latest version of the mod, but I made a new version of Arrakis.py. I am using TERRAIN_SNOW (rugged)for the special polar ice sand, even though it doesn't currently look right or help with water.

From now on I'll put the latest version in the first post.

Is it possible there is something missing/wrong in my terraininfos? I don't see what could be wrong, but I have taken all the steps I can think of to "hide" these vanilla terrains from the mapscripts. If you have a minute, could you look inside the attachment?

EDIT: I added an onGameStart which puts them all back, and this works unless you select "Regenerate Map". Maybe there is a different hack which would work better, but it seems like there should be a way to restrict some terrain from ever being generated. Also, there must be a step I am missing in terms of getting terrains to blend, as you can see in the attached screenshot. Does each of the N terrains have to define how it blends with the other N terrains? Blech.

Regenerate Map does not clean up and redraw the map properly. I've always had a problem with it.

Is it possible there is something missing/wrong in my terraininfos? I don't see what could be wrong, but I have taken all the steps I can think of to "hide" these vanilla terrains from the mapscripts. If you have a minute, could you look inside the attachment?

I don't think you can hide them outside of altering the map script or adding a tag and altering the SDK.

Thanks for the suggestion. I added the following and now vanilla grass/plains is not added:


def normalizeAddGoodTerrain():
return
def normalizeRemoveBadTerrain():
return
def normalizeRemoveBadFeatures():
return
def normalizeAddFoodBonuses():
return
def normalizeAddExtras():
return


I am a little nervous about removing normalizeAddFoodBonuses on a map which has limited food. But I have gotten the immediate effect I wanted, thanks.

Surely normalizeAddFoodBonuses can't have much to do with the TERRA terrains being placed? I think that just relates to the iNormalize flag in BonusInfos.xml which I only have set for Groundwater.

Also: I think we should have a new terrain TERRAIN_POLAR for the polar area. I like the variety we have in the different rock types. If we create this and use the same graphics as TERRIAN_SNOW for now, then I'll get around to making it look a bit more icy (along with the zillion other things on my list).

Surely normalizeAddFoodBonuses can't have much to do with the TERRA terrains being placed? I think that just relates to the iNormalize flag in BonusInfos.xml which I only have set for Groundwater.


Yeah, actually this one should stay.

Now that 1.3 is available I will update the map with the new polar terrain and incorporate rugged with the rest of the map this weekend. It should be fun to see the new terrain art!

One more question, did you get a chance to make a desert terrain that I can use for dunes that wont have bonuses all over them?

Surely normalizeAddFoodBonuses can't have much to do with the TERRA terrains being placed?
Yeah, actually this one should stay.

When I add a stub normalizeAddGoodTerrain only, the TERRA terrains are still present. When I add the five stub functions shown, they are no longer present. I do not see why any of the other four should prevent this terrain, but one clearly does. I will put back just nAFB and see what happens. It seems to me that since the TERRA terrains have more food in their base yield compared to the other terrains, nAFB may be placing them.

But, I would still rather learn how to prevent the TERRA terrain from being put down in the first place. There seems to be little activity on the mapscript sub-forum; where would be a good place to post to find out more?

When I add a stub normalizeAddGoodTerrain only, the TERRA terrains are still present. When I add the five stub functions shown, they are no longer present. I do not see why any of the other four should prevent this terrain, but one clearly does. I will put back just nAFB and see what happens. It seems to me that since the TERRA terrains have more food in their base yield compared to the other terrains, nAFB may be placing them.

But, I would still rather learn how to prevent the TERRA terrain from being put down in the first place. There seems to be little activity on the mapscript sub-forum; where would be a good place to post to find out more?

The very best place would be to have a look at the sdk. Then you can see what's really happening in these functions. I looked at the xml, and I don't see any tags that would prevent this kind of use. You do SDK work right David?

The very best place would be to have a look at the sdk. Then you can see what's really happening in these functions. I looked at the xml, and I don't see any tags that would prevent this kind of use. You do SDK work right David?

I can read C++ but I have never setup the makefile to build. However, it seems that a lot of the map script subroutines are in python, vanilla CvMapGeneratorUtil.py. I highly suspect the +1 food and +2 food terrains are added by nAFB because there is so little food in the starting position. This problem would not appear in vanilla, or in other mods, because Dune Wars goes much further in reducing the amount of food in the default terrains.

Maybe the best solution is to get rid of this terrain in onGameStart, and just document that "Regenerate Map" should not be used.

Still, I would like some help in understanding the blends. I added the vanilla grass and plains; as you can see from my screenshot there is no blending at all. The edges are hard. How is this controlled in the civ4artdefines_terrain? If there is a faq/tutorial, please let me know.

Being such an active Civ modder as you are, I suggest you get one of those new express(free) versions of Microsoft C++ so you can look around the SDK when a question such as this comes up. You can't compile with those, but the search functions are very good. I use VS 2003 for compiling, but if I just want to investigate something I have a converted project for vs 2008 express. It's much better for navigating the code. Looking through the SDK answers nearly all questions regarding game logic. Graphics are another story however.

In regards to the blanding glich on regenerate map, if you save the game and reload, I bet the glich goes away.

Looking through the SDK answers nearly all questions regarding game logic.

Thanks for the encouragement. I can navigate through the code fine with "vi" and "grep" (long time unix programmer). However, all too often I find a 500 line long, uncommented function, in which six different modders have added six different sections of code. So it is not necessarily an "easy" way to answer questions. Very often there are other modders who have already mastered those code segments and can answer questions.

In regards to the blanding glich on regenerate map, if you save the game and reload, I bet the glich goes away.

I'll try tonight. I call setTerrainType (newtype, true, true) which should cause the graphics to be rebuilt. Since these terrains are changed dynamically during the game, save/reload is not a good permanent solution. Is there anything stronger I can use, besides setTerraintype(true,true) to force proper reblending?

I just ran home for lunch to try 1.3 and it doesn't seem to have the new terrain art that Deliverator mentioned. And the polar terrain is not there yet.

I would like some help in understanding the blends. I added the vanilla grass and plains; as you can see from my screenshot there is no blending at all. The edges are hard. How is this controlled in the civ4artdefines_terrain? If there is a faq/tutorial, please let me know.

Maybe the FFH folks know, I have started this thread (http://forums.civfanatics.com/showthread.php?t=327402).

EDIT: Deliverator has pointed out the answer. In TerrainInfos, make sure that each terrain has a unique LayerNumber. By copying vanilla grass and renaming it, I had the same layer number twice, and this prevents blending. So this is solved.

I just ran home for lunch to try 1.3 and it doesn't seem to have the new terrain art that Deliverator mentioned. And the polar terrain is not there yet.

His actual comment was, "get around to it ... along with the zillions of other things I have to do". Koma13 has recolored some of the vanilla terrains two months back, but I am not aware of any new terrain art available.

His actual comment was, "get around to it ... along with the zillions of other things I have to do". Koma13 has recolored some of the vanilla terrains two months back, but I am not aware of any new terrain art available.

Ok, in any case, there's a new version up that is ready for comments. I can do more when the polar terrain comes in.

I just ran home for lunch to try 1.3 and it doesn't seem to have the new terrain art that Deliverator mentioned. And the polar terrain is not there yet.

I'll try and look into this on the weekend. I'm going to de-redden the mountains too.

OK, I don't want to be the one holding up mapscript development so here is a patch over 1.3 with the polar terrain. I've just adapted the Colonization tundra for the purpose. I've also recoloured the peaks to make them less red.

http://forums.civfanatics.com/attachment.php?attachmentid=220618&stc=1&d=1247258039
http://forums.civfanatics.com/attachment.php?attachmentid=220617&stc=1&d=1247258094

I've made the grid overlay, but for some reason I don't understand switching on grids crashes the game. There's nothing wrong with file location or anything I can see in the XML. Koma may be able to help with that as he did a lot of the original terrain textures.

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

OK, I don't want to be the one holding up mapscript development so here is a patch over 1.3 with the polar terrain. I've just adapted the Colonization tundra for the purpose. I've also recoloured the peaks to make them less red.

http://forums.civfanatics.com/attachment.php?attachmentid=220618&stc=1&d=1247258039
http://forums.civfanatics.com/attachment.php?attachmentid=220617&stc=1&d=1247258094

I've made the grid overlay, but for some reason I don't understand switching on grids crashes the game. There's nothing wrong with file location or anything I can see in the XML. Koma may be able to help with that as he did a lot of the original terrain textures.

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

Screenshots look great. I'll work on it over the weekend.

I want a land terrain called 'deep desert' that has the same bonuses as the 'ocean' deep desert.

I want a land terrain for polar ice, something that looks alot like deep desert but with ice in it. Make it look like it used to be deep desert but more wet or frozen. I'm thinking I might create some dunes at the pole of this terrain, since I can't really make a 'sink' at this time. This will be the juicy stuff that everyone wants access to.

Having re-read your wishlist and run the latest script, I now see why you want the first of these two things. If you keep using the desert terrain as you are doing, we can just change BonusInfos so that no bonuses are placed on the 'dunes'. We can also make the texture match the deep desert texture more closely. Edit: Actually you're way is better we should create a new land terrain for deep desert.
http://forums.civfanatics.com/attachment.php?attachmentid=220625&stc=1&d=1247259846
Looking at the new version, I'd like the ring to be a bit more broken up and archipelago like, but that's probably because I'm used to the Archipelago mapscript for this mod. Could you perhaps make the broken-up-ness a menu option for the script? Or a parameter that can be tweaked in the code?
http://forums.civfanatics.com/attachment.php?attachmentid=220624&stc=1&d=1247259846

I've also recoloured the peaks to make them less red.Since you're working on the terrain right now, do you think the rugged terrain could need a bit of an overhaul? I'm thinking it could be a bit brighter and less saturated and given a very slight bluish tint - making it look more like granite than brownish mud?

Otherwise I'll take a stab at it after I finish the early city set (I've made it to eight different kinds of caves now... I feel weird, and it's terrible to texture them, because I can only use a single texture for city sets... - but I'll get them done, no worries).

Cheers, LT.

I might leave the rugged terrain to you. I seem to have a lot of odd jobs to do on this mod at the moment so I'm doing a little bit of everything.

I'd really like to get that Ornithopter sorted - If you want I can send you the blender file - it's still at 6000 polys and a bit of a mess...

I'd really like to get that Ornithopter sorted - If you want I can send you the blender file - it's still at 6000 polys and a bit of a mess...Sure, but don't expect anything too soon - stuff is piling up on my list... but you seem to experience the same! :lol:

Cheers, LT.

Looking at the new version, I'd like the ring to be a bit more broken up and archipelago like, but that's probably because I'm used to the Archipelago mapscript for this mod. Could you perhaps make the broken-up-ness a menu option for the script? Or a parameter that can be tweaked in the code?

Yes, please keep it as Archipelago-like as possible. I optimized early units for that map script type. On current version of Arrakis.py map script, ai would rarely use transporters.

Yes, please keep it as Archipelago-like as possible. I optimized early units for that map script type. On current version of Arrakis.py map script, ai would rarely use transporters.

This latest version has some adjustment for that, but there's a bunch of interplay between the variables involved. I might have to make some in-game options for that.

Ok, thank you. The problem with transporter is that ai will only use it for assault if regular units can't reach the target city. Hence we have to make sure there are some gaps (-> ocean) inbetween.

koma, at some point, could you take a look and see why my polar terrain is crashing when you turn on grids? I can't figure it out. There is a patch over 1.3 with it here (http://forums.civfanatics.com/showpost.php?p=8253097&postcount=65).

That grid is pain to do. You have to use the grid terrain for tundra (from C4C) and colorize it the same way you have done the normal tundra terrain. Also make sure you save it the same way as the blend terrain.

I looked into your files and tundra seems to be ok. But are your sure the reason for CTD is tundra terrain and not the new mountains (you didn't include grid for it)?

Well I thought it would just use the peak grid from the PAK art. I'll see if putting the peak grids in the folder fixes the problem.

hi,

the dunewars.py - with the new 1.3.1a + 1.3.2
isnt working - it gives a full desert terrain and some polar.

I do not think you are seeing any effect due to the game python (DuneWars.py) or due to any mapscript change either. I think what you are seeing is the effect of Deliverator's new terrains. Please try removing the new polar terrain from terraininfos. Does that fix the problem?

I do not think you are seeing any effect due to the game python (DuneWars.py) or due to any mapscript change either. I think what you are seeing is the effect of Deliverator's new terrains.

I noticed that too. I also think that the new polar terrain is looking like salt and the salt feature is looking like ice. :crazyeye: Maybe we can exchange that?

New version up with the new polar terrain! What does it mean? I dunno!

If someone can change the bonusInfos to exclude DESERT_TERRAIN, this thing will be very close to what I intended, and ready for full playtesting. The shield wall is a little weak, but ultimately that's mostly cosmetic.

EDIT: Gah, I forgot to add the salt flats. Actually, I haven't given any thoughts to how they should be placed. Any suggestions?

EDIT: Gah, I forgot to add the salt flats. Actually, I haven't given any thoughts to how they should be placed. Any suggestions?

Easy answer, clone jungles. Better answer, make lakes, then fill them with salt flats.

Easy answer, clone jungles. Better answer, make lakes, then fill them with salt flats.

Well, this being a polar map, There's really nothing I can use with the default XML. Otherwise we would get a straight line of salt across the middle. I gues I can just make little patches of salt scattered randomly.

I noticed that too. I also think that the new polar terrain is looking like salt and the salt feature is looking like ice. Maybe we can exchange that?

The existing salt flats graphic needs changing I think - to look more salty. I could make the polar terrain look more icy I suppose, but people seem unsure whether there is even any ice on the surface of the poles of Arrakis. I decided to go with the tundra-just-a-bit-of-ice look.

Edit: Checked the latest version, and it definitely feels like it's moving in the right direction.

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

1) It seems like there is too much Rugged Hills terrain.
2) I'm not exactly sure what the polar cap should look like. The dune strips feel a bit weird there. Perhaps we should have an icy sea terrain - although I'm not sure what happens if you mix two ocean terrain graphics. Maybe we should go for a Mars style polar cap so it's more obvious to people. Not sure...
3) It's definitely more Archipelago like which is cool, but there seem to be a few too many small islands and 1 square thin strips of land around (or is that the shield wall?)
4) We should sort out the outer dune hills to make sure no bonuses are placed there. It should only really be spice out in the deep desert.

Anyway, good work so far cephalo. :goodjob:

The existing salt flats graphic needs changing I think - to look more salty. I could make the polar terrain look more icy I suppose, but people seem unsure whether there is even any ice on the surface of the poles of Arrakis. I decided to go with the tundra-just-a-bit-of-ice look.

Edit: Checked the latest version, and it definitely feels like it's moving in the right direction.

1) It seems like there is too much Rugged Hills terrain.
2) I'm not exactly sure what the polar cap should look like. The dune strips feel a bit weird there. Perhaps we should have an icy sea terrain - although I'm not sure what happens if you mix two ocean terrain graphics. Maybe we should go for a Mars style polar cap so it's more obvious to people. Not sure...
3) It's definitely more Archipelago like which is cool, but there seem to be a few too many small islands and 1 square thin strips of land around (or is that the shield wall?)
4) We should sort out the outer dune hills to make sure no bonuses are placed there. It should only really be spice out in the deep desert.

Anyway, good work so far cephalo. :goodjob:

1. There are a couple of things that still need adjusting. The reason there are so many hills is because I lowered the land percentage without lowering the hill percentage. I just forgot.

2. Multiple ocean terrains shouldn't cause problems, except if one is supposedly free of worms it would be weird if you cant walk on it.

3. The shield wall has beed reduced to a strip of land :lol: I may need a new technique. Other than that though, I think it's ok to have a few one square islands just for show. But, I can make further ajustments to smooth the terrain to see how it looks.

4.Yes please!

Since it is supposed to be a polar cap, can you make it not wrap? Right now it wraps both directions.

I didn't count the total number of usable (non-ocean) plots, but it seems much lower than a vanilla archipelago at the same map setting. A 5-player map, which is the size I usually play, is 64x40, and the average distance between civ starting locations is about 15. A 5-player Arrakis map is 80x80 and the average distance is over 20. So it feels much more sparse. Maybe 64x64 would still give enough feeling of space outside the central area.

Have you done anything particular to force starting locations? In the handful of maps I tried, four of the civs were evenly spaced in a circle around the pole, but one was way off center. That guy certain has less access to the polar terrain.

Since this is polar, the dunes should really be circular, shouldn't they? When you zoom way out and clouds appear, they always go east to west; I suppose there is no way to make them go in a circle.

From my understanding of what Cephalo has done (http://forums.civfanatics.com/showpost.php?p=8185668&postcount=363). He took this image of ripples

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

and extracted the coordinates from it to form the pattern of the dunes. That is why there are those big arrays of numbers in the mapscript.

If he repeated the process with an image of broken up concentric circles or a spiral pattern, then I believe we could have the dune pattern you're talking about. It might look better for a polar map than the diagonal lines. If you want Cephalo I can have a go at creating a suitable black and white source image, if you let me know the dimensions...

Agree that the map shouldn't wrap, but that is an easy change.

Since it is supposed to be a polar cap, can you make it not wrap? Right now it wraps both directions.

I didn't count the total number of usable (non-ocean) plots, but it seems much lower than a vanilla archipelago at the same map setting. A 5-player map, which is the size I usually play, is 64x40, and the average distance between civ starting locations is about 15. A 5-player Arrakis map is 80x80 and the average distance is over 20. So it feels much more sparse. Maybe 64x64 would still give enough feeling of space outside the central area.

Have you done anything particular to force starting locations? In the handful of maps I tried, four of the civs were evenly spaced in a circle around the pole, but one was way off center. That guy certain has less access to the polar terrain.

Since this is polar, the dunes should really be circular, shouldn't they? When you zoom way out and clouds appear, they always go east to west; I suppose there is no way to make them go in a circle.

Map size is something we will have to tune. The reason I have it bigger is that there should be less usable land than a normal archipelago map. How much less exactly depends on a few factors that aren't final as yet. It doesn't have to wrap either.

I am not using any starting plot code yet, things are currently placed the default way which will probably have to be changed.

The dunes are cosmetic only, and I just wanted the pattern to evoke sand ripples that you see when water or air passes over sand. I argue that if there were corialis winds travelling around the pole in a circular direction, the dunes would be formed radially like spokes on a wheel. In any case though, the pattern needs to tile so that different size maps can get a somewhat seamless pattern. I thought it was fine for the pattern to look sandy.

Another thing that needs to be changed is that currently I'm setting the different terrains by altitude, best terrain at lowest altitude and more harsh at higher altitude. The problem with that is that hills and peaks tend to be more numerous at higher altitudes, so that most of the hills are on crap land. I thinking of solving this by making a separate midpoint displacement map to guide terrains, that is unrelated to altitude.

Since the desert plots seem to be filling with resources, I am assuming that the entire map is land. Is that correct? This may be a problem. The AI does not use land transport. If there is a land path from point A to point B, the AI will never build and load fast transports; it will have units walk, even though it is much slower. That is why we used an archipelago map with ocean. The original unit set, and also Koma's new unit set, assume that by the mid game, armies travel by transport.

I think either a radial pattern or a circular pattern of dunes is worthwhile to make sure people see the idea of a polar map. I know your concept is based on a specific texture map, but in order to get maps at different sizes a procedural method may be needed. Do other people think the diagonal pattern seems odd for a pole?

Another thing we should probably measure is what is the average number of land plots available to a typical city site. In pangaea, chances are 90% of your BFC plots are on land. I did not count in vanilla archipelago; I am sure it is lower, but on the other hand the ocean plots are useful for city growth. In this map, the number may be very low. Since in DW, ocean plots are good for commerce and not direct growth, this may hamper city development.

Since the desert plots seem to be filling with resources, I am assuming that the entire map is land. Is that correct?

The 'dunes' in the outer regions are land, but most of the sand you see is ocean just like on archipelago.

Do other people think the diagonal pattern seems odd for a pole?

Yes, I do. I think it should probably be a vague circular blob of icy ocean and icy land. I am going to make a more icy looking texture for it and there will be both a land and ocean version we can use. You could even make it an inner donut of icy land surrounding icy ocean - a proper polar sink. I'm thinking the pole needs to look like an ice cap otherwise people won't get the concept. I think something like the Martian ice cap is what we want:

http://upload.wikimedia.org/wikipedia/commons/6/62/Mars_NPArea-PIA00161_modest.jpg
This site (http://dunepedia.wetpaint.com/page/Arrakis) says:
At the planets uppermost point, lay the Polar Caps, a vast expanse of ice, some of which was presumably melted down to make water forthe rich, that had never truly been explored.

Other sources I've looked at refer to polar ice caps.

Since the desert plots seem to be filling with resources, I am assuming that the entire map is land. Is that correct? This may be a problem. The AI does not use land transport. If there is a land path from point A to point B, the AI will never build and load fast transports; it will have units walk, even though it is much slower. That is why we used an archipelago map with ocean. The original unit set, and also Koma's new unit set, assume that by the mid game, armies travel by transport.


The dunes are like islands in the 'water' in that sense. So there are gaps between the continents. I have been asking if we can reserve desert terrain for this purpose and remove all bonuses from it. I'm hoping that the AI won't feel the need to expand onto worthless dune terrain, but it might.

As for the transport issue.. man, that seems like it needs to work properly. Even on archipelago, I would be surprised if there weren't some extremely negative consequences to this mechanic. If you need this, then koma needs to really tear up the AI and make it work. Can you fake it, and make the transports add movement points to the slow units?

The 'dunes' in the outer regions are land, but most of the sand you see is ocean just like on archipelago.

I haven't played a game on this map yet. I guess it is unlikely, but possible, for a civ to put a colony there unless we do something. Is it possible to add an invisible feature whose only job is to set bNoCity=1? This should prevent it completely.

Other sources I've looked at refer to polar ice caps.

Hm, I'd like to check that against "canon". If the polar region is hot, I find it highly unlikely that there would be ice just sitting there. It would melt and the sandtrout would isolate it. I think your graphic captures the right feel, there is some ice there but not so much that you would have water caravans traveling there.

As for the transport issue.. man, that seems like it needs to work properly. Even on archipelago, I would be surprised if there weren't some extremely negative consequences to this mechanic.

We believe that on vanilla archipelago, the AI handles amphibious assaults poorly, but it is no worse than other lame AI decisions. We also believe that Maniac/koma have made enough minor changes to the AI that it can do amphibious assaults on DW archipelago maps. Basically, every city is treated as a coastal city so it can build ocean transports; a few other changes were needed also.

So we believe the current DW archipelago map works about as well as vanilla. It may be that having hills on the outside is OK, as long as (a) no resources there, (b) no civs there, (c) the map does not wrap. These are all solvable.

Hm, I'd like to check that against "canon". If the polar region is hot, I find it highly unlikely that there would be ice just sitting there. It would melt and the sandtrout would isolate it. I think your graphic captures the right feel, there is some ice there but not so much that you would have water caravans traveling there.

I asked on Jacarutu, where they are pretty well informed and 'Orthodox Herbertarians', and they said:

There is a small north polar ice cap that is mined for water, see the polar map in Dune.

There is a small north polar ice cap that is mined for water, see the polar map in Dune.

Isn't making Baron Harkonnen making fun of the 'sweet/small' ice polar caps in the book? I think I remember something like that.

Do other people think the diagonal pattern seems odd for a pole?

Hmm, I'm not sure but I would prefer the current pattern, circles will look strange. Maybe reducing the thickness of dunes by removing flat land (only ocean->hills<-ocean) could make them more convincing.

The original unit set, and also Koma's new unit set, assume that by the mid game, armies travel by transport.

My new unit set has transports from turn 0. We only have to make sure there are ocean gaps here and there. Else we would need land transports :nono:. Make a special desert terrain for dunes with no bonuses and no water/hammers/trade and ai won't settle there. Also remember we have better ai included which improves 'naval' assaults.

Maybe reducing the thickness of dunes by removing flat land (only ocean->hills<-ocean) could make them more convincing.

Make a special desert terrain for dunes with no bonuses and no water/hammers/trade and ai won't settle there.

I'm going to create a better texture for the dune hills, make it have no yields/bonuses and include in patch 1.3.4, although it seems I'll have to comment them out of terrain infos xml until we have a better solution. I'll also include a polar ocean terrain and texture, and I'm thinking of brightening up/recolouring the Rugged terrain a little as Lord Tirian suggested.

I'm going to create a better texture for the dune hills, make it have no yields/bonuses and include in patch 1.3.4, although it seems I'll have to comment them out of terrain infos xml until we have a better solution.

The reason that your polar ice and my terra terrains get added near the start positions, is because they have a food benefit. Your terrain will appear outside any reasonable start positions, and it will have no food benefit, so I don't think it will be a problem. In this case, we would want it removed from maps generated by the archipelago mapscripts but not removed from arrakis mapscripts. If this turns out to be a problem, then in 1.3.4 you could also add stub normalizeRemoveBadTerrain and normalizeAddGoodTerrain functions to the mapscripts in the mod.

New version up. I decoupled the terrain from the altitude, made the map flat, and also added salt.

Unfortunately, I had to remove the shield wall for now. The way it was done basically connected all the islands together which won't work for us. I'll have to do it differently.

The new salt placement is adjustable by the way. I was thinking that I could improve the salt flats by surrounding them with hills. Also, maybe they would look better as a terrain instead of a feature?

I was thinking today that instead of having extra food on the polar terrain, it might be better to allow a city on polar terrain to build a national wonder that provides an amount of water to all cities. Otherwise, we'll most likely be seeing giant metropolises in the polar area, which doesn't really fit the fiction. Maybe the terrain itself could be inhospitable, but the national wonder(ice mine, whatever) would provide a nice benefit to having a city there.

This would require at most some very minor SDK changes.

Would it not be easier just to forbid founding cities on polar terrain?

Would it not be easier just to forbid founding cities on polar terrain?

Well, then there's no benefit to the polar terrain.

In my view, the polar terrain should be pretty small, and surrounded by a ring of civs. If the amount of water there is valuable, then it should be an opportunity for all the civs to go there and fight over it. They would ship it back to their existing cities somehow.

In terms of mechanics, we might need some improvement like "Ice Drilling"; then a civ could build a fort and this improvement. But, if the goal is to ship it back, how does that work? Maybe some new bonus like "ice" which gives +1 food at every city? (Is that possible?)

Well, then there's no benefit to the polar terrain.

When giving polar terrain additional food, you could build cities next to polar terrain.

In my view, the polar terrain should be pretty small, and surrounded by a ring of civs. If the amount of water there is valuable, then it should be an opportunity for all the civs to go there and fight over it. They would ship it back to their existing cities somehow.

In terms of mechanics, we might need some improvement like "Ice Drilling"; then a civ could build a fort and this improvement. But, if the goal is to ship it back, how does that work? Maybe some new bonus like "ice" which gives +1 food at every city? (Is that possible?)

That's exactly why I was thinking national wonder. It would be a small SDK change. I had to do this for happiness in my Gross National Happiness mod.

When giving polar terrain additional food, you could build cities next to polar terrain.

The configuration of the maps I've seen of Dune, the polar area (worm line) seems to be surrounded by the usual deep desert. I've modeled it this way in the map script. If we keep it that way, you won't really be able to reach the polar terrain with your borders. I sortof imagined it out in the desert.

The configuration of the maps I've seen of Dune, the polar area (worm line) seems to be surrounded by the usual deep desert. I've modeled it this way in the map script. If we keep it that way, you won't really be able to reach the polar terrain with your borders. I sortof imagined it out in the desert.

Ah ok, i should have noticed. Doing that national wonder sounds good too.

That's exactly why I was thinking national wonder. It would be a small SDK change. I had to do this for happiness in my Gross National Happiness mod.

I did not follow that. Perhaps you would build an improvement on the polar terrain in order to get a resource, and that resource enables building a national wonder in your city (which is not on polar terrain), and that wonder gives a +1 food in every city. Is that what you meant? Which part of that requires an SDK change?

I did not follow that. Perhaps you would build an improvement on the polar terrain in order to get a resource, and that resource enables building a national wonder in your city (which is not on polar terrain), and that wonder gives a +1 food in every city. Is that what you meant? Which part of that requires an SDK change?

Hey that doesn't require an SDK change does it? Yeah, that would be simplest then.

In the book, one of the guests at the Atreides banquet is 'a water-shipper whose summer mansion was near his polar-cap factory'. So a factory improvement at the poles sounds good. Not sure what to call a factory that makes water out of ice, maybe Polar Water Factory is good enough. Then we can have an Ice bonus only appearing on Polar Terrain.

The National Wonder idea is doable, but... we now have two corporations to replace, (Sapho Corp, and Stillsuit Makers, as a consequence of recent and soon-to-be bonus changes so it would make perfect sense to have a Water Shippers Corporation (or is there already a Water one? - I forget) and do something with that.

Also in the book, the talk about the northern deserts as well as the southern ones so a ring of deep desert around the pole is appropriate.

Not sure what to call a factory that makes water out of ice, maybe Polar Water Factory is good enough. Then we can have an Ice bonus only appearing on Polar Terrain.

Ice Processor? Ice Extractor?

The National Wonder idea is doable, but... we now have two corporations to replace

I rarely use corps in vanilla, so I may not be the best judge, but what do you think about simply removing all the non-spice corps?

As far as I could tell from reading articles like this (http://forums.civfanatics.com/showthread.php?t=237717) about Corps in vanilla, Sid's Sushi was by far the best and it was the only one I ever built when I was playing vanilla. It seems like the concept of Corporations is quite a cool thing, but even Firaxis couldn't come up with 7 decent/compelling ideas for them. I think the way that they are implemented is just not that fun maybe. The fact that domestic corporation spread does not make money is sort of counter-intuitive.

The current ones need some redesign anyway after the bonus overhaul. There may be some much more interesting things we can do with them, but it needs some research and thought.

Maybe we should open a Corporations thread to discuss whether we keep them/how can we improve them. I think FFH2 tried to do something with corporations but ended up taking it out again...

In my opinion, corporations don't make alot of sense on this planet. This is all about spice. I don't know if you guys ever played M.U.L.E. (If not, you really, really should. It's possible these days with a commodore 64 emulator.) but in that game there is a very clear example of the situation on Dune. If you have competitors for a commodity, your profits are drastically reduced.

Everyone who comes to Dune is already a corporation or other business entity looking to cash in. The conflict of interest between factions is so great that either accepting or offering 'help' to any other faction can only be viewed as a bad idea. Any trade between houses would have to be so carefully considered that it would happen only during short periods of dire mutual interest. I don't think that corporations could thrive here unless they were completely locked out of and independant of the spice interests.

I remember m.u.l.e. :lol:

It would be cool if we can somehow create a setting that allows a spice monopoly, maybe as a victory condition.

Decided to make a legible version of the map of Arrakis for reference purposes. Here it is.

I've been messing around with terrain a lot today, and I've made a little breakthrough that I'm quite excited about. I've managed to completely remove the water. No more weird grey sparkly thing hovering over the desert. The impact is big for such a small change. I like the fact that now that units walk on the sea bed in effect, it feels like the land is more like the mesas and rocky outcrops shown in the book map.

http://forums.civfanatics.com/attachment.php?attachmentid=221509&stc=1&d=1248019417
http://forums.civfanatics.com/attachment.php?attachmentid=221508&stc=1&d=1248019417


Also, as you see I've been trying to make the deep desert in this mapscript look like dunes. I've been taking the textures and blurring them which seems to help sell the dunes. I think I may have overdone it in these screenshots, but with some more tweaking it could look pretty good. I've done improved polar terrain too. I'll put it all in a miny terrain patch so that it can be used to develop the mapscript. Cephalo - really like this latest version by the way, it's not far off being something really cool.

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

you removed water??

what does this mean??

is it like our first versions of maps that koma made with desert instead of water?
how will it impact the domain sea and units ai? transports and so on?

i too rather have it with no water - if we get get over the transports - it will create a much better game since the ai could be much more affressive - it will attack via "ocean" just like it was a land terrain,
the game will be much much less boring and interestin.

the art look a real buety,
i look forward to see you breakthrough,
great work!

Here a patch specifically to aid the Arrakis.py mapscript. It does the following:

Polar and No Water Development Patch

+ Adds two new terrains, Polar Desert Waste and Polar Deep Desert. It may be that we don't need both of these. I was thinking perhaps the Polar Deep Desert can be used to create the Worm Line around a blob of Polar terrain at the centre representing the Polar Sink/Cap. The Desert Waste can be used as the coast around the Polar blob, but having tested it I think just going straight to the Polar Deep Desert may look better. Haven't done new icons for these yet.

+ Polar terrain graphics updated to look more frosty. It needed to be more obvious that it was the pole and not salt or something.

+ Removes the graphical water effect entirely making the deep desert look much better. I decided to leave my dune texture experiments out for now. I'm now pretty confident we can get dune-like deep desert though.

+ Renamed the Desert Terrain to Dunes and prevented bonuses from appearing on them. We'll have to decide how we are going to handle these changes with regards to the Archipelago mapscript, when we are ready to release this.

Donwload Link (http://www.mediafire.com/download.php?y2wjy5dz2lh)

It would be nice to work towards a full release Arrakis.py and start getting some player feedback. The Ice bonus idea should probably get implemented before then.

you removed water??

what does this mean??

Don't panic! It's a graphical only change...

Edit: Those bladesmen I plonked down on the 'sea bed' was just to test than they were standing at the right height.

Excellent work Deliverator! What patches does this patch depend on? I'm still using 1.3.

I'm glad you removed that water texture. Maybe I should try my water = land change again. The problem is that I would have to figure out how to make all the normal city buildings drawable on water via the L system.(like lighthouse, colossus) The L system seems veery complicated.

Ah, should have said it depends on patch 1.3.6 available at this link (http://forums.civfanatics.com/showpost.php?p=8276339&postcount=129).

I've done a coloured in version of the Arrakis map seeing as the white version is hard to read. I never realised the shield wall was so fat...

Maybe I should try my water = land change again.

I think it's probably not worth the bother, all things considered. Various changes have been made to get the AI to transport units around in Thopters/Hover etc and its probably not worth upsetting that.

ahh no panic!

i like this alot!

i have a q,

the start locations are allover the map, isnt suppose to be on the terrain?

anyway, looks freat those dunes.


***

well deliverator,

i always prefered a land based terrain for the entire map, cause the ai will run attack much better...:)

The start locations are scattered around the rock 'islands'. What do you think should be different?

i always prefered a land based terrain for the entire map, cause the ai will run attack much better...

I prefer the model we have I think. The desert should feel different and dangerous. I still want to persuade people that worms swimming through the rock islands is just wrong wrong wrong...

I noticed that my 7zip caught a CRC error on polargrid.dds, saying that the file is broken. I'll try it anyway.

shouldn't the factions all begin on the centered rock?

except maybe the fremen?


you dont have to convince me about worms on rock, it wasnt right in the movies aswell,

maybe we need another beast for rocks?

shouldn't the factions all begin on the centered rock?

except maybe the fremen?


you dont have to convince me about worms on rock, it wasnt right in the movies aswell,

maybe we need another beast for rocks?

Yes, I haven't examine starting plots yet. Right now it's just the default routines.

maybe we need another beast for rocks?

It's a good idea, but it's difficult to find something native to Arrakis. I think the best thing would be to have more danger from Smugglers and perhaps some barbarian Fremen too. Given the Fremen are tribal, it is fair to think that there are some groups that are not aligned with the two playable factions at the start of the game.

I noticed that my 7zip caught a CRC error on polargrid.dds, saying that the file is broken. I'll try it anyway.

Ok this appears to be preventing me from placing polar terrain. With the map version that I posted earlier, instead of placing polar it places arid(grass). After testing, my map seems to be functioning normally. I think I need a new version of polargrids.dds as the file seems to have been corrupted.

Here you go.

Here you go.

Hmm, I'm stumped. I have a question, when you use Arrakis.py is it placing polar terrain?

yeah,
maybe just smugglers attacks could be fine - same unit ai as animal , but looks like some smugglers or fremen hostile?

I still want to persuade people that worms swimming through the rock islands is just wrong wrong wrong...

+1
It is bad for fluff, and bad for gameplay.

I still want to persuade people that worms swimming through the rock islands is just wrong wrong wrong...Another ditto. After all, they're sand worms, not rock worms! ;)

Cheers, LT.

Hmm, I'm stumped. I have a question, when you use Arrakis.py is it placing polar terrain?

Nope. Not in the latest version. It was just placing one of the other terrains in the middle instead...

I remember it placing polar in the version before that. I'm not sure but I think they're might be some python that's stopping polar being placed in 1.3.6 ...?

sorry - posted something irrelevant here earlier.


so ill just say,
cephalo, Lord Tirian, Ahriman

thanks for everything you do and helping us.

Keldath, do mind clearing that post out, now that it's posted in the correct place. :)

@Cephalo: If you install this dev patch minus the BonusInfos over straight 1.3 it should work. See if the polar terrain is placed then. I think davidallen might know more about the polar terrain.

Nope. Not in the latest version. It was just placing one of the other terrains in the middle instead...

I remember it placing polar in the version before that. I'm not sure but I think they're might be some python that's stopping polar being placed in 1.3.6 ...?

Yes, that is correct. When Deliverator added the polar terrain it started getting placed by the archipelago mapscript, and we had this whole long conversation about how to stop it. Please locally edit assets/python/DuneWars.py:

def onGameStart(self, argsList): [...]
if iType == self.iTTGrass:
pPlot.setTerrainType(self.iTArid, true, true)
elif iType == self.iTTPlain:
pPlot.setTerrainType(self.iTPlains, true, true)
elif iType == self.iTPolar:
pPlot.setTerrainType(self.iTArid, true, true)


The last two lines shown are converting polar terrain to arid. Remove those two lines and it will stop.

The only other solution is to edit *all* the mapscripts and add these lines at the end:

def normalizeRemoveBadTerrains(): return
def normalizeAddGoodTerrains(): return

The only other solution is to edit *all* the mapscripts and add these lines at the end:

def normalizeRemoveBadTerrains(): return
def normalizeAddGoodTerrains(): return


I think I prefer this. This mod is getting far enough away from normal Civ that custom map scripts should be expected. Dune is just not Earth. A mapscript that tries to make Earth is getting more and more innapropriate as the mod develops.

It's not like we have a lot of mapscripts to maintain. I be honest I think we should clear out the ones we have and just go with Dunipelago and Arrakis (when it is finalised).

Even Continents isn't going to play well with the transport changes.

Anyway, Davids recommendation worked and the new polar terrain looks awsome. I noticed that there is a polar_coast and a polar_ocean now. I can put the polar_coast to work straight away, but do we need the polar_ocean?

Also, that spice is a little shocking. I like the big pile of cinnamon look, but I wonder if there's an alpha channel we can use to make it blend with the terrain a bit?

It's not like we have a lot of mapscripts to maintain. I be honest I think we should clear out the ones we have and just go with Dunipelago and Arrakis (when it is finalised).

That is fine. It can only be done when we cut 1.4. You cannot remove files with a patch. Let us add the two lines to archipelago and remove the other mapscripts. If we find the new arrakis script playable when 1.4 is cut, we can have both in the release.

Ok, I put up a new version that uses the POLAR_COAST. I didn't use the ocean because I'm not sure what to do with it yet.

Cool. Look forward to trying the new version. The polar ocean terrain might be overkill. I just thought it could be used to create a worm line around the polar centre. We can then prevent worms from entering the worm line, meaning that units are safe from worm attack there.

Also, that spice is a little shocking. I like the big pile of cinnamon look, but I wonder if there's an alpha channel we can use to make it blend with the terrain a bit?

Sadly, with the tiled solution we have, using alpha results in the glitches and lines that you can see on the surface of the spice patches. In order to resolve this I may have to go the other way and remove partial transparency completely from the spice tiles.

I've spent many hours trying to get it to look better in all circumstances. It seems you can have a smoother alpha blend with big glitches, or harsh/no blending and no glitches. If alpha overlapping worked the way it logically should then there wouldn't be this problem, but it seems to be a game engine limitation. If someone else wants to take up the challenge, then they're welcome, but I've spent most of the time that I want to spend on one single game element - however key it is.

I downloaded the mapscript, and extracted it into the publicmap folder. But everytime I try to use it, it crashes the game.

To get it working you need patch 1.3.6 (http://forums.civfanatics.com/showpost.php?p=8276339&postcount=129), then the polar terrain patch (http://www.mediafire.com/download.php?y2wjy5dz2lh) from here and the fixed polargrids.dds (http://forums.civfanatics.com/attachment.php?attachmentid=221535&d=1248030176). Sorry for all the files, but this is still a work in progress...

I'll probably include the latest mapscript and all the required changes in patch 1.3.8.

Thnx. I was missing the last 2 files.
Where do I need to put them?
Dont worry about it bieing work in progress.
Im already happy bieing able to play the mod. :)


I keep getting a corrupted polar terrain patch.

The polar terrain patch is applied by copying the dune wars folder over the top of the current one. The polargrids.dds goes in /dune wars/assets/art/terrain/textures/ from memory.

Please note you do not need the arrakis mapscript to play the game. The mod comes with a number of mapscripts, and most people play with the archipelago script.

@Greeneyedzombie: Probably best of waiting for 1.3.8, I'll include whatever the latest version of Arrakis.py is then.

Please note you do not need the arrakis mapscript to play the game. The mod comes with a number of mapscripts, and most people play with the archipelago script.

I know.

@Greeneyedzombie: Probably best of waiting for 1.3.8, I'll include whatever the latest version of Arrakis.py is then.

I finally got a working dowlnoad.

Started a few games with the arrakis script and quite often civs start paired right next to each other.

Started a few games with the arrakis script and quite often civs start paired right next to each other.

I will make a new starting plot finder when I have a better idea of exactly how it should be handled.

I will make a new starting plot finder when I have a better idea of exactly how it should be handled.

I don't know the details of how starting plots are chosen normally. But, if the pole terrain is valuable, every civ must start the same distance away. So, how about restricting start locations to a donut at a certain radius from center, and then more or less spacing them equally around the circle? So a six player game would have one civ roughly every 60 degrees around the circle.

This would produce a game where you can initially affect exactly two other civs, but once you can travel rapidly over sand, you can reach all the other civs. I am not sure if any of the existing mapscripts have this particular orientation.

There are Ring and Donut and Inland Sea mapscripts which I think all have a somewhat similar idea to this.

Well, hopefully this will end up being more interesting than those examples and more tailored to this mod.

I don't know the details of how starting plots are chosen normally. But, if the pole terrain is valuable, every civ must start the same distance away. So, how about restricting start locations to a donut at a certain radius from center, and then more or less spacing them equally around the circle? So a six player game would have one civ roughly every 60 degrees around the circle.

This would produce a game where you can initially affect exactly two other civs, but once you can travel rapidly over sand, you can reach all the other civs. I am not sure if any of the existing mapscripts have this particular orientation.

Yeah, I'll probably do something along these lines.

Something wich might prevent civs starting in the desert is to make impossible to build cities on dunetiles.

Something wich might prevent civs starting in the desert is to make impossible to build cities on dunetiles.

Yeah this should probably be done if possible.

There is a <bFound> tag in Civ4TerrainInfos which apparently determines whether it's possible to found a city on the terrain. I'll try it out.

I am planning to include this script in the 1.3.8 patch. We need to change the Archipelago script so that the terrain changes made for Arrakis.py don't effect it.

I think this comes down to two things:

1) Use the code so that POLAR is not placed at the starting locations. Ideally, polar should appear at the top and bottom of Archipelago I guess.
2) The DESERT terrain is no longer a normal land terrain, it is being rebranded as Dunes , will have no yield and it will not be possible to build a city on it. Therefore this terrain should not be placed by the Archipelago mapscript.

Is someone able to do this, or point me to the lines in the Python and tell me what to change?

Discussion at this post (http://forums.civfanatics.com/showpost.php?p=8259499&postcount=73) and this post (http://forums.civfanatics.com/showpost.php?p=8279468&postcount=138). Please add the lines:

def normalizeRemoveBadTerrain(): return
def normalizeAddGoodTerrain(): return

To the end of all the mapscripts in publicmaps. Since your patch will presumably install over 1.3, there is no way to remove the mapscripts included in 1.3; we can do that in 1.4. It is your call whether to change the other mapscripts or just document that they can no longer be used.

You will also have to include your locally changed DuneWars.py; I believe you must have followed my previous suggestion to delete two lines from onGameStart if you are able to see polar ice at all in your runs. See this post (http://forums.civfanatics.com/showpost.php?p=8279468&postcount=138) if you do not recall the change.

EDIT: regarding desert, I cannot locate the post, but we discussed this previously also. I believe that this terrain will never be placed, because it has no benefit. If you see it in your tests, we can discuss how to change DuneWars.py to remove this terrain instead of removing the polar ice terrain. But it is less clear what terrain to put instead.

I am planning to include this script in the 1.3.8 patch. We need to change the Archipelago script so that the terrain changes made for Arrakis.py don't effect it.

I think this comes down to two things:

1) Use the code so that POLAR is not placed at the starting locations. Ideally, polar should appear at the top and bottom of Archipelago I guess.
2) The DESERT terrain is no longer a normal land terrain, it is being rebranded as Dunes , will have no yield and it will not be possible to build a city on it. Therefore this terrain should not be placed by the Archipelago mapscript.

Is someone able to do this, or point me to the lines in the Python and tell me what to change?

Adding the POLAR terrain can be done in the XML if you equate the settings to how tundra is used in the normal game. The POLAR_COAST will require some fixer routines, there's not likely any code in there to place an alternate coast type.

To prevent normalization, use the code that david mentioned to bypass normalizeAddGoodTerrain et al.

I would do it but I'm just getting ready for a big long family vacation! I'll be out of commision for about a week and a half.

The Arrakis mapscript has gone live in the 1.3.8 patch. However, it has a problem. In most games, pairs of civs start right next to each other. Start a huge game and autoplay one turn (or just click "next turn"), then ctrl-z to view all and zoom out to globe view. This will enable you to see all the cities. Many times, there are 2-3 pairs of civs which are immediately adjacent.

This is annoying, but there is a fatal result. Very often, the civs start so close to each other that one civ's settler starts in the same square as another civ's soldier. This results in the settler surrendering and the civ being destroyed on turn 0. This does not happen in every game; but if you create several huge games I guarantee you will see it at least once. In one game, I had 3 out of 11 civs immediately destroyed. I am pretty sure this is due to adjacent start points.

Is it possible to update the mapscript to ensure a min separation between the civ starting locations?

The Arrakis mapscript has gone live in the 1.3.8 patch. However, it has a problem. In most games, pairs of civs start right next to each other. Start a huge game and autoplay one turn (or just click "next turn"), then ctrl-z to view all and zoom out to globe view. This will enable you to see all the cities. Many times, there are 2-3 pairs of civs which are immediately adjacent.

This is annoying, but there is a fatal result. Very often, the civs start so close to each other that one civ's settler starts in the same square as another civ's soldier. This results in the settler surrendering and the civ being destroyed on turn 0. This does not happen in every game; but if you create several huge games I guarantee you will see it at least once. In one game, I had 3 out of 11 civs immediately destroyed. I am pretty sure this is due to adjacent start points.

Is it possible to update the mapscript to ensure a min separation between the civ starting locations?

Unfortunately I'll be leaving for vacation tommorow. I have no idea why this would be happening with the default starting code unless there was a real crowding problem. Are the maps just too small?

Unfortunately I'll be leaving for vacation tommorow. I have no idea why this would be happening with the default starting code unless there was a real crowding problem. Are the maps just too small?

Seems like there is a huge amount of empty space. I guess we will keep using archipelago for now; have a good vacation!

Seems like there is a huge amount of empty space. I guess we will keep using archipelago for now; have a good vacation!

Another thing I should say is that I have not done any testing with the size of maps other than standard, the sizes that I set for other maps are basically arbitrary right now. On a standard map, I'm not seeing these problems to the degree you mention.

Really? It actually seems worse on standard size compared to huge. I just did three standard maps, and had 4/7, 4/7, 3/7 players start dead. Are you using patch 1.3.8? The resource distribution is quite different compared to previous patches, and it is possible that has somehow made the problem worse.

Really? It actually seems worse on standard size compared to huge. I just did three standard maps, and had 4/7, 4/7, 3/7 players start dead. Are you using patch 1.3.8? The resource distribution is quite different compared to previous patches, and it is possible that has somehow made the problem worse.

Dang, I'm out of time. We'll have to wait a week on this.

If you generate a Large Arrakis.py map, the overlapping starts issue doesn't seem to occur. I tried running a game on autorun but the game crashed at around 250 turns or so. I did notice that performance was much slower than Huge Archipelago which is interesting.

Not sure what all that means...

If you generate a Large Arrakis.py map, the overlapping starts issue doesn't seem to occur. I tried running a game on autorun but the game crashed at around 250 turns or so. I did notice that performance was much slower than Huge Archipelago which is interesting.

Not sure what all that means...

The fact that the map is larger, and also complex in terms of pathfinding, might really make a difference on a map like this. Don't worry, I'll fix everything when I get back.

Ok, I'm back from vacation, and I need some pointers on the current patch progression. I think I am using 1.3.6.

Welcome back! The latest patch is at this link (http://forums.civfanatics.com/showpost.php?p=8313565&postcount=186).

I think the key enhancement needed is understanding the start positions. Many civs start with their settlers on top of other civs' soldiers, leading to instant death. Also you mentioned you might need a new algorithm for the shield wall.

Welcome back cephalo.

I have a question. Do you know whether the sea level can be changed? Since I made the water layer invisible, units are hovering in space slightly, rather than walking on the sea bed/desert floor. It would be great if there was a fix for this.

Welcome back cephalo.

I have a question. Do you know whether the sea level can be changed? Since I made the water layer invisible, units are hovering in space slightly, rather than walking on the sea bed/desert floor. It would be great if there was a fix for this.

Is there some hard coded constant in the nifs and stuff? Really, this sort of thing I have not investigated.

Ok, I have a new version up. Civs still start too close together, but at least they are there.

I *think* the problem is that hills are evaluated much higher than groundwater. Here is some debug output from my plot evaluation code, which was patterned after the default code in the SDK.

The first example is a plot with a groundwater bonus, and the second is a plot with a hill.


************************************************** **************

Evaluating plot x = 54, y = 16

Natural yields. Food=0, Production=1, Commerce=1

Bonus Type = BONUS_GROUNDWATER <------------------------------------------------------------

Bonus yields. Food=1, Production=1, Commerce=1

Tech is high enough for IMPROVEMENT_IRRIGATION

Plot can have IMPROVEMENT_IRRIGATION

Improv yields. Food=0, Production=0, Commerce=0

Tech is high enough for IMPROVEMENT_GROWTH

Plot can not have IMPROVEMENT_GROWTH

Tech is high enough for IMPROVEMENT_GREEN

Plot can not have IMPROVEMENT_GREEN

Tech is high enough for IMPROVEMENT_MINE

Plot can have IMPROVEMENT_MINE

Improv yields. Food=0, Production=1, Commerce=0

Tech era not high enough for IMPROVEMENT_MINE2

Tech era not high enough for IMPROVEMENT_MINE3

Tech era not high enough for IMPROVEMENT_SOLARFARM

Tech era not high enough for IMPROVEMENT_WINDMILL

Tech era not high enough for IMPROVEMENT_WINDMILL2

Tech era not high enough for IMPROVEMENT_WINDMILL3

Tech is high enough for IMPROVEMENT_PLANTATION

Plot can not have IMPROVEMENT_PLANTATION

Tech era not high enough for IMPROVEMENT_QUARRY

Tech is high enough for IMPROVEMENT_CAMP

Plot can not have IMPROVEMENT_CAMP

Tech is high enough for IMPROVEMENT_COTTAGE1

Plot can have IMPROVEMENT_COTTAGE1

Improv yields. Food=0, Production=0, Commerce=1

Tech era not high enough for IMPROVEMENT_OUTPOST

Tech era not high enough for IMPROVEMENT_FORT2

Tech is high enough for IMPROVEMENT_WINDTRAP

Plot can not have IMPROVEMENT_WINDTRAP

Tech era not high enough for IMPROVEMENT_FISHING_BOATS

Tech is high enough for IMPROVEMENT_DESERTREFINERY

Plot can not have IMPROVEMENT_DESERTREFINERY

Tech era not high enough for IMPROVEMENT_SHALLOW_WELL

Tech era not high enough for IMPROVEMENT_DEEP_WELL

Tech era not high enough for IMPROVEMENT_QANAT_SYSTEM

bestImp.value=220

Evaluating. Food=1, Production=2, Commerce=1

Final Value = 220

************************************************** **************

Evaluating plot x = 55, y = 17

Natural yields. Food=0, Production=2, Commerce=1

Tech is high enough for IMPROVEMENT_IRRIGATION

Plot can not have IMPROVEMENT_IRRIGATION

Tech is high enough for IMPROVEMENT_GROWTH

Plot can not have IMPROVEMENT_GROWTH

Tech is high enough for IMPROVEMENT_GREEN

Plot can not have IMPROVEMENT_GREEN

Tech is high enough for IMPROVEMENT_MINE

Plot can have IMPROVEMENT_MINE

Improv yields. Food=0, Production=1, Commerce=0

Tech era not high enough for IMPROVEMENT_MINE2

Tech era not high enough for IMPROVEMENT_MINE3

Tech era not high enough for IMPROVEMENT_SOLARFARM

Tech era not high enough for IMPROVEMENT_WINDMILL

Tech era not high enough for IMPROVEMENT_WINDMILL2

Tech era not high enough for IMPROVEMENT_WINDMILL3

Tech is high enough for IMPROVEMENT_PLANTATION

Plot can not have IMPROVEMENT_PLANTATION

Tech era not high enough for IMPROVEMENT_QUARRY

Tech is high enough for IMPROVEMENT_CAMP

Plot can not have IMPROVEMENT_CAMP

Tech is high enough for IMPROVEMENT_COTTAGE1

Plot can not have IMPROVEMENT_COTTAGE1

Tech era not high enough for IMPROVEMENT_OUTPOST

Tech era not high enough for IMPROVEMENT_FORT2

Tech is high enough for IMPROVEMENT_WINDTRAP

Plot can have IMPROVEMENT_WINDTRAP

Improv yields. Food=4, Production=0, Commerce=2

Tech era not high enough for IMPROVEMENT_FISHING_BOATS

Tech is high enough for IMPROVEMENT_DESERTREFINERY

Plot can not have IMPROVEMENT_DESERTREFINERY

Tech era not high enough for IMPROVEMENT_SHALLOW_WELL

Tech era not high enough for IMPROVEMENT_DEEP_WELL

Tech era not high enough for IMPROVEMENT_QANAT_SYSTEM

bestImp.value=180

Evaluating. Food=4, Production=2, Commerce=3

Final Value = 720

Would removing irrigation help? Since it adds no value in the current design, but could be messing up the plot value evaluation.

Would removing irrigation help? Since it adds no value in the current design, but could be messing up the plot value evaluation.

The problem is that a windtrap on a hill results in 4 food, 2 prod and 3 commerce, while the groundwater provides only 1 food, prod, commerce with starting era technology.

I would expect this to be a problem with other maps as well.

Tech era not high enough for IMPROVEMENT_SHALLOW_WELL

Why is this? Both SHALLOW_WELL and WINDTRAP are ERA_ANCIENT. Would it help if we moved SHALLOW_WELL to the lowest tech tier?

Why is this? Both SHALLOW_WELL and WINDTRAP are ERA_ANCIENT. Would it help if we moved SHALLOW_WELL to the lowest tech tier?

It should be driven by era. Also, I'm using 1.3.6 I believe, maybe you guys have fixed it since then?

Something to note in 1.3.6: the "shallow well" in theory was granted by a tech several lines down, but this never showed up anywhere; it was NOT the level 1 well buildable on a groundwater resource, which had no tech requirement at all.

Why is this? Both SHALLOW_WELL and WINDTRAP are ERA_ANCIENT. Would it help if we moved SHALLOW_WELL to the lowest tech tier?

Wait a minute, I found something in my code that was meant for using PerfectWorld with FfH that disqualified build infos that had no tech requirement. That way non buildable 'special' improvements (i.e. Pool of Tears) didn't affect the value. Well, let me take that out and see what happens.

It should be driven by era. Also, I'm using 1.3.6 I believe, maybe you guys have fixed it since then?

Well, there is some philosophical debate on the "A mod-mod: Dune Wars Reduced" thread, but the current version is 1.4.1 from this post (http://forums.civfanatics.com/showpost.php?p=8330822&postcount=47). You would also need 1.4 from this post (http://forums.civfanatics.com/showpost.php?p=8327057&postcount=21). Could you locally try moving shallow well to the lowest tier and see if that makes the results better?

Well, there is some philosophical debate on the "A mod-mod: Dune Wars Reduced" thread, but the current version is 1.4.1 from this post (http://forums.civfanatics.com/showpost.php?p=8330822&postcount=47). You would also need 1.4 from this post (http://forums.civfanatics.com/showpost.php?p=8327057&postcount=21). Could you locally try moving shallow well to the lowest tier and see if that makes the results better?

I fixed the actual problem with the buildinfo that requires no tech, (in BtS, all buildinfos require tech so there was no issue), but now I have a bunch of issues with the very small continents having less starting locations than players. I'll have to work on this a bit.

Very small islands is a problem on its own. Did you compare the average size of your islands against the average size of vanilla archipelago islands? Earlier in the thread I commented that vanilla ocean plots are still pretty useful compared to dune wars ocean plots; so small islands where most of your bfc is water will be a really crummy start for dune wars. Maybe the islands should be bigger.

We still need to implement the ice extractor improvement and associated wonder to coincide with the next working release of this mapscript.

I agree. In 1.4.2 I used your harvester concept art to make a button for the harvester build action. This frees up the oil rig icon to use for the Ice Drilling improvement. Do we agree that "+1 water in every city" is the right building to use the resource? Or should it be something like "+2 water in this city"?

Should the archipelago mapscript also be changed so that all this "stone rock" in the polar regions becomes ice? The possible problem with that is some civs may have a starting position far from the ice, and they will be shut out.

The possible problem with that is some civs may have a starting position far from the ice, and they will be shut out.

I don't think this is a problem; the civs far from the equator get the mesa/rock terrain, whereas civs near the poles get much more of the very bad broken/badlands terrain. Anything that mitigates the fact that polar starts are worse would be useful.

Ok, here's a better version, the starts are somewhat more sensible.

I'm having alot of trouble with the trade-off between small islands and a map that looks good. I guess it would be ideal if every civ had it's own continent, but that would require something very different than what I'm currently doing. I kinda wish that the mod was more like bts, and that you only need transport to cross ocean. Larger continents look a lot better.

I kinda wish that the mod was more like bts, and that you only need transport to cross ocean. Larger continents look a lot better.

I am confused. Currently this mod is exactly like the bts archipelago mapscript; you only need transport to cross ocean, but there is ocean everywhere.

However, we could certainly discuss some other approach if you like.

I am confused. Currently this mod is exactly like the bts archipelago mapscript; you only need transport to cross ocean, but there is ocean everywhere.

However, we could certainly discuss some other approach if you like.

Maybe I'm just out of date with the info, but I thought that having large continents on the map would put the AI at a huge disadvantage, as it won't use transport to travel on the same continent. Jeez, I don't even remember why that was a problem lol.

Oh, I misunderstood your point. I think the goal is to have islands that are roughly the same size as archipelago. With the current setup, you are right that large continents would be bad. The reason is that the AI will only use transports to bring units from one island/continent to another. It will never use transport to move units around on the same island/continent, even when that would be much faster. In DW this is more of a problem because our transports can move on both ocean and land, so it would be very handy to use fast transport to move units around a continent.

So large continents would indeed put the AI at a disadvantage.

The reason is that the AI will only use transports to bring units from one island/continent to another. It will never use transport to move units around on the same island/continent, even when that would be much faster.

Yet another reason for roads! :-)

how about road just on certain tiles?

I also really like my idea of roads not buildable on rugged, dunes, hills or peaks. This would help to still make terrain matter and still be an obstacle. So you can easily patrol and defend your flatlands civilised areas with cottages and the like, but the harsher terrain still feels different.
:-)
Great minds.

Do we agree that "+1 water in every city" is the right building to use the resource? Or should it be something like "+2 water in this city"?

How about a ordinary building that gives +1 water everywhere and a world wonder that gives a further +1 everywhere?


Should the archipelago mapscript also be changed so that all this "stone rock" in the polar regions becomes ice? The possible problem with that is some civs may have a starting position far from the ice, and they will be shut out.

I reckon try it and see how it plays. You could customize the mapscript further to try and ensure everyone is a similar distance from the poles.

It would be great if the Archipelago mapscript has some means of encouraging settlement at the poles, rather than punishing it. The badlands/rugged terrain are terrible, and cities who start in them currently get screwed, whereas in reality the closer to the poles you are the weaker the winds are, the cooler the temperatures, the more water, and the smaller the worms.

Another though; is it possible (or already existent) to make the sandstorms spawn dependent on latitude? That would be nice if the big nasty storms couldn't spawn in the polar regions.

Those are both good suggestions for the archipelago mapscript. It is a little awkward to maneuver both mapscripts since they have different key terrain types. At some point, I may simplify the terrain types a little, which will involve tweaking arrakis.py a little. Then both can have ice. I like the idea of fewer storms near the north and south edges, but I am not sure that will make up for the awfulness of rugged.

Well, how would you feel about flipping the mapscripts; make the default be a large polar region script with lots of tundra and ice, and then have the vanilla plains and grassland be rugged and badlands, and vanilla tundra and ice be mesa and rock?

So the equator has dunes, badlands and rugged, while the poles have mesa and rock and ice, and tweak the placement scripts so that humans start in either the temperate zones or poles rather than the tropics.

Also: I just started re-reading Dune last night, and they talk about the people of "graben, sink and pan" as opposed to the people of the desert (Fremen). Maybe we should do some renaming of rock/badlands/mesa/rugged?

http://en.wikipedia.org/wiki/Graben
http://en.wikipedia.org/wiki/Hardpan

I was trying out the latest Arrakis.py and I've got a CTD. Here are two saves. I'm using dune reduced 1.4.4. Can people see if they can autoplay 100 turns or so without a crash?

I don't know if this is the sporadic crash reported in the modmod thread or something to do with the mapscript? Cephalo said something about pathfinding being more intensive.

I always get ctd's after 100-200 turns with this mapscript.

Greeneyedzombie hi,

just a quastion - are you playing 1.3? or the reduced?

Both. but mostly reduced, since that seems to be the future dune.

I always get ctd's after 100-200 turns with this mapscript.

Me too. Sometimes earlier.

I really don't think the mapscript would cause a crash 100 turns into the game. Are you guys playing on Huge? Do you not get crashes on Archipelago?

I was playing Large. I can't recreate the crash on Archipelago. It may be that this mapscript just makes whatever circumstance is causing the crash more likely. I've noticed turns are really quite slow too. Perhaps it's something to do with spice blows and vast expanse of deep desert in this mapscript?

I was trying out the latest Arrakis.py and I've got a CTD. Here are two saves. I'm using dune reduced 1.4.4. Can people see if they can autoplay 100 turns or so without a crash?

In fact, I get a crash as soon as I load either of your games, or as soon as the first turn finishes. This is because of unset variables such as sXMLNationalism. This is caused by having the Revolutions option turned on. Did you know that you were playing with these options?

It is time to actually fix revolutions so it doesn't crash. The trick is that it refers to individual tech names, and we are in the process of rewriting the tech tree. So the tech tree will have to stabilize a little first. Once keldath posts 1.4.5, I will update revdefs.py so it will not crash. Still, removing revolutions would be a better idea.

I was playing Large. I can't recreate the crash on Archipelago. It may be that this mapscript just makes whatever circumstance is causing the crash more likely. I've noticed turns are really quite slow too. Perhaps it's something to do with spice blows and vast expanse of deep desert in this mapscript?

This map does have alot more deep desert than Archipelago. If there's alot of stuff happening to each deep desert tile, it's possible that it's just too much. If that is the case, you would find the problem much more pronounced on a huge map, and less pronounced on a smaller map. Sorry I can't test these things, I've been very busy lately.

I have tested the relative runtime of arrakis vs archipelago. I have found two things.

1. The number of squares on the arrakis map is much larger. For example a large arrakis is 128x128, a large archipelago is 104x64. That is 2.2x as many squares, therefore we should "expect" the runtime to be 2.2x slower. That is not precisely true, but that probably accounts for longer runtime of pathfinding, checking every plot on the map, etc. If the runtime were 2.2x slower, we would probably have to accept that. I am not sure if the arrakis map *needs* to be that much larger; maybe 104x104 instead of 128x128 would still be enough, and it would only be 1.6x larger.

2. Still, I have found one part of the python which is increasing runtime. On a large map with no python changes, arrakis takes almost 3x longer than archipelago. When I turn off the routine which upgrades the terrain based on Reservoir of Liet, it is only 2.1x slower. Therefore, the terrain upgrading routine is causing the slowdown. I will investigate this to find a more efficient way to do it.

So, it is definitely slower; we can recover some by making the map size closer to archipelago, and some more if I rewrite the terrain upgrader.

This does not shed any light on the occasional crashes, but at least Deliverator's are caused by the revolutions game options.

Therefore, the terrain upgrading routine is causing the slowdown.

I'd love to see the terrain upgrader happen more slowly (ie lower probability chance of change per turn) and to eventually be able to cycle other terrain types in too, so rugged/Dunes don't remain completely useless.

I'd love to see the terrain upgrader happen more slowly (ie lower probability chance of change per turn) and to eventually be able to cycle other terrain types in too, so rugged/Dunes don't remain completely useless.

In 1.4.2 the terrain upgrades much more slowly than 1.4 or 1.4.1. Do you still find it too fast? As I mentioned earlier, to upgrade multiple terrain types I need more infrastructure to remember the original terrain type so it can downgrade to the original level if the catchbasin or improvement is destroyed. I'll do it, with lower priority.

In 1.4.2 the terrain upgrades much more slowly than 1.4 or 1.4.1. Do you still find it too fast? As I mentioned earlier, to upgrade multiple terrain types I need more infrastructure to remember the original terrain type so it can downgrade to the original level if the catchbasin or improvement is destroyed.

I think its slightly too fast, but I probably need to play more before being certain.

Agree that its not high priority.

What exactly does the Reservoir of Liet do? Does it need to examine the whole planet every turn?

You can read about the catchbasin and reservoir of liet in the civilopedia, dune wars concept tab, terraforming topic. I added highlights of this for the catchbasin xml help, but it is missing for the reservoir. It does look at the whole map once, but I am not sure which part is slow yet. In the city's BFC, it destroys spice and allows territory with improvements to upgrade its terrain type. Also, as part of the check, it looks to see if any previously upgraded territory has to be downgraded; for example, if a catchbasin was destroyed when a city was attacked, any territory which it upgraded needs to be downgraded. Since there is a random % chance per turn to downgrade, the whole map has to be checked.

I will have to cache this information somehow, but I haven't studied it very carefully yet.

Is there any way that you could store cities which have ever had a catchbasin or reservoir, and then check only the tiles in the BFCs of those cities? That would save you from having to do a global tile scan.

Another idea:
The AI often does really bad city placement for its capital, which cripples its development. I think the biggest single reason for this is that the AI is enticed by the spice resource tiles and so tries to include those in its BFC, when those are really only transient.

So is it possible to adjust the mapscript so that the spice resource is not generated during the map generation at all, and then create on turn 1 a ton of spice blows all over the map (by a one-off event?) that will then blow up on the next few turns seeding the planet with spice?
Slightly unrealistic, but the player will barely notice, and it could lead to much better AI capital placement.

Alternatively, is there any way to get the AI to ignore the spice resource when evaulating tiles for city placement?

Is there any way that you could store cities which have ever had a catchbasin or reservoir, and then check only the tiles in the BFCs of those cities? That would save you from having to do a global tile scan.

Thanks for the suggestion. The problem here is that the terraforming degrades when a catchbasin is *destroyed* or also if an improvement on the square is pillaged. So the entire map must be scanned. I will have to study it a little more.

The AI often does really bad city placement for its capital, which cripples its development. I think the biggest single reason for this is that the AI is enticed by the spice resource tiles and so tries to include those in its BFC, when those are really only transient.

The initial city locations are chosen in the mapscript. The spice is added later, in the GameStart function. So I don't think poor initial city location can be "blamed" on spice. I don't really know how the vanilla mapscripts (including our archipelago) actually select initial city locations. Maybe cephalo can comment on how his new mapscript selects initial city locations. I would be surprised if the vanilla routines could choose wisely for DW; hills and peaks have a large value due to windtraps, but you should also take into account the one tile spacing requirement to be really optimal.

Thanks for the suggestion. The problem here is that the terraforming degrades when a catchbasin is *destroyed* or also if an improvement on the square is pillaged. So the entire map must be scanned. I will have to study it a little more.


Note quite what I meant; I didn't mean store the location of cities that *currently* have a catchb/reservoir; that wouldn't work because you need to downgrade for cities where the building no longer exists (eg because of change of civic), I meant make a store of the location of cities that have *ever* had a catb/reservoir.
So have some array that is empty at game start, and whenever a catchb/res is built, take the tile location of that city and add it to the array. And tiles are never removed from the array.

[store the tile location rather than the city because the city could get razed and leave terraformed tiles around it]

So all you ever have to do is scan the tiles of the BFC surrounding each member of the array each turn, and check if they are terraformed but do not have an improvement, and if so then downgrade them.
This should work, because it is impossible for a tile to ever have been terraformed if it was not in the BFC of a city that once had a catchb/res. You never need to degrade any tile that *wasn't* in the BFC of a tile listed in the array.

The spice is added later, in the GameStart function. So I don't think poor initial city location can be "blamed" on spice.

Are you sure? I thought that the mapscript chooses the location for the starting settler, not the location for their capital; couldn't the AI move 1 tile in any direction before settling on the first turn? Or do they always settle on their starting tile?
If they always settle on their starting tile then you are correct, but if they begin with their starting units and *then* try to choose an "optimal" city site on the first turn then they can be encouraged by spice to move towards the coast and settle there, rather than inland slightly with more potential for hills.

Or do they always settle on their starting tile?

This. The only reason why ai would move before founding a city is if starting plot doesn't allow to found one.

Perhaps I can do the terraforming check only in the BFC of every city; that may be a sufficient speedup.

I thought that the mapscript chooses the location for the starting settler, not the location for their capital

OK, you are right. jdog5000, the Better AI guy, has pointed out that when you are in ctrl-z mode, you can see colored circles which are acceptable settler locations for the AI. Koma has looked into this a little to change the minimum acceptable value to make distant colonies easier. But this routine would need to be customized to value hill/peak highly. Perhaps at the same time, we could investigate whether spice was exerting a big influence on the choice.

(EDIT: koma knows better, see his immediately previous post.)

But putting the spice slightly later doesn't really help this part of the code, because every city (not just the first one) is chosen by this code. Also, the spice decays pretty slowly now, so valuing plots with spice "now" may not be such a bad idea.

The capital city placement is much more important than later ones.
But if the AI always settles on its starting tile then the no-spice-in-mapscript idea would do nothing.

Perhaps I can do the terraforming check only in the BFC of every city; that may be a sufficient speedup.


Of course, the city might be razed, but even so, this seems like a great candidate for some pre-processing. Any time a tile get's upgraded, put it in a list for possible downgrading, then just check that list.

EDIT: and of course remove it from the list upon downgrading.

Of course, the city might be razed, but even so, this seems like a great candidate for some pre-processing. Any time a tile get's upgraded, put it in a list for possible downgrading, then just check that list.

EDIT: and of course remove it from the list upon downgrading.

Yes, and then pack/save the list upon save game, unpack or rebuild upon load, all that fun infrastructure. Good point about razing however.

I agree. In 1.4.2 I used your harvester concept art to make a button for the harvester build action. This frees up the oil rig icon to use for the Ice Drilling improvement. Do we agree that "+1 water in every city" is the right building to use the resource? Or should it be something like "+2 water in this city"?

Should the archipelago mapscript also be changed so that all this "stone rock" in the polar regions becomes ice? The possible problem with that is some civs may have a starting position far from the ice, and they will be shut out.


I have made some local changes for ice and an ice building.

* Changed archipelago mapscript so that the top and bottom rows are "polar" land terrain with some ice resources. I added polar coast as appropriate but no polar ocean; at least this is a start.
* Removed "stone rock" which clutters up the polar regions of the archipelago mapscript
* Added "ice extractor" improvement, buildable on ice resource, uses vanilla offshore drilling station graphics.
* Added worker action "build ice extractor" under "water transport" tech
* Added Ice Souk building (copy/paste of Water Souk) which requires ice bonus and gives +25% water yield in the city. I can have it give a different bonus, maybe +2 water instead of +25%; the + % seems better since it should help in the midgame where the numbers are larger.

I didn't add a national wonder; you need to build a building in each city to get the benefit. What do you think?

Seems reasonable.
How about we rename the current Market as Water Souk, and then make this one "Ice Trader"?

We could also consider recreate the water-seller's guild corporation (either as a standard corp or a buildable wonder) that turned excess ice resources into gold. Will depend on how many resources you can feasibly build.
Seems like the ice extractor should also have a decent commerce tile yield bonus?

Did you consider any of the ideas from post 198?

Well, how would you feel about flipping the mapscripts; make the default be a large polar region script with lots of tundra and ice, and then have the vanilla plains and grassland be rugged and badlands, and vanilla tundra and ice be mesa and rock?

So the equator has dunes, badlands and rugged, while the poles have mesa and rock and ice, and tweak the placement scripts so that humans start in either the temperate zones or poles rather than the tropics.

Also: I just started re-reading Dune last night, and they talk about the people of "graben, sink and pan" as opposed to the people of the desert (Fremen). Maybe we should do some renaming of rock/badlands/mesa/rugged?

http://en.wikipedia.org/wiki/Graben
http://en.wikipedia.org/wiki/Hardpan

How about we rename the current Market as Water Souk, and then make this one "Ice Trader"?

And then to make the circle complete, we should rename the existing water souk as market, I guess. Do you like "trader" better than "souk"? Or is there some fourth name we could add?

We could also consider recreate the water-seller's guild corporation (either as a standard corp or a buildable wonder) that turned excess ice resources into gold. Will depend on how many resources you can feasibly build. Seems like the ice extractor should also have a decent commerce tile yield bonus?


I was thinking that ice added to your food, not your commerce. When we do more playtesting, perhaps we can decide whether we have too much or too little food and commerce.

We have gotten rid of all the corps for now; is there a strong reason to add back one?

Did you consider any of the ideas from post 198?

I made a hack in the archipelago mapscript to change the top and bottom rows. I don't really understand how it works. You have some good ideas, but I think our long term goal should be to use the arrakis mapscript in this thread, and discard archipelago.

And then to make the circle complete, we should rename the existing water souk as market, I guess. Do you like "trader" better than "souk"? Or is there some fourth name we could add?

Oh, and I meant drop the current water souk building. Its boring, just a flat gold bonus. The market and bank (rename Guild Bank) already do that.

I was thinking that ice added to your food, not your commerce.
Sure, sounds good.

but I think our long term goal should be to use the arrakis mapscript in this thread, and discard archipelago.

Hmm. Ok.

I like Water Shipper rather than Trader. Book quote: 'a water-shipper whose summer mansion was near his polar-cap factory'. Ice Souk sounds wrong, because it is water that is sold.

I think rather than doing a water percentage which seems a bit weird, creating a Water Shippers corp would be a good thing. I don't advocate having many corps - perhaps this will be the only non-spice one. Corporate branches would produce a yield of water dependent on the number of a bonus that that city has access to. +1 water per Ice might be a good level. Sid Sushi had +0.75 per seafood, but also produced culture. We could maybe add a small +0.25 gold per Ice too. If we set this up for the Ice Bonuses then grabbing a large number of ice resources will be a strategy for growth. We should probably set iAIObjective = 1 for Ice.

I think water +% buildings should be better water retention and transportation facilities to keep the link between theme and function strong.

I like water shipper as a name, but I see a problem with it *only* being a corp. Unless you create an individual corp for each faction, then only 1 faction (the founder) will get any benefit at all from the ice resource unless they choose to spread it to other players, which seems weak.

If you do go with a corp, tuning the bonus will need to depend on resource availability. Sid's sushi etc. only gives a bonus for water tiles with a bonus resource (and rice bonus); but if you can get an ice resource from *every single* polar tile then it could be too easy to get a big bonus.

But I see no problem as with a %water bonus Water Shipper Building either, its a good simple way to make sure that everyone who gets some ice can benefit. And I think the theme/function is very direct; if you have polar ice, then then you can import more water for your faction and so have more water income than you would have locally from groundwater/dew collectors/windtraps. If you don't have polar ice, no extra water. You can get more water in a city *either* by being more efficient wi the water you have, or by getting more.
Easy enough to cut the water bonus to say 15% if you think 25% is too strong, or make it say +3 water rather than +%.

The polar terrain has an ice resource only on certain plots, just like grass has a wheat resource only on certain plots. So a given player might have 1-2 ice resources available. The original goal was to have a very limited number of ice resources in the center of the map, and have players fight over ownership. We will have to see how this actually works on the arrakis map. On the archipelago map, it compensates a little for extreme north or south start positions, which have a lot of rugged terrain.

I agree with Ahriman that setting up N corps, one for each civ, is a little messy, and the benefit of the corp mechanic seems relatively small.

Vanilla has market and grocer at a similar tech level; in 1.4.4 we have market and water souk. I will change market to "water shipper" which requires ice and gives +25% water instead of +25% gold.

This sounds good to me. I agree that it is going to be difficult to get this to work on the Arrakis script; it seems like it will be too easy for a single player to monopolize all the ice, but its probably good for the Archipleago scripts.

If only some polar tiles have an Ice resource, will at least all polar tiles have some water tile yield? What improvements can be constructed on Polar?

If only some polar tiles have an Ice resource, will at least all polar tiles have some water tile yield? What improvements can be constructed on Polar?

You can get the mapscript from the first post in the thread and try it out. No coding required. It seems to work pretty well now.

OK, I'll go with that solution. It would be nice if we could make the bonus scale with the amount of ice you control like corporations, but that would need some custom code. As it is you only need a single ice resource.

Polar terrain had +2 water last time I checked - it is the equivalent of grassland. I think all improvements should be buildable on Polar. On Arrakis, the polar terrain is much more tolerable than the rest of the planet.

@ Cephalo, I think we have gotten very close to a "production" version of the mapscript. There is one big problem, one enhancement, and one preference.

DA52. The big problem is with start positions too close together. You have improved this a little, but it still happens often that I start within 4-5 squares of another civ. This is not fatal, like it used to be when my settler and his soldier overlapped, but it does make for a very difficult start. Can you make sure the starting locations are further apart?

DA53. The enhancement is for a shield wall. Maybe this is not necessary, but I think if most readers think of important geographical features of Dune, this is one of the first to come to mind.

DA54. The preference is that I feel the maps are *too* large. On the large setting, a normal map is 64x104, and your map is 128x128. This is almost 2.5x the area. If there were a lot of interesting things to explore, that would be one thing; but Dune does not have much geographical variety. So I would prefer to make the maps smaller. Say, 104x104 for large.

(EDIT: retrofitting bug report numbers for tracking)

@ Cephalo, I think we have gotten very close to a "production" version of the mapscript. There is one big problem, one enhancement, and one preference.

The big problem is with start positions too close together. You have improved this a little, but it still happens often that I start within 4-5 squares of another civ. This is not fatal, like it used to be when my settler and his soldier overlapped, but it does make for a very difficult start. Can you make sure the starting locations are further apart?

The enhancement is for a shield wall. Maybe this is not necessary, but I think if most readers think of important geographical features of Dune, this is one of the first to come to mind.

The preference is that I feel the maps are *too* large. On the large setting, a normal map is 64x104, and your map is 128x128. This is almost 2.5x the area. If there were a lot of interesting things to explore, that would be one thing; but Dune does not have much geographical variety. So I would prefer to make the maps smaller. Say, 104x104 for large.

Ok, I'm glad you guys had a chance to play around with it for a bit. The shield wall is no problem, I was just waiting to see what else needed to be changed so I wouldn't have to tear it down again in case it wasn't compatible.

As for the starts, this will require a trade off. I'm currently using a midpoint displacement technique to generate landforms. This makes for very natural looking forms, but it is impossible to fully control. You end up with some large islands and a bunch of very small ones. When several civs are placed on one continent, it's because they actually get more value this way than they would otherwise starting on some distant tiny island.

On the stock archipelago, I beleive the different islands have a similar size. I can make that happen but it won't likely look natural. It may be good enough though, and if it helps the gameplay then it's worth it. Doing it this way might also make it easier to shrink the map some.

I'll need some time to work on this, I'm in the middle of some other RL projects.

I think more similar size islands is important.

By a shield wall, do you just mean a chain of peaks along the outside of one of the larger islands?

I'd also vote for making this mapscript slightly more similar to Archipelago in terms of the regularity of the islands.

By a shield wall, do you just mean a chain of peaks along the outside of one of the larger islands?

Before I was just drawing a broken, wiggly circle of peaks.

While we're talking about peaks, it would be good to make them more desirable in this mod. Does our modcomp stack include this one (http://forums.civfanatics.com/showthread.php?t=311211)? I like the idea of giving them a beefier defence bonus.

I think rather than giving even more bonus to peaks, it would be better to make them impassable to more unit types.

Basically, I see only thopters, guardsmen and melee as being able to enter peak tiles. Vehicles and suspensors shouldn't be able to get through them.

Ok, hopefully I'll have a couple of days to work on this. Is there anything new regarding maps that I need to know about? Do we still have the land transport problem?

Ok, hopefully I'll have a couple of days to work on this. Is there anything new regarding maps that I need to know about? Do we still have the land transport problem?


Generating starting positions often fails with your map script. And there is no shield wall. Another complaint was that map size is too large.
:)

Generating starting positions often fails with your map script. And there is no shield wall. Another complain was that map size is too large.
:)

When you say fail do you mean crash? Or just starting too close to the others?

Here:


http://img410.imageshack.us/img410/2143/error1u.jpg
http://img14.imageshack.us/img14/2033/error2w.jpg

Stupid question, but is the version in the release the same as the latest version in the OP of this thread? I know Cephalo fixed this issue in a more recent version.

Welcome back. Koma's three points are the main points we would like fixed regarding the map. Ahriman has pointed out that city site selection for DW in general (not just starting positions) is not very good; windtraps on hills are a main source of food, and the selector doesn't take this into account.

One other question, rather than enhancement request specifically, has to do with island size; since coast is relatively useless in DW, a lot of small islands will be less useful. Have you compared the typical size of islands in your mapscript against vanilla archipelago? The archipelago script seems to work OK for island size, but if yours generates more, smaller islands it may be a little painful.

Stupid question, but is the version in the release the same as the latest version in the OP of this thread? I know Cephalo fixed this issue in a more recent version.

Yes the version in the OP should not crash as Koma indicated unless a new issue has cropped up, although the starts were often not usable.

I know this is a bit of a side venture that threatens to delay map development, but that land transport issue bugs me to no end! I've been looking at the BtS ai code and I believe I can solve it. There are about 20 places in the code that will need modification but I think it's do-able.

If I can, I wanna make a map that looks like my vision of Arrakis, and the land transport issue makes the whole process less fun for me. I need to spend some effort in hopes of squashing it.

Can someone link me the latest stable version of the source code?

The problem that I have with initial location is not python exceptions, but start positions which are within 5-6 plots of each other.

The source code for dune wars is in the cvgamecoredll directory of the current 1.5 download; see this link (http://forums.civfanatics.com/downloads.php?do=file&id=13270). I have made a few changes to restrict the actions cargo units can take; search for "davidlallen" changes primarily in CvUnit.cpp. Koma has made a variety of changes based on Maniac's code for dropships; search for "koma13" changes in different places.

You may be aware of another poster's recent attempt to solve land transport AI; see this thread (http://forums.civfanatics.com/showthread.php?t=332254). He made one change which accidentally made one thing work; he claimed a complete solution and got everybody excited; then he went silent again once he understood the actual scope. Still, there may be some good ideas there.

This idea of Ahriman's is quite interesting.

The one thing that would be neat to try, just for visual effect, would be to swap the heights; so our land tiles pan/sink/graben(=currently mesa/rock/etc) are at ocean level, and have hills and peaks in them, and then the desert and deep desert is at flatland level. It would be cool to see what this looks like.

I think it would be interesting to try a habitable pan/graben terrain at the lowest height (ocean plot type), surround that with a ring of hill plots representing the shield wall (we can alter the TGA heightmaps to make them more like a rocky barrier) and then the deep desert can be at flatland level. I'll try some experiments and see what this idea looks like in practice.

Another alternative is giving up one of Peaks or Hills plot types, to have a depression/sink heightmap that is less than the height of the flatland but higher than the ocean.

Also, is it technically possibly to make spice a terrain type too? I think we could have a big improvement over the current spice if so.

Yes the version in the OP should not crash as Koma indicated unless a new issue has cropped up, although the starts were often not usable.

Does that mean the version bundled with 1.5 is not the latest version?

Stupid question, but is the version in the release the same as the latest version in the OP of this thread? I know Cephalo fixed this issue in a more recent version.

It would be helpful if different versions of the mapscript had different version numbers instead of "1.0". But, the file timestamp of the script in the OP is Aug 5, and the timestamp of the script in 1.5 is also Aug 5.

Also, is it technically possibly to make spice a terrain type too? I think we could have a big improvement over the current spice if so.

Today spice is a feature, so that it can tile properly. There is also an invisible bonus. Only python code places spice, and it places both the feature and bonus together. If you made it a terrain type instead of feature, that would be fine; but it can be placed on either coast or ocean, so wouldn't twice as many tile types be needed?

The one thing that would be neat to try, just for visual effect, would be to swap the heights; so our land tiles pan/sink/graben(=currently mesa/rock/etc) are at ocean level, and have hills and peaks in them, and then the desert and deep desert is at flatland level. It would be cool to see what this looks like.

Heeey... what's going on with the heightmap changes? That sounds interesting, and if I'm not way off in understanding what you guys are talking about, I think I have an idea. How about if we swap the heightmaps for land and sea? So the sea(sand) is raised above the land? That might look cool. Then we can have real salt pans that are actually pans.

I think it would be interesting to try a habitable pan/graben terrain at the lowest height (ocean plot type), surround that with a ring of hill plots representing the shield wall (we can alter the TGA heightmaps to make them more like a rocky barrier) and then the deep desert can be at flatland level. I'll try some experiments and see what this idea looks like in practice.

Another alternative is giving up one of Peaks or Hills plot types, to have a depression/sink heightmap that is less than the height of the flatland but higher than the ocean.

The more I think about this, the more I like it in general.
Suppose we call the 4 heightmaps h0 (ocean), h1 (flatland), h2 (hills) and h3 (peak).

Consider if:
We have desert waste and deep desert as current, at h1.

We have graben (with 1 hammer, 1 commerce yields, replacing current mesa) and sinks (replacing current rock, at 1 hammer yield) and saltpan (replacing current rugged, 1 hammer yield, 30% higher improvement build cost) at h0. And *maybe* dunes (as current) at h0.

We have mesa (replacing current hills) at h2.

We have peaks (as current) at h3.
Peaks represent the shield wall; on the Arrakis mapscript, we get a line of peaks at the edge of the desert.

This is geologically more accurate, and could look pretty cool in contrast to vanilla; building your civ in depressions below the main desert.

My biggest concern is that peaks would look pretty weird sprouting out of flatlands adjacent to a higher desert, but we could make this happen *only* on the shield wall/arrakis, and have peaks banned from other areas adjacent to desert otherwise.
We could also modify the peak graphic so that it was a peak coming out of some foothills, rather than a peak coming up just from nothing.


Also, is it technically possibly to make spice a terrain type too? I think we could have a big improvement over the current spice if so.

What do we gain from this?