I made a door blueprint of a swinging door that always opens away from the player.
I use two trigger volumes on either side to check from which side the player is approaching and then trigger the opening with a smaller embedded volume.
The graph looks like this:
It works beautifully when I walk through the door. Opening and closing is just as it should be.
But for some reason, the projectiles wont travel through that door. They stop in mid air.
Any idea why
(Is the mesh rotated but not the collision? And if so, why do the projectiles get stuck and not ricochet like they do when I fire on a closed door?)
Sounds like the collision settings on TriggerA and TriggerB. If you stand further back, outside the trigger range, and fire at the door, does it hit the trigger box?
Iâm guessing since youâre inside either TriggerA or TriggerB, when you spawn the projectile, it just gets spawned inside a colliding area and stops immediately.
I would set the collision settings on TriggerA and TriggerB to overlap pawn⌠I think that should work.
Thanks for the tip
It were indeed the box volumes that caused the trouble. The boxes just repelled the projectiles like a solid object.
I changed the collision settings, but not to âpawnâ or âoverlappawnâ, (which did not work, same effect), but to âtriggerâ instead.
Sounds pretty stzraight forward now, since that is what the are used for :rolleyes:
Just one minor flaw in my design I cant get rid off:
When the player enters the inner volume and the door opens and then leaves the inner volume (so the door closes) but stays within the outer trigger volume and then reenters the inner volume, the doo opens in the wrong directionâŚ
Is there a way to make this work better?
A side question:
I figured that with blueprints (as opposed to some UDK stuff), the execution is linear (meaning no parallel signal paths).
If I place two volumes exactly over each other and give both overlap events, is there a rule to determine whichone is handled first?
When you enter Trigger A, Approach is set to false. Then, when you enter Opener, it triggers the false part of the branch and adds -90 yaw to your door.
When you leave Opener, Approach is still false, so -90 yaw is applied again, for a total of -180.
Reentering Opener, Approach is still false so another -90 for -270 yaw.
Iâm not completely sure on this, because it seems like the -180 would have your door going through the frame instead of back to itâs original location, but I probably just donât understand rotation enough.
I think you can fix this by added an execute to both Add Local Rotation nodes which sets Approach to the opposite boolean value. That way you should always have the correct value when you leave Opener and youâll be able to approach the door from either direction still.
