Triggerenter Problem

Help & Support
1

Hello all, I’m new in PlayCanvas and I’m making some small games to understand if the game engine can fit my needs.

I have a problem with the triggerenter event, this event seems to be raised on the trigger entity (the one with only the collision component) but not on the rigidbody entity (the one with both rigidbody (kinematic) and collision component). From the documentation (https://developer.playcanvas.com/en/api/pc.CollisionComponent.html) it seems that this event should be raised on both the trigger entity and rigidbody entity.

This is the test scene: https://playcanvas.com/editor/scene/848732
I have a BallProva script that register onTriggerEnter to triggerenter event. If I add BallProva to the trigger entity (LeftWallTest) it print correctly on the console (so the event is rised). If I add BallProva to the rigidbody entity (BallTest) there are no print to the console (so the event is not rised).

What is wrong with my script?

2

Hi @Dave_C and welcome!

I think the issue here is that there is no entity that acts as a trigger.

When two entities collide the onTrigger events will fire only if one of the two is a trigger. For an entity to act as a trigger it should have only a Collision component and not a rigid body component. As then it would be part of the physics simulation.

If you haven’t already done, take a look at the following tutorial it explains a bit more on the subject:

https://developer.playcanvas.com/en/tutorials/collision-and-triggers/

3

Hello Leonidas, thank you very much for your answer.

I don’t know if you opened up the project, but there is exactly the entity trigger (the one with only a Collision component), and if I add the script to that entity the triggerenter event is rised. The problem is that this event is not rised on the entity with the rigidbody that trigger with the entity trigger :slight_smile:

4

Right, I am not sure that is a bug or something expected and the docs are in error here (since they state that the event will fire in both entities, both the trigger volume and the rigidbody entering the volume).

There is an issue about that in the engine repo, you can submit your findings as well so someone can take a look at:

For the moment as a workaround, on the trigger volume when the events fire, you get the other entity as an argument returned:

BallProva.prototype.onTriggerEnter = function(other) {
    console.log ("OnTriggerEnter, entity entered: ", other);

   // example custom event
   this.app.fire('ball:onTriggerEnter');
};

So you can easily add an event listener to a script attached to the other entity and manually fire it to inform it of this event happening.

MyOtherScript.prototype.initialize = function() {

   // example custom event
   this.app.on('ball:onTriggerEnter', function(){
      console.log('ball is on trigger!');
   }, this);
};
1 Like
5

Hello Leonidas, thank you soo much to answer me and give me this workaround. I will definitively submit my findings on that github issue.

Thank you very much again!

1 Like
6

Seems to me this is broken again,
I am only getting event on the trigger volume and not on the rigidbody itself,

7

Test project:
I have attached same script to Box and the plane, of trigger enter, only the plane is firing the event to the console ( open console to check) .
https://playcanvas.com/editor/scene/975092

8

If the entity has a rigidbody, the triggerenter is fired on the rigidbody, not the collision.

That documentation needs to be worded a little better.

1 Like
9

In other words:

CollisionHandler.prototype.initialize = function() {
    this.entity.collision.on('triggerenter', this.onTriggerEnter, this);
    
    if (this.entity.rigidbody)
        this.entity.rigidbody.on('triggerenter', this.onTriggerEnter, this);
};
1 Like
10

Thanks guys.
Yes Yaustar, maybe docs need some changes in that regard.

11

Yeah, the table is there to say which events are fired on which component like so:

image
image1684×792 55.1 KB

So the triggerenter is fired on the trigger volume (red box) and on the rigidbody (blue box)

1 Like
12

To be fair, this table was a bit confusing to me too. Perhaps an example could be added on how to read it. I mean, I can look at the bottom left and say, hey, so here is a trigger volume, follow to the right, and see that it shares the trigger events with rigidbody. Eurika. But it won’t work. Once you know that rigidbodies and triggers fire different events of the same name, then it makes sense, but may be confusing if you are not familiar.

13

Hello,
I wanted to know if it would be a problem if the trigger volume was moving?

In my code, I have the trigger volume change position based on its parent’s position.
This trigger volume only has a collision component and no rigidbody. but the “triggerenter” event never gets called.

Although if I give it a rigidbody and look for “collisionstart” event, the event gets fired.
But I want this entity to strictly be a trigger volume (based on the design of the game).

14

@theomkarpatil , moving triggers aren’t a problem against kinematic and dynamic rigidbodies.

https://playcanvas.com/editor/scene/1194343

When the trigger ‘enters’ the box rigidbody, hello is written to the console.

15

I have similar code setup in my project here: https://playcanvas.com/editor/scene/1185419

the warpsphere script has the code for onTriggerEnter (triggerenter event), but nothing is fired.

Holding Space button increases the size of the trigger volume (I confirmed this by debugging in the console)
‘A’ and ‘D’ key for left and right movement.

but the event does not get fired. its important to have the sphere set as trigger volume only as I don’t want it to push the entities it collides with.

16

I don’t see any triggers? Every object has a rigidBody

17

the warpshere entity, I disabled the rigidBody in the editor.

18

Ah, triggers aren’t created if there is rigidbody component, even if it’s disabled. You have to remove the component completely

1 Like
19

Can’t this be changed? Something like that could keep me busy for a long time because I would also assume that disabeling of a component should suffice.

1 Like
20

It most likely can be changed, but hasn’t been a pressing issue unfortunately to really allocate time for it in the short term.