on_item_request_removed

[DaveMcW]

I would like to know when an item-request-proxy is cancelled or completed. I don't care about items (because apparently that is hard). I just want to know when my item-request-proxy is removed and which entity (if it still exists) was the target.

[Arcitos]

+1

Dear devs,
please make completion and cancellation of entity-type "item-request-proxy" detectable. Currently there is no efficient way to get information about this, because the "death" of item request proxies is also not covered by event.on_entity_died().

Regards,
Arcitos

[quyxkh]

I think the problem with this might be that mods can fulfill those requests themselves, there's no way to know what's going to happen when a mod reads an entity's `item_requests` or sets it nil.

[Arcitos]

[...] there's no way to know what's going to happen when a mod reads an entity's `item_requests` or sets it nil.

If the "item_requests"-value of a item-request-proxy is set to nil, the item-request-proxy is fulfilled and subsequently removed (i tested this a few minutes ago). It doesn't matter if this is done by drones or by setting it to nil via script. I just want to know that an item-request-proxy has been fulfilled/removed.

[moon69]

This would be handy.

[Rseding91]

Why?

[DaveMcW]

The general use case is to make complicated buildings that require multiple items to build. Instead of a ghost, you build a chest with an item-request-proxy, then check every tick if it has the complete set of items to build it. This event would remove the requirement to check every tick.

My specific use case was for Blueprintable Trains, which is no long needed now that they are in the base game.

[moon69]

Similar to Dave really - I want to avoid plopping complete things down, but rather build them in stages.

I'm also working on a construction bot based ammo/fuel filling station.

Is it an expensive thing to implement or make performant? I assumed the game already knows when the request is complete as it removes the proxy?

[eradicator]

+1
For progressively building structures like in traditional RTS games. I.e. if something needs 100 wood planks then every plank delivered builds 1% of the structure.

If the proxy entity knew which bots are heading towards itself (i.e. something like LuaEntity.bots_ordered_to_build_this (table or nil)?) then it would at least be possibly to make a cheaper polling solution in script by estimating the bots arrival time based on max_speed. Ofc an event would be much cleaner so that's just my usual "maybe that's easier to implement" compromise.

[Rseding91]

+1
For progressively building structures like in traditional RTS games. I.e. if something needs 100 wood planks then every plank delivered builds 1% of the structure.

If the proxy entity knew which bots are heading towards itself (i.e. something like LuaEntity.bots_ordered_to_build_this (table or nil)?) then it would at least be possibly to make a cheaper polling solution in script by estimating the bots arrival time based on max_speed. Ofc an event would be much cleaner so that's just my usual "maybe that's easier to implement" compromise.

That's a completely different request: on-item-delivered - and it's not going to happen.

The original request for an event when the proxy is being deleted because it was fulfilled might happen.

[Oktokolo]

That's a completely different request: on-item-delivered - and it's not going to happen.
The original request for an event when the proxy is being deleted because it was fulfilled might happen.

If on-item-request-proxy-complete gets implemented, someone could use it for incremental building by creating one proxy per build stage.
That would certainly not be as UPS-friendly as on-item-delivered. But it might (or might not - would have to be benchmarked) still be better than checking the current state each 6th tick (100ms response time).

[Rseding91]

That's a completely different request: on-item-delivered - and it's not going to happen.
The original request for an event when the proxy is being deleted because it was fulfilled might happen.

If on-item-request-proxy-complete gets implemented, someone could use it for incremental building by creating one proxy per build stage.
That would certainly not be as UPS-friendly as on-item-delivered. But it might (or might not - would have to be benchmarked) still be better than checking the current state each 6th tick (100ms response time).

That would end up taking more CPU time overall because 5 robots would have to get sent out vs 1 with all the items.

[eradicator]

That's a completely different request: on-item-delivered - and it's not going to happen.

The original request for an event when the proxy is being deleted because it was fulfilled might happen.

I think you completely misunderstood my post, there was no request in that post. But if on_item_request_removed happens it doesn't really matter.

[Oktokolo]

If on-item-request-proxy-complete gets implemented, someone could use it for incremental building by creating one proxy per build stage.
That would certainly not be as UPS-friendly as on-item-delivered. But it might (or might not - would have to be benchmarked) still be better than checking the current state each 6th tick (100ms response time).

That would end up taking more CPU time overall because 5 robots would have to get sent out vs 1 with all the items.

Yes, that probably kills cosmetic build stages.

[DaveMcW]

I found another use case, I would like to know when a newly built locomotive is refueled.

[PFQNiet]

Does "register_on_entity_destroyed" not work for item request proxies? Because that might be a helpful first step. You'd have to determine if it was caused by the requesting entity being destroyed, or the player cancelling the request, or it being fulfilled, but it could be wrangled.

Alternatively, keeping a table of item request proxy entities and looping over that every tick... It might sound bad but I have to wonder how many of them you expect to have at any given time. Unless you expect there to be hundreds of thousands of them, I wouldn't worry so much about UPS - especially if most of the time the number is more like zero because everything is fulfilled. "Iterating" over an empty table takes a mere nanoseconds.

[DaveMcW]

Does "register_on_entity_destroyed" not work for item request proxies?

Sadly it does not. But that would also work for me if it was implemented!

[ickputzdirwech]

Does "register_on_entity_destroyed" not work for item request proxies?

Sadly it does not. But that would also work for me if it was implemented!

It does work for me. Did they implement it only very recently?

[DaveMcW]

It seems they did, this can be moved to Implemented mod requests!