Download

Projectile gets stuck in door

Hi,

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.

5a412b50e21166d026c9f62eb066678508618541.jpeg

The graph looks like this:

12dfaa5b3edb312c1de90bccc004f7a2ff94b909.jpeg

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. :frowning:

f3b2573e1fc131dcab5e6ef8abf5a145d6b7a40d.jpeg

Any idea why :confused:

(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?)

Any help is appreciated :slight_smile:

Cheers,
Klaus

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.

Hi,

Thanks for the tip :slight_smile:
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:

Thanks again :smiley:

Cheers,
Klaus

Oh ok. I’m still getting used to what the collision settings mean. Glad it worked out for you though!

Me too :smiley:

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?

Cheers,
Klaus

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.