Factorio Forums

[0.13.16] Map generation - There is only one map - Seed only defines the position on this map


Edit: Somehow related Reddit Thread: https://www.reddit.com/r/factorio/comme ... _starting/


For my Speedruns I have reviewed several thousand of maps. I had the feeling that i see the same ore patches over and over again. Turned out I did indeed. All Seeds generate the same Map.

These are the map settings i used:


Set 1: Lets take a look at these 6 Seeds:
http://imgur.com/a/s4nUs
1111264398
1122004188
1126000668
1128005838
1129003852
1337508708



Looking at the iron/copper/coal/stone patches only, they are identical on all maps (except for the small starting area in the center that is generated differently). They are just shifted by some tiles. Sometimes even the terrain/biomes are identical as well. I found this effect on several sets.

Set 2:
http://imgur.com/a/LQk0U
1111081858
1111264396
1126002598
Same Effect. Different patches.

Set 3:
http://imgur.com/a/UnYvH
1111042612
1111330618

However the most interresting part appears when exploring a little more of the map in the first set. We can find the starting areas of the 2nd and 3rd set there as well.
http://imgur.com/a/heCIf


Therefor it is very likely that there is only 1 map in total that gets produced by all seeds (still depends on the generator options). The seed only defines the starting position on this map. I only found out about this bug yesterday and already found sets of up to 6 seeds with nearly identical starting areas, so this is not uncommen at all. I would like to request you to make the Seed generate a completly new map instead of only influence the starting position on the same map.

Love you devs,
AntiElitz




---
Some more Sets of similar starting areas - Note I searched for these sets manually, so I only notice the most wierdest ore patch shapes and probably missed A LOT of other sets:

Set 4:
1126004272
1111087636
1111182866
1111326488
1121000214
1124001132

Set 5:
1111343442
1111025756
1111311698
1121001820

Set 6:
1122006160
1111105224
1337307194

Set 7:
1337308160
1122005162
1111334650

Set 8:
1111362864
1111324042
1111355786
1126005922

AntiElite wrote:Therefor it is very likely that there is only 1 map that everyone plays on, which only depends on the generator options. The seed only defines the starting position on this map.

That's exactly how the map gen works...? There's no bug in that.

Map generation is deterministic. There's only 1 "random" element that goes into it and that's the seed you define at the start. That seed determines the start location and so it appears "random" although it never is.

Rseding91 wrote:

AntiElite wrote:Therefor it is very likely that there is only 1 map that everyone plays on, which only depends on the generator options. The seed only defines the starting position on this map.

That's exactly how the map gen works...? There's no bug in that.

Map generation is deterministic. There's only 1 "random" element that goes into it and that's the seed you define at the start. That seed determines the start location and so it appears "random" although it never is.

You got me wrong there: What I actually mean is that the map is always the same regardless of the Seed. Even different Seed produce the same Map. The Seed just influences where you start, like the x/y coords of the map.
Edited original text to clearify.

AntiElite wrote:You got me wrong there: What I actually mean is that the map is always the same regardless of the Seed. Even different Seed produce the same Map. The Seed just influences where you start, like the x/y coords of the map.
Edited original text to clearify.

That's what I was saying: there's only 1 map - you're correct. The "random" element is the seed which is simply a shift of x/y on that same 1 map so it appears as if it's random because the 1 map is near infinite and you simply shift the entire map by that random seed value to make the map look different. That's how deterministic map generation works.

You can actually take any map generated on the same game version and using: http://lua-api.factorio.com/latest/LuaS ... n_settings to extract the shift value: http://lua-api.factorio.com/latest/Conc ... enSettings go back to the "real" 0,0 of the map which will be identical.

Rseding91 wrote:

AntiElite wrote:You got me wrong there: What I actually mean is that the map is always the same regardless of the Seed. Even different Seed produce the same Map. The Seed just influences where you start, like the x/y coords of the map.
Edited original text to clearify.

That's what I was saying: there's only 1 map - you're correct. The "random" element is the seed which is simply a shift of x/y on that same 1 map so it appears as if it's random because the 1 map is near infinite and you simply shift the entire map by that random seed value to make the map look different. That's how deterministic map generation works.

Ah I see. So would it be possible to increase that shift by the factor of like 100 in general? Because as of now, all the starting positions are still very close to each other.

