x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Enable player input when looking at object

I'm trying to get a player input to work only when player is looking at it. Specifically, allowing the player to open a door only when he is inside the hitbox, and looking at the door.

Here's the blueprint for the door: https://blueprintue.com/blueprint/06smlcfa/

I've looked at tutorials about these line trace nodes, but I cannot for the life of me get them to work. So here, the whole lookAt part of the blueprint is not working. What exactly is wrong here?

Product Version: UE 4.16
Tags:
more ▼

asked Oct 22 '18 at 04:53 PM in Blueprint Scripting

avatar image

BTDarmstad
5 1 3

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

3 answers: sort voted first

The first thing I would try is printing out what you are hitting when a hit result happens, if you are hitting anything at all. Because it sounds like your trace channel isn't setup correctly therefore the raytrace is never colliding with the door.

EDIT: Updated info.

So they way I believe you want this to be set up is if the player is standing next to the door AND looking at it, they can open it.

Here is how I set that up:


alt text In this first image is the setup of my door actor with it's collision and overlap boxes. I am using the DoorCollision component to block the user from walking through the mesh of the door, and it is set to BlockAllDynamic in its Collision settings. The DoorOpenArea is the bigger box surrounding the door that is the area the player can be standing in while opening the door. That is set to OverlapAllDynamic


alt text In my event graph for the door actor, I am doing my overlap checks to see if the player has entered the DoorOpenArea (You can get these events to show up by clicking on the component in the Variables section and under Details on the right, selecting the event you want). This just tells the player what door they are trying to open.


alt text This is my raytrace happening on the character. The beginning is the same as yours, except I am checking if the DoorToActivate variable is set or not before running the raytrace (not important, just some performance enhancement to only raytrace when we need to). First I'm checking if we hit anything, and if we did I'm seeing if it was a door actor by casting to it. (I'm doing this because I'm going to need to reference the actor we hit as a DoorActor anyways so may as well kill 2 birds with one stone). Then I check if the door we are looking at is the same as the door we are standing next to. If all of that is true, I'm setting a boolean to allow our character to open a door.


alt text This is my input for the character. And where to actual door opening happens. I'm just checking if we have a valid DoorToActivate and if we can open the door and then setting the rotation of the DoorMesh component from our door actor. (Remember the DoorMesh component contains the DoorCollision collision box too, so that allows us to walk through the door when we open it.

door-tut-1.png (607.1 kB)
door-tut-2.png (320.5 kB)
door-tut-4.png (335.2 kB)
door-tut-3.png (307.6 kB)
more ▼

answered Oct 23 '18 at 03:54 AM

avatar image

TestyRabbit
351 7 6 13

avatar image BTDarmstad Oct 26 '18 at 08:04 PM

That seems to be working pretty well! Thanks!

If it's not too much to ask, I just have one additional problem with this setup - I have set up a timeline so that the door will slide open. With this setup, the flipFlop node will disregard which door I am trying to open/close. So when I try to open a door number 2 after opening a door number 1, door number 2 will play the closing animation (snap open and then play the closing animation)

Is there a way to fix this?

https://blueprintue.com/blueprint/l1iy_v_3/

https://blueprintue.com/blueprint/koghutkf/

avatar image TestyRabbit Oct 26 '18 at 08:28 PM

So the way I would solve this is by creating a state variable on the door. Maybe a boolean value called isOpen and then instead of using flip flop, I would check if isOpen is true, and if it is I would play the close animation, otherwise play the open animation. Just make sure you set that variable to be true or false whenever you interact with the door

avatar image BTDarmstad Oct 27 '18 at 07:08 PM

After some tinkering with this idea, I believe I've got it working the way I want. Thank you again!

So I did the boolean thing you suggested, and I moved the timeline node back to the door actor because there was some weirdness with it snapping and cancelling out when I tried interacting with multiple doors. Having it in the door actor instead seems to have solved it. And then I added two custom events for opening and closing.

I'm not sure if I'm using the casting nodes entirely correctly or efficiently, but that's a lesson for another time, I guess. The doors are working, and the problem has been solved.

Here is the final setup:

https://blueprintue.com/blueprint/g72e1wjy/

https://blueprintue.com/blueprint/y5c4nzjv/

avatar image TestyRabbit Oct 30 '18 at 03:40 AM

Awesome! I'm glad to hear it's working! Can you mark this as resolved so others in a similar position will know there is a fix here?

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

I tried setting up a branch and print strings, and sure enough, the trace doesn't work. If I try trace channel visibility, the trace turns green when it passes through anything, and with camera it doesn't turn green for anything.

I don't get it. In my mind, it should be dead simple - if line is hitting this component, set boolean value that enables player input, but it doesn't work like that. I tried with a different blueprint actor with containing just a cube as well, same result.

more ▼

answered Oct 23 '18 at 12:00 PM

avatar image

BTDarmstad
5 1 3

avatar image TestyRabbit Oct 23 '18 at 04:24 PM

1) When you are printing out what you're hitting, what is it telling you when you try to collide with the door? 2) If it is not telling you you're hitting your door, something is up with the collisions. 3) What does your "Door" actor look like? Or the actor containing the door?

avatar image TestyRabbit Oct 23 '18 at 04:58 PM

I have edited my answer above with how I accomplished this

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Your LineTraceByChannel is stopping on the first actor hit, regardless of whether it an actor you care about.

You can use MultiLineTraceByChannel, use for a foreach loop on the hit result, break it, and check if any of the the hit actors are your door. If any hit result is your door, then you can set the "lookAt" to true, if not, do nothing.

To achieve the changing of lookAt to false, I would simply set it to false before performing this loop, and then it will only be changed back to true if your door actor was hit.

Hope this helps!

more ▼

answered Oct 23 '18 at 02:56 PM

avatar image

Unfathomable
451 2 5 7

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question