Arrakis.py map script discussion

[davidlallen]

Discussion at this post and this post. 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 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.

 

[cephalo]

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.

 

[davidlallen]

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?

 

[cephalo]

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?

 

[davidlallen]

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!

 

[cephalo]

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.

 

[davidlallen]

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.

 

[cephalo]

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.

 

[Deliverator]

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

 

[cephalo]

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.

 

[cephalo]

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

 

[davidlallen]

Welcome back! The latest patch is at this link.

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.

 

[Deliverator]

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.

 

[cephalo]

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.

 

[cephalo]

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

 

[Ahriman]

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

 

[cephalo]

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.

 

[davidlallen]

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?

 

[cephalo]

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?

 

[Ahriman]

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.