There can be an inconsistency on how oil spawn on a certain mapstring depending on exploration order.
Variant 1:
Variant 2:
Explanation video with showcase (reproduceable):
https://youtu.be/1FmcXYHzV6U
Different reproduction by Bilka:
https://youtu.be/bjnPF3zJ3p4
Mapstring:
>>>eNpjYBBiUGGAAAcgtudgSc5PzGFgOOAAw1zJ+QUFqUW6+UWpyMKc
yUWlKam6+ZmoilPzUnMrdZMSi1NXr9KygxjcYM+RWZSfh24Ca3FJfh5
MxB4sUlKUmloMcsrqVavsQBq5S4sS8zJLc0F6YQaCacaJ2kYSDS1yDC
D8v55B4f9/EAayHgCVgDADYwPITEZGoBgUsEgk5+eVFOXn6BanlpRk5
qVbJZZWWCVlJhZzGOiZGoCABjYVaUWphaWpecmVVrmlOSWZBTmZqUVA
HYZmQGAui64jNz+zuKS0KBXVYF2cyvCazpqck5mWxsCg4AjEThBvMEI
oPQco60CSA1TIE48QgwmQZQwGn+0RjGqRde4Pq0rsGWHKOBwQDIhkiz
1UhIGRCU7MmgkCO+FSMF0P7KFSN+0Zz54BgTf2YK0CfEBiQQ+QUJCB+
8EOpk3EgTENDL7B3PYYxrhsj+4yFQdGG5CRciDiBIhgRQQL0CWMEKZD
vwOjgzxMVhKhBKjfiAHZDSkIH52EWXsYyX40h6g4wIMUiz/QRFQcsAQ
sF8jCFDjxghnuGmD4XWCH8RzmOzAygxggVV+AYhAeNLOCjYLQAg4wCR
D4YM8Q7nzpEwDKdM3Z<<<
[0.18.36] Map generation changes on same mapstring depending on exploration order
Re: [0.18.36] Map generation changes on same mapstring depending on exploration order
I was really, really, really hoping it will be something fixable, so I can make you feel like we are not ignoring your bug reports for once ...
... but the problem is that crude oil patch has 3x3 collision box (so that they are not placed in a way that would make it impossible to build pumpjacks on top of them),
Each chunk wants to place oil resource entity on an edge tile, colliding with entity from the neighbouring chunk, so whichever chunk is generated first wins and the other one can't place the entity.
Only way to fix this I can think of at the moment, would be to align oil patches to 3x3 grid, so it's not possible for them to overlap without having the exactly same position. But that is also undesirable behavior of the map generation.
... but the problem is that crude oil patch has 3x3 collision box (so that they are not placed in a way that would make it impossible to build pumpjacks on top of them),
Each chunk wants to place oil resource entity on an edge tile, colliding with entity from the neighbouring chunk, so whichever chunk is generated first wins and the other one can't place the entity.
Only way to fix this I can think of at the moment, would be to align oil patches to 3x3 grid, so it's not possible for them to overlap without having the exactly same position. But that is also undesirable behavior of the map generation.
Re: [0.18.36] Map generation changes on same mapstring depending on exploration order
Now I don't have access to the map gen code, but question:
When generating the lower chunk, couldn't you just temporarily calculate the potential positions of oil spots on the upper chunk, and then e.g. make upper chunk oil spots always get preference where they overlap? Or is there something that makes it hard to know where the upper chunk oil spots will be placed?
I assume that this is a performance problem? For in theory, it should always be knowable where the upper chunk oil spots will be placed, and use that when placing the lower chunk spots, just by fully generating/regenerating the whole upper chunk from scratch.
When generating the lower chunk, couldn't you just temporarily calculate the potential positions of oil spots on the upper chunk, and then e.g. make upper chunk oil spots always get preference where they overlap? Or is there something that makes it hard to know where the upper chunk oil spots will be placed?
I assume that this is a performance problem? For in theory, it should always be knowable where the upper chunk oil spots will be placed, and use that when placing the lower chunk spots, just by fully generating/regenerating the whole upper chunk from scratch.
Re: [0.18.36] Map generation changes on same mapstring depending on exploration order
Oh no worries that's fine. I didn't expect a fix for that, but Bilka pointed out there could be more significant underlying problems that could be revealed and it's still worth reporting it. I generally don't mind my reports ending up in "won't fix". I just hate it when they get into "Not a bug", when they clearly are .