loadEngineInjection

[anselm]

Summary

load engine injection

References

closes #insert number here

QA Steps

[speigg]

Typescript error:

src/behave-graph/nodes/Profiles/Engine/Events/onCollision.ts(105,5): error TS2304: Cannot find name 'startSystem'.

[HexaField]

rather than checking for the trigger component, we should add it to the collisionQuery, we can then ensure it exists

[anselm]

There is no concept TriggerComponent to query against. It is just a mode... and sometimes it is null. In fact avatars don't even have a ColliderComponent (or at least I get a runtime error occasionally that the avatar doesn't have this). I think the avatar is special and the root entity may not have that component - but instead there may be a collision capsule somewhere else in the avatar children graph?

[anselm]

It feels like that code has some kind of defect conceptually. Imagine a pairwise collision between a trigger volume and an avatar. The avatar in this case will be the triggerEntity (the entity that triggered the collision). This code is then looking through the avatar for triggers ...

Maybe the intention was to fetch the list of triggers from the trigger volume - so:

const triggerComponent = getComponent(triggerEntity, ColliderComponent)

Should be:

const triggerComponent = getComponent(entity, ColliderComponent)

?

[anselm]

The risk of correcting or changing this is I don't have any kind of way of knowing if will impact anything. I don't know if our tests cover this case, or if this code is ever exercised. I don't think my code relies on this - and I don't know if there are any apps or demos that rely on it; or how to test it.

[HexaField]

oh i see, i think this can be cleaned up and work as i said, now that we have CollisionComponent being generated when there is data and removed when not

[anselm]

Um, ok, but there are conceptual issues still:

• things entering that code don't always have a trigger -> either because avatar doesn't have one directly, OR because it is the receiving side of a triggerable interaction? which shouldn't need a trigger

• that code may just be broken / may never have worked / may never have been tested? the test I added to block the crash may be actually due to testing the wrong object for a trigger?

[anselm]

I think it's best if I revert TriggerSystem.ts and treat that as a separate issue rather than trying to merge that in with this commit since this commit is languishing. The issue doesn't come up for me now due to fixes elsewhere, and examining TriggerSystem can be done as a separate commit.