Additional check on chunk generation

[ZlovreD]

Hello, orzelek. Could you please add additional check for entities already placed on surface before generate resources?
I'm planning to release a mod with on_chunk_generated event handle and i found what sometimes RSO generate resources over entities already placed by my mod.
I have my own check to existing resources before placement, but it works only if game generate resources by itself. Otherwise, seems my mod work faster than yours.

Something like as adding surface.count_entities_filtered check somewhere in roll_chunk function @1426 with custom type and ghost_type tables, also with invert option, which i can modify on final-fixes stage. Couse there is no collision mask for buildings as i know.

[darkfrei]

With some tricky code you can place your entities in one tick after chunk generation.

Default collision mask:

Code: Select all

collision_mask = { "item-layer", "object-layer", "player-layer", "water-tile"}

https://wiki.factorio.com/Types/CollisionMask

[eradicator]

With some tricky code you can place your entities in one tick after chunk generation.

Or do the right thing and add a dependency if you want to load after RSO. I strongly advise against any form of "one tick delay" for any usecase. If you think you need it is in 99% of cases a huge warning sign that you're doing something very wrong.

[ZlovreD]

With some tricky code you can place your entities in one tick after chunk generation.

Idk how many ticks may pass after event occur and when rso generate resources.
And as i saw it may takes more than second on huge map, or with low UPS, multiple generation events per second and ect.. Such delay is unacceptable.
And i'm come here not because i'm lazy.

Default collision mask:

Code: Select all

collision_mask = { "item-layer", "object-layer", "player-layer", "water-tile"}

https://wiki.factorio.com/Types/CollisionMask

Couse there is no collision mask for buildings as i know.

[ZlovreD]

With some tricky code you can place your entities in one tick after chunk generation.

Or do the right thing and add a dependency if you want to load after RSO. I strongly advise against any form of "one tick delay" for any usecase. If you think you need it is in 99% of cases a huge warning sign that you're doing something very wrong.

Already did it when start writing mod. But it usefull only on "data.raw" stage and almost pointless in "control" stage with event handling.

[eradicator]

With some tricky code you can place your entities in one tick after chunk generation.

Or do the right thing and add a dependency if you want to load after RSO. I strongly advise against any form of "one tick delay" for any usecase. If you think you need it is in 99% of cases a huge warning sign that you're doing something very wrong.

Already did it when start writing mod. But it usefull only on "data.raw" stage and almost pointless in "control" stage with event handling.

Events in control stage are still handled in mod-dependency-order. So unless you're listening for a different event it should work.
In any case the collision mask wouldn't help, because create_entity doesn't care about collision if the mod doesn't explicitly check it.
What kind of entity are you placing?

[darkfrei]

Couse there is no collision mask for buildings as i know.

https://lua-api.factorio.com/latest/Lua ... ision_mask

[ZlovreD]

Events in control stage are still handled in mod-dependency-order. So unless you're listening for a different event it should work.

Yes but how to explain different delays between actual events and entity/resource generation? I think it depends on amount of api calls.

... mod doesn't explicitly check it.

That why i'm here.

What kind of entity are you placing?

Vanila buildings (walls, furnaces, inserters, ect.)

[ZlovreD]

https://lua-api.factorio.com/latest/Lua ... ision_mask

And which mask would explicit for buildings w/o trees and rocks, which is also an entity?
For now, I only know one solution for my problem - adding an additional check to the RSO, as I wrote in the first post. With checks on both sides (with mine for resources and RSO for building), and then, i'm sure, no more collisions.

[darkfrei]

So you can get collision mask for selected entity (not tested):

Code: Select all

/c game.player.print('collision_mask = '..serpent.line(game.player.selected.prototype.collision_mask))

[ZlovreD]

So you can get collision mask for selected entity (not tested):

Code: Select all

/c game.player.print('collision_mask = '..serpent.line(game.player.selected.prototype.collision_mask))

Collision masks is some kind of predefined arrays of types. And problem in what anyone can write their own mod with their own new building types.

Anyway, what are you talking about? I have problem with delayed resource generation by RSO. I'm fine with my own generations. So i'm asking not even about mod support, just about universal solution for all kind of such things.

[orzelek]

RSO doesn't do any delayed resource spawning as of now. Whole ore patch is spawned in chunk generation event - it might cover more then chunk from this event. Collision mask checks are done but buildings are legal locations for ore placement so it will go under buildings.

