Repository navigation
Component that gives any entity Trigger-like behaviour #1116
Description
Activity
peak
also i do feel like the arbitrary "thing that triggers things" → "thing that gets triggered" mapping would be nice, but that's perhaps out of scope..
thinking about something like "thing that triggers [custom touchswitch like thing]" component, triggering "triggerable [custom touchswitch like thing]" componentsthinking about something like "thing that triggers [custom touchswitch like thing]" component
I don't think this belongs as a component. Also the
Triggerables are intentionally only updated as part ofPlayer.orig_Updatelike normalTriggers, and I think they should probably stay contained that way.Reacted by microlith57@microlith57 not sure if this is what you're talking about (maybe I misunderstood you initially), but I was thinking it could definitely be done with entity type matching. I feel that
TriggerZonemight be a better name given you can pass it a collider and have any arbitrary number of them. We don't need separate source/target pairs since they pretty much do the same thing.class TriggerZone : Component { Action OnEnter... etc. } // triggered by any TEntity class EntityTriggerZone<TEntity> : TriggerZone where TEntity : Entity { } // triggered by any entity with TComponent class ComponentTriggerZone<TComponent> : TriggerZone where TComponent : Component { } // triggered by Player class PlayerTriggerZone : EntityTriggerZone<Player> { } // triggered by TheoCrystal, Glider, etc. class HoldableTriggerZone : ComponentTriggerZone<Holdable> { }
For an entity that acts as the "target" (such as a spring, refill, etc.)
// a better version of PlayerCollider mySpring.Add(new PlayerTriggerZone(optionalCollider)); // a better version of HoldableCollider mySpring.Add(new HoldableTriggerZone(optionalCollider));
For an entity that acts as the "source" (such as player, puffer, etc.)
// if for some reason you wanted the player to enter/stay/leave anything with a Sprite player.Add(new ComponentTriggerZone<Sprite>(optionalCollider)); // if for some reason you wanted the puffer to enter/stay/leave any subclass of Spikes puffer.Add(new EntityTriggerZone<Spikes>(optionalCollider));
We would assume the
TriggerZonecollisions/triggering is done inTriggerZone.Update, which means that for anyTriggerZones added directly to thePlayerentity, they would lag one frame behind calls toPlayerListenerandTriggers since player movement happens afterbase.Update(). I believe the same applies toPuffer,TheoCrystal, andGlider. Not sure how we would handle this.Does this all sound too much?
As a side note, it would be nice to be able to pass "entity or component" as a constraint and not need to have two separate generic types. The only reason I care about the difference is whether I do
CollideorCollideByComponent.Maybe we could add
ITrackableto bothEntityandComponent, then addCollideByTrackablein the tracker that will just pick the right one. That would allow something likeTriggerZone<T> where T : ITrackable.Edit: Given not all entities or components are trackable, we'd probably want something like
ISceneItem.this is a good idea. i think the arbitrary source/target stuff is distinct enough to be a separate feature / pr
i approve ofISceneItemalso
I am planning on implementing this myself
Yes
Describe your request
Essentially, the code modder can add a component to their entity that gives the
OnEnter/OnStay/OnLeavefunctionality as if it were aTrigger. This means modders will no longer need to manually trackCollideChecks across frames in the entityUpdate.I've currently named the component
Triggerableto be similar in naming toHoldable, and the actionsOnEnter/OnStay/OnLeave, with their virtual invocation methods calledInvokeOnEnter/InvokeOnStay/InvokeOnLeavein case the modder wants to override the component instead of assigning actions.These actions (or method groups) can be passed into the constructor and/or assigned directly in the object initialiser. The first argument is an optional collider to use instead of the entity's Collider property.
Since colliders can be specified, this means multiple trigger regions can be assigned to the same entity if desired, each with different functionality.
This is an example where I've added three separate trigger regions to a gravity field, using different instantiation styles.
triggerable.mp4
Additional context
No response