on the info tab, you wrote "The default values are the original values used by the in-game map generation script." are these the values for "default map" or are they somehow adjusted when selecting rich resources, rail world, etc ?

since all those values look tiny (0.001, 0.0002xxx, etc) it looks to be awkward to set different values myself.
without having tried it, i had the idea that a total could be specified for their sum (i think that should be around 0.007?) and then all entered values for the ore types would only be relative to each other, then automatically normalized to match a total of 100% (getting values between 0 and 1 for each type, summing up to exactly 1.000) and finally multiplied by a given value like 0.007. by having an additional checkbox "use relative values" and additional field for setting that sum, people could enter values either way. but that's just an idea that i got on seeing all those tiny values (similar to the evolution parameters on another vanilla setting which can barely be adjusted with a slider :-) :-(

of course, when 0.17 comes, all GUIs might have to be changed anyway and/or there might be easy methods to implement this: in case you will do something, there is no need to hurry and do it before 0.17 is released ...

Thanks for your feedback. Let me first introduce these things first.
To what I learned by reading the scripts, the "coverage" value corresponds to roughly the probability of the certain resources to appear on a tile. If you have a large value, like 0.5, for iron ore, you will find HALF your whole map is covered by iron ore patches! Therefore, unless you want to play some scenarios like the "Dangerous Ore", you will not need such high values. But some players may specifically want this.
So in normal play, you will have such small values. The default values of the vanilla game is located in "base/prototypes/entity/demo-resources.lua". If you look into the file, you will find formula like 0.0023 / 3, or even more complicated like (0.006 / 3) / 1.1 * 1.49. I want the default values set at vanilla values, so players can make changes based on them. Any option type other than double type would be "lossy" conversions, so I decided to leave it as current value box.
I wanted to make the values more "nice" looking as well, but those "/3" and "/1.1" make me hard to find some good HCF among these numbers.
I have tried to use the slider. But I feel it is too "coarse" for values having such a large range from 1 to 0.0000xxx. In-game conversion GUI "radius" gives you an idea on how "coarse" the sliders are.

To what I am understanding, these "coverage" values are for default/medium setting. The "rich world", "rail world" settings give some modifications (like "high") are applying some kind of multiplier to the coverage values. So setting values for coverage still apply. I could be wrong, so don't quote me on this. ;-)

The devs change the map generation and resource autoplace functions almost every versions. Consider the devs change the iron/copper/stone usage ratios in science FFF, I am sure they will change these values a lot. Hope they will use some "simple" values, so I don't have to consider GUI change at all. :D

thanks a lot for answering so qucikly and giving so much detail.

and now I'll try to give an example of what i had thought of:

• the first setting would be the current checkbox whether to modify coverage at all
• a new second checkbox would be whether to use absolute values (like it is now) or percentages
• if both checkmarks are set, the third would be the absolute sum between 0 and 1, else would be ignored (with the sum being the system's values added up: 0.0027091 + 0.002 + 0.0007667 + 0.0015 + 0.00015 + 0.0003333 = 0.0074591)
• followed by the six values for 6 ores, either with values 0.00xxx like now (each between 0 and 1, and adding up to a value between 0 and 1), or if both checkboxes are selected with normalized values 36 + 26 + 10 + 20 + 2 + 4 = 98 (roughly rounded percentages, adding up to a value around 100)
  btw: some kind of summation and/or normalization has to be done anyway to ensure that users don't add values that add up to more than 1.000

yet again, this was only an idea to be able more easily giving the values since i have a better imagination what a total coverage of 0.01 (1% of the total area) might mean, with percentages (ratios) like 36% and 26% for iron and copper ore. it would be much harder for me to envision how much 0.27091% and 0.2% would be and what ratio that would be.
of course, i have no idea whether such calculations for the settings can be done at all and most of all whether they can dynamically be adjusted eg when clicking a checkbox. didn't they say in some FFF (or was that a suggestion from someone as an answer to some FFF) that 0.17 might have sliders where you could also enter values directly ? maybe it then would be possible to easily see the ratios on the slider positions and at the same time still have the values like it is now. let's see and wait for 0.17 :-)

Well, allowing a single text field as a "decimal/absolute" or "percent" value by another checkbox can confuse the users. Making two separate field for each may confuse even more.
The current API/GUI does not support autohide or disable of other setting fields. "Autohide" means if the "percent" checkbox is enabled, the "decimal" text fields are hidden from display. "Disable" does something similar, but instead of hiding, it simply make those text fields and labels darkened or unselectable.

If future versions support autohide or disable features, I may consider implementing these.

And yes, actually in many of my mods, many settings would look better in slider form, rather than the old-school text field or drop-down box I am using currently.

Hi, I have just released the 0.17 update.
Vanilla 0.17 resource autoplace has just a very different algorithm.
It no longer used the "coverage" with have small decimal values, 0.17 is using "base density" values instead.
"Base density" ranges from 0.9 (uranium ore) to 10 (iron ore). So the values now gives players a better "feel" of the ratios, etc. So I guess the simple textfields are adequate at the moment.
You may want to try and play with the values, see what you feel afterwards.

thanks. that sound much better now.

but it will take some time until i try it since I'm first doing a vanilla run and installing/updating mods which quite often alter the game of factorio into a game of restarting it all the time to find which mods cause problems on starting factorio :-(

I have a gigabase with ALL my mods saved in 0.16.51, now I just tested and found it running properly after update.
But yes, take your time.

many mod authors seem to have been lazy and only updated the version number in the json, but not at least once started up factorio between that change and publishing to the mod portal, causing dozens of errors (in turn causing dozens of restarts) because of improper names for items like science packs, which should have been very easy to detect when starting factorio at least once. next are more difficult errors (but still also on startup) where factorio suggests to disable 10+ mods because of one bad mod, and finally when/if factorio starts, checking for incompatibilities ingame.
admitted, i use too many mods, from 20+ QoL to rarely used extensions of the game like 20+ additional specialized constant combinators to check for some status (bonuses, research, etc) or 5+ alternate miners (bucket, etc), and finally to other additions like new tiers, logicarts, additional trains, spaceX, etc etc. I'll only maybe cut down on mods when my UPS would start dropping below 58-60 on my small/medium factory (based on producing 1-4 of each per sec, using eg 250-350 peak science per min) :-)

I understand your feeling. Many such mods. Too bad there are no thumbs down or negative comment feature in the mod portal, to warn other players what problem they could face.
Yes, so I learned to be picky after installing (a lot) of mods. Firstly, I will not download those mods which are poorly documented. I want to know what the mod is going to do from description. Secondly, I will go into the discussion section and see how many bug reports. This is to get an impression whether the author was careful enough writing the mod. Thirdly, I will check the update frequency. If the mod is frequently updated like thrice per week, I don't consider the author have think enough of what to do with his/her mod.
Passing the above conditions, then I will download the mod to try it out. But that's not the end.
I used some very useful QoL mods, but found them terrible to UPS with my megabase. So I decided to uninstall them.

I have been picky, and keep my mod counts below 10 (not counting my own ones). The outcome is I no longer have such painful upgrade to 0.17.
Updating my own 20 mods was a painful process, though... >_<