Temperature and Humidity parameters can be altered from the command line.

[esampson]

Added command line options for Temperature and Humidity ranges. While this does not fully allow the creation of non-terrestrial planets (we need to be able to alter how much water there is) it brings us much further along.

$ python worldengine -b -s 1 --temps 1/1/1/1/0.594/0.439 --humidity .507/.236/.073/.014/.002/.0/.0

Worldengine - a world generator (v. 0.18.0)

operation : world generation seed : 1 name : seed_1 width : 512 height : 512 number of plates : 10 world format : protobuf black and white maps : False step : full greyscale heightmap : False rivers map : False fade borders : True temperature ranges : [1.0, 1.0, 1.0, 1.0, 0.594, 0.439] humidity ranges : [0.507, 0.236, 0.073, 0.014, 0.002, 0.0, 0.0]

starting (it could take a few minutes) ...

Producing ouput:

• world data saved in './seed_1.world'
• ocean image generated in './seed_1_ocean.png'
• precipitation image generated in './seed_1_precipitation.png'
• temperature image generated in './seed_1_temperature.png'
• biome image generated in './seed_1_biome.png'
• elevation image generated in './seed_1_elevation.png' ...done

[tcld]

Interesting! Although I wouldn't know what kind of variables I would have to pass to worldengine, the explanation could be more precise. From the code I gather that these are the percentage-values that have been fixed before - your example --temps 1/1/1/1/0.594/0.439 thus would result in cool temperature region everywhere (the ones before are overwritten), then a bit of warm (15.5%, the rest is overwritten) and 43.9% subtropical. The percentages refer to the temperature map, but I think this still results in e.g. 43.9% of the (lands) surface being covered by a subtropical temperature-region.

Is that right? If so, an ice-world would be --temps 1/0/0/0/0/0 ?

EDIT: Do you see a simple way of slightly randomizing these values if no parameters are passed?

[tcld]

On a sidenote: If your PRs aren't passing the ancient map-tests even though you think they should, rebase your work on the current master (my last PR changed the ancient map-generation slightly).

[tcld]

I just realized that this is probably not repeatable - maybe worldengines info-mode needs to be updated, too? (This would then require an update to the save-files, too, I guess.) (I never used that mode anyway, I just wanted to point this out.)

[ftomassetti]

I am not sure I get your last comment. Can you rephrase that please?

[tcld]

Sorry. Changing the parameters for temperature- and humidity-distributions will result in a world-file whose generation-parameters can not be fully retrieved for later reproduction. Maybe I am just overlooking something, or maybe the info-mode isn't meant to provide that kind of reproducibility anyway.

[ftomassetti]

Oh, ok I understand now. So we could just store those parameters in the world file. Currently I do not think it offers 100% reproducibility but it would make sense to store it.

[tcld]

We might just not store them - there may be more changes like this in the future and it might prove laborious to store all the different parameters in the world-file. Depends on how important it is to be able to recreate a world.

[esampson]

Ok. Merged with the new master and updated.

The update is very minor, but I think it will make it much easier to understand. The values I was initially using were the identical values used in code; good for the machine but not so good for human comprehension. What I did was invert the value (1 - old value) and that should (hopefully) make it a lot easier to understand what is going on.

The way the parameters work is fairly simple. Temperature is arranged in the order of coldest to hottest and Humidity is arranged driest to wettest. With the modification the following would have been to correct command:

--temps 0/0/0/0/.406/.561 --humidity .492/.764/.927/.986/.998/1/1

These numbers are the dividing lines based on the percent of the land population. In other words 49.2% of the land surface on this map will be the driest possible category. 76.4% will be either the driest or the second driest (and since 49.2% is already designated as the driest that means that 27.2% will be the next driest), etc. There are 8 possible humidity zones normally but on this map the 2 wettest won't occur because the lines separating zones 6 from 7 and 7 from 8 occur at the very end of the chart, so everything will be zone 6 or drier.

Likewise there are 7 temperature zones, but the 4 coldest won't occur in this case because the the lines separating zones 4 and 5 (and everything before that) occur at 0% of the population.

[esampson]

As for slightly randomizing the values; I think it would be a better idea to just add a command line option that will randomly generate new values (something like --humidity random). That way the default will be to use the tuned values but you can easily use random values if you like.

[ftomassetti]

yes, I agree with having "earth like" values by default and random as an option

[tcld]

I am currently thinking about randomization and storing variables in a global file (https://github.com/Mindwerks/worldengine/issues/140#issuecomment-152483413). Something like this might be nice:

temps=[.874, .765, .594, .439, .366, .124]  # all values below 1: relative (% of surface covered)
temps=[0, 2.1, 5.0, 5.7, 5.9, 10.0]  # at least 1 value above one: absolute temp-value required
temps=[.874, .765, (.594, .05), .439, .366, .124]  # a 2-tuple means: 0.594 +/- 0.050
temps=[.874, .765, (.594, +0.05, -0.1), .439, .366, .124]  # a 3-tuple means: 0.494...0.644

A class would have to manage these lists. My ideas regarding this are still very rough.^^

[tcld]

Thinking about the new notation you chose, to me it is as convoluted as the previous one. Exactly as convoluted. I would have preferred not having that extra layer of confusion (if a user looks into the code he has to notice that he has to look at values in the code differently than values on the commandline).

[ftomassetti]

I think this is a great contribution and we can incrementally improve it. It is very good and positive to have more eyes looking at the code but perhaps we should not be too negative :)

[tcld]

If one of those lists ever changes their length, 4 different files will have to be changed to account for it - two files belonging to the test-suite. Almost all of that could have been avoided by slightly altering ~5 lines of code.

I am sorry if I come across as overly negative, this is a great addition for sure. I just think that increasing maintainability is worth going the extra mile.

[ftomassetti]

I appreciate your comments and I agree with many of your concerns. I just had experiences with other projects were we ended up parking PRs for a long time, then they ended up out of sync with master so we had to rebase them or new committers were scared of. This is absolute not that case, I wanted just to say that perhaps we can each time point out the main 1-2 things, merge and then refactor. In this way we reduce conflicts and keep the unit of work small, which I think is positive. But your attention to details and code quality is very much appreciated and we definitely need some help on that side!

[esampson]

I was trying earlier to use default values when possible, but for some reason they didn't seem to be getting passed correctly. I'll be making more passes over this code to try and tighten and clean up bits of it (such as this) and I appreciate all of the feed back.