I think that the parts out of current chunk are going under your spawned buildings. Delaying of spawning by tick on your side will not fix this (it's enough that neighbouring chunk rolls huge ore patch later on).

As for doing searches... that will create few problems. One is performance - placement is already heavy on searches to validate the ore locations and doing additional potentially large area entity searches would make it even worse.
Second potential problem would be tying this to collision avoidance algorithm that currently uses tile checks to move the ore patch if it would have a big overlap in current spot. This algorithm has +/- 1 chunk area to look for better patch location and in theory it should then take into the account all the entities found by search by looking at their location and size.

If you can provide a list of excluded entity types to search for I can add an option that would scan ore patch area. It would remove the whole patch when anything colliding is found (most likely would need this for enemy bases unless they are ok over buildings?). Trying to tie this to collision avoidance seems like pretty big improvement and would require lots of testing. And fiddling with collision masks discussed above. Performance would also get even worse probably since I'd need to actually get all the entities in the area not only their count.
Instead of an option it could also be made into remote interface that would allow your mod to enable collision checks automatically when present. Most likely table of entity types would be in the remote call then. I'll just need to find a way to nicely merge tables if there would be more calls of the interface from different mods.

[ZlovreD]

RSO doesn't do any delayed resource spawning as of now.

As i've mentioned, it may happens because of RSO manipulations with searching right place or even because of amount of api calls. Idk and this is hard to reproduce for testing.
I'd testing my own mod adding movement speed bonuses and rising game speed more than in 10 times and start running to the horizon. =)
On such speeds i can getting more than 100 chunk events per second. So maybe i'm just overreacting and it's core game problem.

As for doing searches... that will create few problems. One is performance - placement is already heavy on searches to validate the ore locations and doing additional potentially large area entity searches would make it even worse.

This can be bypassed by adding checks into chunk generation but disabled by default, because filter table is empty. And some "injection point", like adding into data-update.lua public variable for it; or additional remote call to fill this table. And anyone like me, who need such option - will be happy and all additional system load fall on their(my) shoulders.

Second potential problem would be tying this to collision avoidance algorithm that currently uses tile checks to move the ore patch if it would have a big overlap in current spot. This algorithm has +/- 1 chunk area to look for better patch location and in theory it should then take into the account all the entities found by search by looking at their location and size.

How much can this be unpredictable in this case?

If you can provide a list of excluded entity types to search for I can add an option that would scan ore patch area. It would remove the whole patch when anything colliding is found (most likely would need this for enemy bases unless they are ok over buildings?).

Much easier to use "invert' option in count_entities_filtered, and describe all trees,rocks, cliffs and so on, than make list of all vanilla buildings and hoping that no more mods not to be installed with custom buildings.

[orzelek]

From what I recall when you force game to generate lots of chunks they are created as incomplete and actual chunk generation event is only called after base gen has been done - that can happen much later if you queue lots of chunks in this way. You can see this because trees will appear on chunks with a dealy - at least it was like that some time ago. I didn't look closely in current version of Factorio.

I'll add entities search based on what you would need for it to work properly. And cliffs are not a problem - I think they collide with ore currently so are handled on collision check. Maybe check if area contains anything other then trees would work. With some external trigger in form of remote call to actually activate the functionality. And it won't bypass performance cost - it will only make it happen if your mod is present but cost will be there for each ore spawn.

I'm not sure I understand your question about unpredictability. Ore is spawned in a given location or not at all if collision would be detected. How it will affect ore layout is down to rng - and it could vary a lot depending on density of ore and your spawns.

[ZlovreD]

I'm not sure I understand your question about unpredictability. Ore is spawned in a given location or not at all if collision would be detected. How it will affect ore layout is down to rng - and it could vary a lot depending on density of ore and your spawns.

I meant how far from initial point resources may be placed on surface. Thinking about what if i expand territory for my areas, which may be more than one chunk wide/tall (i'm assume you already figure out what my mod doing) further into undescovered territory.

[orzelek]

I'm not sure I understand your question about unpredictability. Ore is spawned in a given location or not at all if collision would be detected. How it will affect ore layout is down to rng - and it could vary a lot depending on density of ore and your spawns.

I meant how far from initial point resources may be placed on surface. Thinking about what if i expand territory for my areas, which may be more than one chunk wide/tall (i'm assume you already figure out what my mod doing) further into undescovered territory.

This is the part of the topic no-one seems to be sure how it works. I know that ore patches can easily have 5 chunks in radius but things start getting problematic if they go to big. There is a point where game will start rejecting spawns if it goes to far out from current chunk. This is why size multiplier is now limited to 3 in mod settings.

I'm not sure how this works internally in game and how it ties to on chunk generated event for those other chunks.