Forcing chunk generation?

[Reika]

I am working on implementing a custom ore generation algorithm, but have run into an issue. The only way I know how to do ore gen (and replacing all existing oregen) is to watch the chunk_generated event and then clear the ores and place new ones manually. This works nearly perfectly, but there is one significant issue: Often times my ore 'blob' will go outside the bounds of the chunk the event is for and get 'clipped off'. Is there a way to force the generation of that chunk, Minecraft-style (MC generates chunks as they are interacted with if necessary), or, alternatively, a way in Lua to do something like a noisemap (it seems far outside Lua's capabilities)?

[aubergine18]

* Autoplace control
* LuaSurface.map_gen_settings
* LuaSurface.is_chunk_generated
* LuaSurface.request_to_generate_chunks

[Reika]

* Autoplace control
* LuaSurface.map_gen_settings
* LuaSurface.is_chunk_generated
* LuaSurface.request_to_generate_chunks

I already read all of that. I need a way to force a chunk to generate immediately, not make a request and not solve the issue.

[aubergine18]

You can't - the game does chunk generation via a queue, and any changes (insertions) to that queue would likely cause desync, which is why there's no method for doing it immediately.

However....

You could potentially kludge it by teleporting the player to the desired location, which might force the game to immediately generate the surrounding chunks....? http://lua-api.factorio.com/latest/LuaC ... l.teleport

[Rseding91]

Chunks aren't generated immediately except at the start of the game.

You can *access* any chunk you want - and it will exist. It might not have tiles/entities generated yet but it will exist and be valid to put entities on (assuming it's within the valid chunk distance from 0,0).

The proper way to do entity generation on chunks is to generate only the entities that will *be* on that chunk. If you have to place entities outside that chunk generate them when that chunk is generated. If your entity generation algorithm can't do that then it's not a proper algorithm.

[Reika]

You can *access* any chunk you want - and it will exist. It might not have tiles/entities generated yet but it will exist and be valid to put entities on (assuming it's within the valid chunk distance from 0,0).

Then why do I get this?

[Rseding91]

You can *access* any chunk you want - and it will exist. It might not have tiles/entities generated yet but it will exist and be valid to put entities on (assuming it's within the valid chunk distance from 0,0).

Then why do I get this?

You didn't read what I said.

[Reika]

You can *access* any chunk you want - and it will exist. It might not have tiles/entities generated yet but it will exist and be valid to put entities on (assuming it's within the valid chunk distance from 0,0).

Then why do I get this?

You didn't read what I said.

Yes I did. You said that it would successfully place entities on not-yet-generated chunks. But when I do that it just fails and causes the highlighted cutoffs.

[orzelek]

You can *access* any chunk you want - and it will exist. It might not have tiles/entities generated yet but it will exist and be valid to put entities on (assuming it's within the valid chunk distance from 0,0).

Then why do I get this?

You didn't read what I said.

Yes I did. You said that it would successfully place entities on not-yet-generated chunks. But when I do that it just fails and causes the highlighted cutoffs.

It works exactly as Rseding91 wrote. RSO uses that and ores don't seem to cut off or very rarely.
What you are seeing is a bit different interaction - you are removing those entities yourself.
You wrote that all ore is removed in event handler - so depending on order of chunk handling is called you can generate patch in one chunk then remove parts of that patch when handling event for neighbouring chunk.

[Reika]

You can *access* any chunk you want - and it will exist. It might not have tiles/entities generated yet but it will exist and be valid to put entities on (assuming it's within the valid chunk distance from 0,0).

Then why do I get this?

You didn't read what I said.

Yes I did. You said that it would successfully place entities on not-yet-generated chunks. But when I do that it just fails and causes the highlighted cutoffs.

It works exactly as Rseding91 wrote. RSO uses that and ores don't seem to cut off or very rarely.
What you are seeing is a bit different interaction - you are removing those entities yourself.
You wrote that all ore is removed in event handler - so depending on order of chunk handling is called you can generate patch in one chunk then remove parts of that patch when handling event for neighbouring chunk.

Oh, the event fires after I finish interacting with it? I though the ordering was "chunk 1 gens" > "fires event for chunk1" > "my code runs" > "spills into chunk 2" > "triggers chunk2 gen" > "fires event for chunk2" > "my code finishes for chunk1", like MC does it. Not "chunk 1 gens" > "fires event for chunk1" > "my code runs" > "spills into chunk 2" > "triggers chunk2 gen" > "my code finishes for chunk1" > "fires event for chunk2".

Well, that explains it.

Though I know of no way to "tag" an ore to mark it as "do not remove".

I have also tried MC MapGen style generation (where I set the random seed based on the chunk coords, and generate a chunk at a time, taking the borders into account), which solves the edging issues but introduces new ones, including fact that the Factorio RNG outright ignores calls to set the random seed (which forced me to implement my own) as well as trouble getting rid of repetition:



I am using the same approach MC does:

Code: Select all

function createSeed(surface, x, y) --Used by Minecraft MapGen
	local seed = surface.map_gen_settings.seed
	setRandSeed(seed)
	local r1 = nextRand()
	local r2 = nextRand()
	local a1 = x*r1
	local a2 = y*r2
	seed = bit32.bxor(surface.map_gen_settings.seed, bit32.bxor(a1, a2))
	setRandSeed(seed)
end

With a custom random based off of glibc:

Code: Select all

local seed = 0
local MULTIPLIER = 1103515245
local ADDEND = 12345
local MASK = 2147483647
local BITSHIFT = 7

--THIS RAND SUCKS

function setRandSeed(newseed)
    seed = bit32.band(newseed, 2147483647)
end

function nextRand()
    seed = bit32.band((seed * MULTIPLIER + ADDEND), MASK)
    return bit32.rrotate(seed, BITSHIFT)
end

function nextDouble()
	return nextRand() / 2147483647
end

function nextInt(limit)
	return 1+(nextRand() % limit)
end

function nextRangedInt(minval, maxval)
	if minval == maxval then
		return minval
	end
	return minval+nextRand()%(1+maxval-minval)
end

function randWithSeed(cseed)
    local oldseed = seed
	local ret = nextRand()
	seed = oldseed
	return ret
end

[Rseding91]

I'm adding LuaRandomGenerator for 0.15 that will allow you to use the deterministic random generator implementation we use internally with a custom seed of your choosing without effecting the normal game random generator state.

[orzelek]

I'm adding LuaRandomGenerator for 0.15 that will allow you to use the deterministic random generator implementation we use internally with a custom seed of your choosing without effecting the normal game random generator state.

Brilliant
Will be able to drop the random gens from RSO - should also make it faster.

@Reika
Your entites might not be triggering another chunk - I'm not really sure on that one. It can be already queued for generation anyway.

Take a look into RSO in data-updates.lua.
It disables base game ore generation using small trick - no need to worry about deleting original ores can only generate new ones.
There are separate ways of disabling for resources and biters since strange things were happening.

[Reika]

@Reika
Your entites might not be triggering another chunk - I'm not really sure on that one. It can be already queued for generation anyway.

Take a look into RSO in data-updates.lua.
It disables base game ore generation using small trick - no need to worry about deleting original ores can only generate new ones.
There are separate ways of disabling for resources and biters since strange things were happening.

I see the "remove peaks" (clearing the noise function for the autoplace) for the spawners, but apparently you are setting the richness to zero for the ores (rather than nulling out their autoplace). Is that to avoid the "strange things"?

[orzelek]

@Reika
Your entites might not be triggering another chunk - I'm not really sure on that one. It can be already queued for generation anyway.

Take a look into RSO in data-updates.lua.
It disables base game ore generation using small trick - no need to worry about deleting original ores can only generate new ones.
There are separate ways of disabling for resources and biters since strange things were happening.

I see the "remove peaks" (clearing the noise function for the autoplace) for the spawners, but apparently you are setting the richness to zero for the ores (rather than nulling out their autoplace). Is that to avoid the "strange things"?

Thats done to not interfere with later algorithm that spawns ore based on presence of autoplace.
It's needed to make sure that RSO works with bob's mods properly.
I don't remember exactly but removal of peaks for ore might had some strange effects also.