Help w/ inserters, drop target, etc.

[hlship]

I'm working on a quality-of-life mod; first Factorio mod, not very experienced on Lua.

Goal: When you drop a logistic storage container (over an existing chest) it will check to see if there's an inserter for the container, and if that inserter takes from an assembler. If so, the mod will set the filter for the container to match the assembler's output. Further, it will remove the inventory block, if any, and replace it with a circuit network override on the inserter (i.e., "blue belts < 1000").

Just getting started, but when I'm having trouble with inserters.

Code: Select all

script.on_event(defines.events.on_built_entity, function(event)

    local box = event.created_entity
    local player = game.get_player(event.player_index)
    local surface = player.surface

    local inserters = surface.find_entities_filtered {
        -- TODO: Maybe entity.collision_box would work instead
        position = box.position,
        type = "inserter",
        radius = 1.0
    }

That finds the inserters, but the drop_target of each inserter is nil. I suspect its an order-of-operations issue, in that built-in logic hasn't recomputed that the inserter drops into the just-built container entity.

I think I can use drop_position and compare it to box.position, but I'm wondering if there's a correct way to do this, i.e., a built-in function on the LuaEntity that I'm missing?

[computeraddict]

From what I'm reading of the drop_target field, you can write to it. I'd try just iterating through the inserters and setting drop_target = box and doing whatever else you were going to do and see if anything breaks.

[hlship]

The goal here is not to change the insert's target, but identify which inserter's target is the newly dropped storage container, then work backwards to the assembler (if any) that's the source for the inserter, and finally to the recipe/item, to make that the filter for the storage container.

On my map, I drop a container onto the map in a spot pointed at by an inserter, but the insterer's drop_target is nil, when I'd expect it to be the new storage container.

[Deadlock989]

I suspect its an order-of-operations issue, in that built-in logic hasn't recomputed that the inserter drops into the just-built container entity.

This seems likely. I don't know when it gets set; maybe in the next tick, maybe whenever the inserter is next updated, maybe the next time the inserter picks something up and starts swinging towards a target, maybe only when the arm reaches drop_position for the first time - it's not documented so you'd have to set up a test that monitors drop_target over time if you really want to find out. But I think your intuition about using drop_position instead is probably the way to go. If given a position rather than an area, surface.find_entities_filtered matches any entities that collide with that position, rather than just those exactly at that position. So if the returned table of entities only has one member and it's your container that was just built, you know the inserter is going to end up dropping into it.

(If there happen to be overlapping entities returned and more than one of them is a container - not something that could happen in regular play but possible if some other mod has introduced shenanigans - then the waters are muddier and that is where setting drop_target might be more useful, but it's up to you if you want to cover that situation as well.)

You might also want to think about whether you want to handle ghosts.

[hlship]

Thanks for confirming some of my intuitions.

Ghosts: this QoL is when I upgrade all the chests in my hub from iron or steel chests into storage containers (or passive providers perhaps). I have a manual process where I wire up the inserter with a limit, update the container with a filter, and remove any block inventory slots (because the inserter handles that now). I just want that to automatically happen when I place (really, when I upgrade, but Factorio doesn't seem to differentiate that) a storage container.

Anyway, it doesn't apply to ghosts per se, because presumably the blue print would already have all the wiring. I'll be sure to run some experiments with blueprints & etcs. once I get the basics operational.