FOSS gamedev and creative worlds

I have somewhat figured out how to manipulate sheet ore generation to do what I want with it - but there remains one big problem: regardless of to what I change the noise_threshold, octaves or persistence, it always generates massive swathes of the ore that extend for hundreds of blocks. I want it to only generate "smaller" clusters of ore, on the order of a couple dozen (or so) blocks in width - so that it is harder to find the clusters, but once one is found the player does not have to keep searching for more clusters in order to have enough resources for making stuff (until the currently uncovered one is depleted, which would take a considerably long time).
What would you recommend to use for the noise parameters, so that it does not end up generating such massive swathes of ore that extend to the point that they all connect as one? Specifically, how can I control how often the noise value reaches above the threshold, the distance between points where the noise value is above the threshold, and the relative size of regions where the noise value is above the threshold? Or, is there a program I can use to quickly generate a noise "map" with parameters relevant to sheet ore generation, in order to test the parameters and find out which values are fitting?

I had the same issue. I used blob instead.

I agree that blob generation can be used for a quick workaround - however, I read somewhere that such mode is very much resource-hogging (or is it just vein generation? or both?), so it will probably be a bad idea to try to implement that for all 46 ores (plus some misc. number for the ones I forgot to add) in my mod. I will use it for the generation of rarer ores like Iridium, Mythril, Carmot, Orichalcum, Adamantite and such - because it results in a denser formation, which is much to find among the huge swathes of stone between deposits, while there is still being a large enough amount of ore in each deposit for the player to reasonably make use of for tools and such.

Even when I use the parameters that I used earlier to generate Iridium, which ended up only generating a few dozen nodes per 1000x1000x1000 area, the clusters are still relatively massive and nothing is changed. I am quickly becoming convinced that at least one of the developers have decided to troll us with this and other unworkable problems (which is easily done by making certain parameters remain static and ignore the values passed by the minetest.register_ore() function call)

bump for inactivity

EDIT: Added some screenshots to define the problem better. Here is what I am getting regardless of the "noise_threshold" and "persist" values:

Don't mind all of the copper ore blocks, they are from some other testing with ore generation. I should probably make them less common, and less minecraft-looking...

Here is what I relatively want to have generated, although maybe at a slightly larger scale:

These smaller clusters are better fitting to the purpose, than the more massive ones (which are frequently interconnected, making it a lot easier to mine large amounts of ore - which is not good for balance). It should be somewhat difficult to find a deposit of ore, but once one is found the player would have plenty for tools and stuff, until the cluster is depleted.

Once you got that to work, it might also be of intrest to darkage. Or was that already updated to the new ore generation functions? The (old?) darkage stone types where often found in sheets. It worked quite well.

Give this a try. I think it is what you want.

What are the current parameters you're using?

I have been using these parameters:

This worked in the past to generate only a few dozen ore nodes per 1000^3 area, but now gives the same results as what is in the above screenshots.
It may have something to do with the scarcity value, but that does not make sense because it is (or was) ignored for sheet ore generation, at least in the past.

However, blob ore generation seems to fit the needs a lot better, especially considering that I have gotten it to work right. Would you agree that this distribution is sanely "balanced"?:

I am not good with generating ores. I do know that I can not get sheet to work right. Do you know if anyone has submitted an issue?

SegFault22 wrote:I have been using these parameters:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

clust_scarcity  = 1
clust_num_ores  = 1
clust_size      = 2
noise_threshold = 2.4
noise_params = {
offset  = 0,
scale   = 2,
spread  = {x=32, y=32, z=32},
seed    = 65550,
octaves = 3,
persist = 0.26 }


I see no reason why those parameters shouldn't work. The noise should be in the range -2.655 to 2.655, so a threshold of 2.4 should produce very infrequent patches.
I've never used sheet ore generation before so I don't have any working examples to test, but if you haven't solved the problem tomorrow I'll try digging into the source code and looking for bugs.

ArguablySane wrote:

SegFault22 wrote:...blah...

