Seed of random generation

[Reygan]

Well, header is self-descripting enough.
If all random values within one map (save or scenario) could be generated using one seed hash string or number. Either it could be possible to see random seed of alredy generated maps. Because there are many random values, especially in terrain/ore generation.
It would be great if it was possible to "save" some random generation user liked.
Like in minecraft or gnomoria, but would be awesome, if absolutely all random generated values was bound to origin seed.

[FreeER]

see this topic
basically such is planned, there may be more updated info somewhere (I think I saw the devs say something not too long ago) but no idea where now..

[cube]

That is already implemented for 0.10.0 (although it needs some polishing). All map settings are serialised into a string that can be copy pasted and shared (we should add a forum tag for that ... ).

[cube]

Also -- all random variables are (or will be) completely detrerministic, this is needed for the multiplayer, but the game will eventually diverge from previous plays because of differences in player's behavior. ...butterfly effect and all that jazz.

[Reygan]

That is already implemented for 0.10.0 (although it needs some polishing). All map settings are serialised into a string that can be copy pasted and shared (we should add a forum tag for that ... ).

Also -- all random variables are (or will be) completely detrerministic, this is needed for the multiplayer, but the game will eventually diverge from previous plays because of differences in player's behavior. ...butterfly effect and all that jazz.

Wow. I expected something else. But this is awesome! Glad that I bought this game

[Dark]

Upping this one.

Anyway to get access (and modify) to world's seed, freq/size/richness control settings from a mod at runtime?

[ssilk]

Why? There is a big chance that a game is unplayable then.

[Rahjital]

Unplayable? At worst, it would cause the vanilla world generator to make a sharp divide between what was already generated and newly generated chunks. That's not the intended use of it, though. It would allow mods like this one to check what settings the user generated the map with and change the generation algorithm accordingly.

[ssilk]

Still not understood: a random seed has nothing to do with the settings of a map. It's like a password and the salt.

[Rahjital]

It's still the same thing, mods that add custom map generation instead of relying on vanilla map generator have to use their own random functions to ensure determinism. Acessing the map seed makes them able to use the same seed the map does.

[Dark]

Still not understood: a random seed has nothing to do with the settings of a map. It's like a password and the salt.

My mod can use that salt/seed for procedural generation, in fact it already doing so, but seed it uses is generated from tile data, it equivalent to map seed in same way, but it's not the same.

[Schmendrick]

Devs have stated they have overwritten the math.random that mods can see. Using it should be completely determinism-safe out of the box, and is recommended.

[Dark]

In procedural generation math.random was never the only thing that defined determinism, many events are player driven with no defined order they can even not happen, producing same result regardless of events order and time of appearance is determinism if no other unpredictable factors involved.
If you blindly use your math.random without stopping to think about when and what you're doing - you'll rarely get the same result, no matter how "deterministic" your math.random is.
In fact, about every random() implementation is deterministic, it just procedural function, that has seed and previous value, based on which it produces a new number, not a truly random number, but it works fast and can produce a lot of numbers.
Only cryptography related software uses "true" randomness, but they draw from "entropy" quite fast and can't produce a lot of random numbers for general usage, entropy can be sucked completely which for example can result in failing to initialize wifi access point.

Anyway, here we talk about quality of procedural generation that can be improved by using map's own seed instead of generating seed based on map data, same goes for access to map generation parameters.

[Schmendrick]

I didn't mean to suggest that other implementations of random are not deterministic, only that the dev-supplied math.random is designed to be a commonality, and as such should be good enough and equivalent to accessing map seed data. Anything you need to be 'random' should be satisfied by it.

And incidentally, even cryptosoftware rarely uses true randomness.

[Dark]

:facepalm:

[Rahjital]

I didn't mean to suggest that other implementations of random are not deterministic, only that the dev-supplied math.random is designed to be a commonality, and as such should be good enough and equivalent to accessing map seed data. Anything you need to be 'random' should be satisfied by it.

That's... not really how it works, though. Terrain generation has to have its own random generator that's completely unrelated to math.random because if it wasn't, you would get a different map even if the events in the game diverged only slightly. Terrain needs to be generated the same way no matter how many times math.random is called and the only way to ensure that is to give the generator a rng of its own.

[Schmendrick]

Sure, but the question is: why do you think you need it (the seed)? Supplied math.random is just as "random" and common. I can definitely think of a few reasons why you'd want access to map generation settings, but the seed? No reason unless you also have access to the internal rng algorithm Factorio uses plus its specific implementation of Perlin, and wanted to use lua for terrain generation instead of using autoplace settings. I'm not saying access to the seed is a *bad* thing, per se, but why would you ever need it?

(Actually I just thought of one: if you wanted to generate a more human friendly version of the map string for sharing, like a paragraph or something. Maybe there are more; at this point I'm curious what you have in mind.)

[Dark]

:faceplant:X10
The reason for access to the seed was already told in this very topic.
It does not matter what algos terrain generation uses, as long as two terrain generators deterministic and use common seed the combined result will be the same.

The way you clinging to math.random in your every post is really unnatural.

[Schmendrick]

This really boils down to a simple question that we have forgotten to ask each other:

"Is the initial math.random seed set based on the same sequence as is used for the map generation?"

I have assumed it is, because this makes sense. You seem to be assuming it isn't. If it isn't, I'd consider that a[n easily fixed] bug.

[FreeER]

"Is the initial math.random seed set based on the same sequence as is used for the map generation?"

It's actually slightly more complicated than that, especially if a mod wants to do the world gen 'manually'. Why? Because the point of a 'seed' is that you get the same output for the same input (well, more typically it's so you can get different output by simply changing the seed, but that's essentially the same lol), and math.random, even if based on the seed, won't always give that since adding (an)other mod(s) that uses math.random before the worldgen mod would result in the worldgen mod receiving different math.random numbers than it did before the other mod(s) was added, even if the map seed was exactly the same. However having access to the seed itself means that the worldgen mod could generate the exact same world (when given the exact same seed).
Just having the options that the player set for something (high iron ore, low enemy bases, etc.) doesn't work as well either because the actual seed that is generated (in all probability) is going to be different even if you give it the same options (otherwise you'd have very limited terrain gen even with the regular generator).

Not sure if there's a reason for the world seed to be mutable however, if it was it'd need to be modified before any actual generation was done (or you'd end up with a starting patch made with the original seed and everything else made by the modified seed)...

I'm sure there are other aspects I haven't considered, but that's an obvious difference between using math.random (seed based or not) and actually having the ability to 'read' the seed.