Field or function to get the real spawner entity of an entity (non-callback request)

[drpandacat]

This addition could allow for properly identifying the entity that spawned another entity for those whose Parent or SpawnerEntity fields refer to a different entity.
Tears fired by tear-copying familiars (Incubus, Gello, etc.) are indistinguishable from tears directly fired by the player until 1 frame after being fired.
It's possible there are more examples of this but this is the most common one I can think of

[ConnorForan]

The main thing to know with this request (at least when suggested so generally) is that if the game did not place the ""real"" spawner entity as the SpawnerEntity or Parent of an entity, then the game did not keep track of the ""real"" spawner entity, full stop. The spawn function itself only takes the SpawnerEntity as a parameter, and many things in vanilla do not even do that much.

So what this means is that to do this, every single relevant case would need to be handled separately. There would be no catch-all solution for this, from an implementation perspective. Given the circumstances this also means that many relevant cases would also be difficult to implement solutions for, potentially requiring patching into the middle of a function. Even the familiars aren't guaranteed to be consistent in how this gets handled between them.

It could be possible for us to add some sort of ""real spawner entity"" field from the perspective of the lua api but, still, each individual relevant case where you would expect it to be populated would need to be implemented separately, and we'd also need to do extra work to keep that "field" cleaned up to make sure it won't point to a removed entity. I am unsure if such an approach would be ideal or not, depends on how many applicable cases it would have compared to just finding a solution for the familiar issue you mentioned as its own thing, such as a new callback if none of the available callbacks are applicable.

Basically it may be more appropriate to treat each case separately and find a good solution for each. If there are a bunch of practical applications for a new entity field it may be worth making one, but it won't necessarily make it any easier to implement.