Rename observer entity methods and fields

[Vrixyz]

• Trigger fields have been confusing to use, discussion on discord from https://discord.com/channels/691052431525675048/692572690833473578/1328735161474482216 suggested a new implementation:

current	proposed	comment
??? (when exposed through event (see pointer: trigger.event().target))	trigger.target	the thing that event was fired on
trigger.target	trigger.observed_on	the thing that the event was received on
trigger.observer	trigger.observed_by	the entity holding the observer state

I'd personally like to see a practical implications of that over recent work of #19245.

[hukasu]

Related (maybe)

• feat: allow for Trigger to provide the Entity on which an event w… #18710
• Distinguish .target() and .target in Trigger<Pointer<E>> #18982

[alice-i-cecile]

@cart:

I do have thoughts on (1). From my perspective, observed_on / observed_by forces the user to think about the distinction when in 99.99% of cases they only need to care about one of the two (observed_on / "the target")

[cart]

Yup. To expand on my discord thoughts: if you're asking "which observer entity is handling this event", you are likely an "internals developer" of some kind, not a normal game logic developer. We should have a nice friendly / snappy name for "the entity the event was triggered on" (ex: trigger.entity(), trigger.target(), trigger.on()). trigger.entity() is honestly my favorite. Its pretty unambiguously "the entity this event was triggered on", and it is likely the first name normal users will look for. Iirc we invented the "target" term to appease the internals developers that considered entity ambiguous, but I don't think that will be true in practice.

[alice-i-cecile]

I think that something like .observer_entity() is probably a good choice for the internals type. Longer, and clearly mentions that it's the observer.

[cart]

Actually "target" is used elsewhere as a "core" term (ex: world.trigger_targets(event, [e1, e2])), so using that term here does make some sense.

[cart]

The Pointer::target storing the original "non bubbled" entity might be worth rethinking too to avoid confusion (ex: maybe that should live on Trigger, rather than on the Pointer event itself).

[Diddykonga]

Actually "target" is used elsewhere as a "core" term (ex: world.trigger_targets(event, [e1, e2])), so using that term here does make some sense.

While true, I think trigger_entities works just as well.

I like:
trigger.observer_entity() - The Observer Entity
trigger.origin_entity() - Entity that was triggered by the user originally
trigger.entity() - Origin Entity or Entity the event has propagated to via relations

Most cases will use entity(), and in the cases where they need to know the origin_entity() it is available and can be compared against entity().

[cart]

trigger_entities doesn't cover the "component target" case (and notably that API already covers that).

[cart]

Perhaps we could statically constrain it like trigger_entities<E: Event<Target=Entity>> and trigger_components<E: Event<Target=Component>>. I don't personally have an event case that would require supporting both (although I also haven't fully conceptualized what an observer-driven query cache looks like).

[Diddykonga]

Either:

1. Component Targets are removed from the API and generic on the Event Types, as you suggested potentially on Discord. (Would be interested to know the extent of use of this feature, does anything use it besides Lifecycle Events 🤔 )
2. Components as Entities turns them into entities, although I don't exactly know how that API would look like given that change.