Rseding91 wrote:You can actually take any map generated on the same game version and using: http://lua-api.factorio.com/latest/LuaS ... n_settings to extract the shift value: http://lua-api.factorio.com/latest/Conc ... enSettings go back to the "real" 0,0 of the map which will be identical.

Wow that is really helpfull! Thanks - is it also possible the other way around? I mean to get the mapseed out of the shift?
PS: It would be helpfull for my speedruns when i could decide on how much i want to shift the map

Does 0.13.15 (or any other version since segmentation was removed) yield these same maps starting positions? The last time I was rerolling for maps, I don't remember this being much of an issue.

The shift is based off the seed. A random generator is seeded with the seed provided and then the x shift and y shift are calculated using that random generator.

Changing the seed will change the shift. Changing it more will change it more.

Rseding91 wrote:Changing the seed will change the shift. Changing it more will change it more.

Sounds like it isn't a cryptographically-acceptable RNG, not sure if that's a good thing or not. What are the theoretical endpoints for the range?

Rseding91 wrote:The shift is based off the seed. A random generator is seeded with the seed provided and then the x shift and y shift are calculated using that random generator.
Changing the seed will change the shift. Changing it more will change it more.

Ok, I think I got that. I meant maybe it is possible to increase the sensivity of the shift even more overall so the shift becomes stronger even with low seed changes. It's seems like one often spawns near the same place currently. So if the shift were stronger overall this would be less likely.
eg increase the shift by the factor of 10. When the seed results in a shift of x=20 and y=100 make it become x=200 and y=1000 instead. And x=-500 , y=400 to x=-5000, y=4000. This would increase the possible range of the shift and therefor make spawning near the same place less likely.

I guess what AntiElite wants is that the map Seed has more influence than just X/Y coordinates.

That the algorithm consists of more than just extracting a x/y shift value from the Seed.


Maybe add in some rotations around some axis as well depending on the seed... that would still result in deterministic results because the algorithm is still the same on all computers, but the outcome would look a lot more different to the user... because it would become harder to recognize the ongoing pattern.

MeduSalem wrote:I guess what AntiElite wants is that the map Seed has more influence than just X/Y coordinates.

That the algorithm consists of more than just extracting a x/y shift value from the Seed.


Maybe add in some rotations around some axis as well depending on the seed... that would still result in deterministic results because the algorithm is still the same on all computers, but the outcome would look a lot more different to the user... because it would become harder to recognize the ongoing pattern.

No, I'm fine with how it works. It's way to much efford to change that and it seem's good as it is. I just liked the shift to be stronger so the startingpoint is more diversified.

Okay well then.

I move this to NaB then.

Loewchen wrote:I move this to NaB then.

While is is true this is not a bug, the problems that is caused by it still persists and has an easy solution. Unfortunally i doubt is will be fixed, since it's in the "not a bug" section now :/

Was it always like this?

My assumption would be that seed affects some other map parameters to give an actual distinct map per seed.

From what I can tell, looking at a disassembly of `MapGenSettings::regenerateShift()`, in 0.13.15, the shift (for both X and Y) will be anywhere from +0 to +1999, inclusive.

Does the ore density relate to the coordinates before or after the shift? What about the technical constraints for map size? If these both use post-shift coordinates, the shift can be increased by a great deal safely. If they don't, it might be a good idea to allow them to, in order to permit a greater variance.

Is the shift in tiles or chunks?

@AntiElite: The RNG used is `boost::random::linear_feedback_shift_engine`, so it will be difficult (but not impossible, since bruteforce) to compute the seed that yields a specific pair of shift values.

Considering the fact that shift is measured in tiles according to docs.. this looks a bit dissapointing.
That would meant that technically map would be the same with starting location difference of up to 4k tiles in each direction. It seems a bit.. low ?

Seed should affect something more then shift change I hope. OP's test doesn't show big variety.

If it is indeed measured in tiles, that means you get 2,000 possible rows and 2,000 possible columns (not 4000). This covers 3,969 possible starting chunks, across 4,000,000 possible starting positions. This is far too low of an area (since that 2,000 tiles is only 62.5 chunks).

Requesting elevation out of "Not a Bug" due to clarification of the issue, and proof that there isn't enough variance.

Yeah I counted with negatives for some reason.
I'd think this test needs to be repeated on 0.12 to see if it's a result of new map gen implementation.