Logistics robot collect/drop off event

[Deadlock989]

Could we have an event similar to on_picked_up_item, but for robots instead of players? Like on_robot_mined but when it interacts with logistics chests.

I want to do things to bots when they pick up certain items. Bad things.

Alternatively, and this may be harder, can we have a way of marking items as non-transportable by bots?

[bobingabout]

Could we have an event similar to on_picked_up_item, but for robots instead of players? Like on_robot_mined but when it interacts with logistics chests.

I want to do things to bots when they pick up certain items. Bad things.

Alternatively, and this may be harder, can we have a way of marking items as non-transportable by bots?

My first thought was... it's a bad idea, lots of events generated that 99%+ of the time would be useless, just wasting CPU power, but if you already have a call for construction robots, it changes my thought to... why not?

An item filter isn't just a bad idea either, it does feel strange when a single small robot can carry a locomotive, or a rocket silo.

[Deadlock989]

I suppose. I have no idea what the runtime burden for an event that no mod actually uses is. The scenario I have in mind would be inhibiting mass logistics bot use, so it wouldn't matter, as long as it didn't adversely affect vanilla players.

I don't build mega-bot bases myself but I do use construction bots a lot, and I'd guess that construction tends to cap out mid-game while logistics bots would continue to increase as you scaled production. That may be why the construction bot events aren't really a problem. You only really need a ton of construction bots if you do a lot of tile paving (would be really, really nice if construction bots could carry more than 1 tile, or if tile items paved a mass of nearby ghosts, just like players can mass-tile in one go).

I did also think about asking for events on setting filters but it doesn't help in my case as you still wouldn't be able to stop items being dumped into active providers etc.

[mrvn]

Wouldn't it be better for the chest to have an item_added and item_removed event?

And by that I mean the actual entity. Not an event for every item that is added/removed from a chest world wide.

[Deadlock989]

You mean just logistics chests? I don't see the benefit, and you'd have to filter out whether it was a player or a robot or an inserter etc. doing the depositing. Personally I only care about the robots.

[mrvn]

Could be logistic chest, could be a normal chest. The important part is that the event gets bound to a specific chest and only triggers when that chest has activity.

No need to get an event for every bot that picks something up or drops something off just so you can filter if it actually interacted with the chest you are interested in.

[eradicator]

Alternatively, and this may be harder, can we have a way of marking items as non-transportable by bots?

I'd love a way to restrict certain items from being transported by players(!)/inserters/bots. But i fear that would also be pretty performance heavy to check on a per-item-basis. :/.

[Deadlock989]

Could be logistic chest, could be a normal chest. The important part is that the event gets bound to a specific chest and only triggers when that chest has activity.

No need to get an event for every bot that picks something up or drops something off just so you can filter if it actually interacted with the chest you are interested in.

That's not how events work. And I am literally interested in every bot and every chest.

[Supercheese]

Alternatively, and this may be harder, can we have a way of marking items as non-transportable by bots?

I'd love a way to restrict certain items from being transported by players(!)/inserters/bots. But i fear that would also be pretty performance heavy to check on a per-item-basis. :/.

You can already restrict a player from transporting certain items, thanks to the various on_player_changed_X_inventory events.

[eradicator]

Alternatively, and this may be harder, can we have a way of marking items as non-transportable by bots?

I'd love a way to restrict certain items from being transported by players(!)/inserters/bots. But i fear that would also be pretty performance heavy to check on a per-item-basis. :/.

You can already restrict a player from transporting certain items, thanks to the various on_player_changed_X_inventory events.

All those events are only raised after the player has already picked up the item. They also don't tell you what changed or where the change came from. So the only thing you can do is drop items on the floor that the player shouldn't carry, and at a heavy performance penalty.

[Deadlock989]

Not really on topic

[Rseding91]

Such an event would be fired too often that it would have an unacceptable performance impact.

What you're trying to do is simply outside of what the game was ever designed to do. Like trying to make belts not support specific items - it's just not going to happen unless you want to sacrifice virtually all of your performance.

[Deadlock989]

Oh well, it was worth asking.

[bobingabout]

Such an event would be fired too often that it would have an unacceptable performance impact.

What you're trying to do is simply outside of what the game was ever designed to do. Like trying to make belts not support specific items - it's just not going to happen unless you want to sacrifice virtually all of your performance.

This was my initial thought, yeah.

When you understand how events actually work anyway.

1. Something triggers an event.
2. an event is created, this means you create a new class item, and push it into this tick's event vector... In short, it makes data and costs RAM
3. When all events have been created, the script is run through the control.lua of every mod. so every instance it checks if an event tag equates to that type of event, it's reading memory.
4. if it matches, it runs that script

Add all this up with tens, or hundreds of thousands of robots flying about, and you've suddenly got hundreds or thousands of events generated and checked several times every second that you didn't have before, slowing the game performance down.

[steinio]

But at the end... Bots are nerfed

[Deadlock989]

When you understand how events actually work anyway.

OK, we get it, you're clever.

There wouldn't be "hundreds or thousands of events generated and checked several times every second" because even when you have a swarm of 10000 logistics bots, they don't all pick something up or drop something off every second.

But if the overhead is too high then it's too high. Discussion over.

[eradicator]

When you understand how events actually work anyway.

OK, we get it, you're clever.

Hostility doesn't help anyone. You made a request that had a very low chance to be implemented. Every semi experienced modder who has ever requested a new event knows this. Bob tried to explain it to you or anyone who might read this thread afterwards. That's all.

[Deadlock989]

I came here to talk to the Factorio devs. Not randoms.

[mrvn]

Such an event would be fired too often that it would have an unacceptable performance impact.

What you're trying to do is simply outside of what the game was ever designed to do. Like trying to make belts not support specific items - it's just not going to happen unless you want to sacrifice virtually all of your performance.

This was my initial thought, yeah.

When you understand how events actually work anyway.

1. Something triggers an event.
2. an event is created, this means you create a new class item, and push it into this tick's event vector... In short, it makes data and costs RAM
3. When all events have been created, the script is run through the control.lua of every mod. so every instance it checks if an event tag equates to that type of event, it's reading memory.
4. if it matches, it runs that script

Add all this up with tens, or hundreds of thousands of robots flying about, and you've suddenly got hundreds or thousands of events generated and checked several times every second that you didn't have before, slowing the game performance down.

Which actually means we should have more specific events.

Take for example the Logistic Train Network mod. It has to listen to events for trains it controls and LTN stations. But there is no way to listen to events for specific trains or specific train stops. So it has to listen to all trains and all train stops and then filter out those that are actually interesting.

If entities could have events then the C++ code for trains and train stations that now triggers the event could check if any mod is interested in that event for that specific entity. And only if someone has registered an event handler the event gets created and consumes time and resources. That way adding an event handler for one entity doesn't significantly impact all entities of that type.