Get list of spidertrons following a certain spidertron

[Xorimuth]

I can find the spidertron that a certain spidertron is following using LuaEntity.follow_target (https://lua-api.factorio.com/latest/Lua ... low_target). Would it be possible to get the reverse? For example LuaEntity.targets_following -> array of spidertrons.

-----

Workarounds

1. Do find_entities_filtered on the entire surface to find all spidertrons, and check each one for a follow_target. Prohibitively slow.

2. Listen on every on_player_used_spider_remote -> check to see if that spidertron has a follow_target -> store spidertron in global table under its target. Drawbacks are:
- If follower spidertron's command is cancelled then spidertron will be in global forever (can be mitigated by rechecking follow_target when looking the following spidertrons up or by this API request/workaround: viewtopic.php?f=28&t=88859)
- Lots of extra code to write and maintain

[PFQNiet]

I personally would disagree with "prohibitively slow". Generally yes iterating all entities of a type on the surface is not the best idea, but think about the scale of the problem here.

Iterating every transport belt would be prohibitively slow, as there are frequently thousands of those. Hundreds of thousands perhaps.

But spidertrons? Sure the player can build as many as they want, but rarely will you have 100+ of them. And I'd be amazed if you ever saw 1000+ of them.

Iterating a relatively small number like that is plenty fast enough, so I'd go with that. If a player really does build 1000 spidertrons, they probably have bigger UPS problems than your script checking for followers.

[boskid]

It is really unlikely to be ever implemented.
Internally spider which is following other entity simply has a pointer to that entity for quick access to its position. In general entity that is pointed to is not aware who has pointers to it (there are some tiny exceptions). It could be done but it requires some effort for a single specific use case which can solved completly on the lua side.

If amount of spiders is reasonable, you can perform initial find_entities_filtered to search for all spiders and keep them in table and listen for all events related to creating and destroying spiders: that way you will be able to skip the find_entities_filtered search. Having up to date vector of spiders you can iterate them to find those who are following your entity in reasonable time.

[Xorimuth]

Thanks for the info. I went ahead and implemented my workaround, which should work reasonably well. If you want to see it, it is this commit: https://github.com/tburrows13/Spidertro ... 8346103152

[Xorimuth]

I personally would disagree with "prohibitively slow". Generally yes iterating all entities of a type on the surface is not the best idea, but think about the scale of the problem here.

Iterating every transport belt would be prohibitively slow, as there are frequently thousands of those. Hundreds of thousands perhaps.

But spidertrons? Sure the player can build as many as they want, but rarely will you have 100+ of them. And I'd be amazed if you ever saw 1000+ of them.

Iterating a relatively small number like that is plenty fast enough, so I'd go with that. If a player really does build 1000 spidertrons, they probably have bigger UPS problems than your script checking for followers.

Indeed I just tried it and it seemed to run ok. Maybe I'll switch to that if my dodgy events-based system doesn't work well. I had assumed that find_entities_filtered speed basically depended on the area search, but I now see that that isn't true.

[Rseding91]

I had assumed that find_entities_filtered speed basically depended on the area search, but I now see that that isn't true.

It does. The area searched and how many things are in that area both contribute to the total cost linearly.