I see no reason why those parameters shouldn't work. The noise should be in the range -2.655 to 2.655, so a threshold of 2.4 should produce very infrequent patches.
I've never used sheet ore generation before so I don't have any working examples to test, but if you haven't solved the problem tomorrow I'll try digging into the source code and looking for bugs.

Thank you for the insight. Maybe if I set the threshold closer to 2.6 or 2.64, that could show at least some different results.
I would like to know how you calculate the noise range from the parameters, as that can be very helpful when configuring generation of over 60 different ores (including transition metals, poor metals, lanthanide/actinide metals, fantasy metals, crystal ores, non-crystal mineral ores, fluid ores, hadron conglomerates, etc.)

I posted this on IRC:
*****
i'm just now starting to understand sheet ore.
try {offset=0, scale=0, spread={x=100, y=100, z=100}, seed=23, octaves=3, persist=0.5} then threshold should be carefully tuned between 0.5 (one 3rd of world area) and 1.0 (very rare).
once you have a rarity you like, the entire pattern can be enlarged in size by increasing all 3 values of 'spread={x=100, y=100, z=100}'.
'spread' will be very roughly the average distance between ore pockets (depending on the rarity).
then finally increase 'scale' to create a wavelike shape to the ore sheet.

if noise has been changed in a way that messes up sheet ore try {offset=0, scale=1, ...} that might help.
a while back there were changes to how offset and scale transformed noise values which may cause a bug because of this: "The noise is not transformed by `offset` or `scale` when comparing against the noise threshold, but scale is used to determine relative height."
*****

Noise range depends on octaves and persistence.
Before being multiplied by 'scale' and before being offset by 'offset' the raw noise value is created like this:
The first octave outputs a -1 to 1 variation, each additional octave adds a variation that is smaller through multiplication by persistence.
So with 3 octaves, 0.5 persistence (a classic much used noise):
Maximum amplitude = 1 + 1 * 0.5 + 1 * 0.5 * 0.5
= 1 + 0.5 + 0.25
= 1.75
Raw noise value range is -1.75 to 1.75.
But the value only very rarely approaches the limits so a threshold of 1 will not be exceeded very often.

Remember that scale is ignored when comparing against the threshold with sheet ore.

paramat wrote:Remember that scale is ignored when comparing against the threshold with sheet ore.

If that's the case, then why does SegFault's code generate any ore at all? The noise value should always be less than 2.4.

A while back there were changes to how offset and scale transformed noise values which may cause a bug in sheet ore.

paramat wrote:A while back there were changes to how offset and scale transformed noise values which may cause a bug in sheet ore.

As far as I can tell from the code, both scale and offset are applied before the noise value is compared to the threshold. I haven't spotted any bugs, although I only gave it a relatively cursory inspection. It seems that the seed value is overwritten though, so there's no reason to set that to anything other than zero.

ArguablySane wrote:It seems that the seed value is overwritten though, so there's no reason to set that to anything other than zero.

Considering that, I will put a stop to my standard of trying to use a range of seeds which is not currently used by other mods. I used to fear that would result in placing nodes over other mods' ores, but now I realize that it does not really matter, so there is no need.
It would be useful if the seed value were actually used and not just overwritten, because currently that could (in theory) cause nodes to be placed over existing ones if the other parameters for generation are coincidentally (or intentionally) identical - unless a totally random seed is used (which would be bad, because that would result in ores always being generated in different locations - if the chunk is ever deleted and re-generated, or if a new world is created with the same world seed in an attempt to make an exact copy of the generated world)

The actual code used for setting the seed in mg_ore.cpp is

It should be deterministic for a given mapseed and chunk, but there are likely to be weird discontinuities on chunk boundaries. Also, as you say, if two ores were given exactly the same parameters then one would probably overwrite the other completely.

Sokomine wrote:Once you got that to work, it might also be of intrest to darkage. Or was that already updated to the new ore generation functions? The (old?) darkage stone types where often found in sheets. It worked quite well.

l aborted updating the darkage mapgen because l don't figure out how to change the threshold of what of the perlin noise is used for setting the nodes.
https://github.com/HybridDog/darkage/bl ... n.lua#L228