![Screenshot 2025-08-18 043750|690x239]
I am using this blueprint to look grab and move any movable object after pressing “E” while aiming at it, I want a “E” prompt to pop up when I am in the range and view to pick it up.
Welcome!
There’s quite few different ways to approach this depending on what your goal is. I will demonstrate the blueprint widget method.
So you’ll need to create a widget to be your prompt to begin with.
(this is just a simple widget with an image, nothing fancy)
Add a widget component to your player blueprint and set the widget to be the prompt you just created and set its visibility to off.
Now in this example we are going to simply run this on a timer with a trace so that we can constantly check in front of us for objects that can be picked up.
(The time does not have to be that frequent but if the objects are moving around a lot you will see the prompt jumping to “stick” to the actor)
Then when playing the game we will trace from the camera and when it hits an object type that can be picked up it will turn on the prompt and set it’s position to be aligned to that hit actor.
It’s worth noting this is very much a prototype example, and if you are going into building a proper HUD then that might supersede this, but as an example this will give you the behaviour you’re after.
1 Like
(post deleted by author)
Apparently the button stays visible even after I have picked the object up, is there any solution for it or did I just follow your tutorial wrong?
Hi @JisanDavis as mentioned above are many methods and many approaches to what you do and the logic is quite correct and simple , however during interaction there are more aspects as hinted with proper hud and logic.
If you want object not to display prompt after its picked up, one of the ways is the query objects.
When you pick up objects you can simply have tag on them or as in your logic you have a bool IsGrabbingObject? you can use that to effect visibility of prompt
return value AND IsGrabbingObject?(not)
Also would like to mention , you have to tell scripts what to do every use case. Interactions would have many use cases so it can get complex however thinking them before hand would take you to the point you want to go. Since we would like to give you the right direction and information you can think about.
- Am I already grabbing an object? What are the gameplay elements that can block my interaction?
- Are all physics objects interactable? or some of them interactable?
- Are all interactables in your game is physics objects or can be something else?
- Can an object grabbed behind a wall?
- Does every object has same prompt? or some have different wordings?
- If 2 grabbable objects are near each other or overlapping , how can we select the lower one or increase accuracy?
- Can I grab 2 objects at the same time?
- Can I grab objects behind a glass window?
- When I grab an object can other players grab it too from my hand?
- many many use cases especially with physics interaction
So thinking about use cases first can help you, not everything plannable ofcourse however if you are looking for a robust interaction system : I would suggest two actor components, one for the interacted and one for the interactor (instigator) who they do their own checks, calculations for the interactions. Brings up their own widgets and have own conditions.
However there can be different approaches still extendable that you can follow after you think about your use cases and design thinking about your games need, a nice starting point can be this one
1 Like
In my example if you fail to hit on the trace it will turn the prompt visibility off.
1 Like
With the previous coding blueprints and the mechanics, can you add a compatible system where if I go near the radius of the movable object, it will show a different prompt while the E prompt is not triggered, but if the E prompt gets triggered then the prompt will disappear?
Well, yes I can. However you have to figure out how to do it yourself.
Approach 1 (Easy shortcut way) : You can have on overlap→show interaction prompt on other interactables. At that moment you can add player a tag, something like “IsAlreadyInteracting” so you can prevent other interactions close(false) at that moment. Both have their own ui so it is not mixed.
Approach 2 (Proper Way) :
Have 2 actor components. BlueprintClass - >Actor Component
InteractionComponent : Holds data for the interaction like name, status etc.
InteractionScannerComponent : Scans every actor in a radius that has InteractionComponent. With the rules you define on it, it picks the most relevant one and displays to you.
Interaction UI : Simply can be always ready but invisible in HUD. When InteractionScannerComponent founds and validates an interaction, it can tell UI or UI can simply listen if there is a validation event in scanner. I prefer to spawn multiple.
The Rules: You can write some functions in blueprint in the scanner component. Like
- CanInteract→Checks some variables (a bool maybe) or tags if interaction enabled.
- IsInViewCone→ Checks if current interaction cone angle matches player look angle. Can be narrow or big
- More rules you can write if you need or prefer like.
If you do this way you system would be more extendable and proper. You can build more on it in time.
On your current system simply you can scan actors that implements **InteractionComponent. If(True)**→Access Variable (PromptName : Door, PromptAction: Open, PrompStatus: Locked ) . Simply going with this architecture would unlock you to do many things without another interactions system required. You can even define things like Interaction distance to it like 10m and add a rule function for it. If distance less than 10m, it is false. When you press E it tells interactions component to fire event and you can do whatever it needs to do (physics pick, open door)
These are just mindset to put you in the correct direction to achieve whatever you need. You current InteractionScannerComponent is basically your camera, if you would need proximity, relevancy based interaction simply you need to change it to a scanner (collision) + Trace.
something like this, basically mix of multiple rules distance, viewcone, key, status
1 Like
Can you demonstrate the approach 2, with screenshots?
Sure in simple terms here it is.
1 - Create 2 Actor Components and name them InteractionComponent and InteractionsScannerComponent
2- Create one widget as InteractionPrompt_WBP and one actor TestInteractionActor_BP so we can run some tests on it. You can fundamentally use any of your actors for testing too.
Before we move on lets recap what we are trying to do. Scanner detects and rules what to display, InteractionComponent tells scanner it’s data, widget listens and shows up if there is something valid. On interact scanner tells widget component to trigger so something happends.
3- InteractionComponent : Simply it has nothing (for now) but two string variables and one Event as OnInteracted.
4- TestInteractionActor_BP : I added simply an interaction component to it add define its variables on left (door , open). Clicked component and add its OnInteracted event to graphs simply by its + icon and made a print string and material change on the mesh..just for testing and understanding the feedback of interaction.
5- InteractionsScannerComponent which fundamentally is a controller/director. I kept logic as simple as possible to explain fundamentals in an open way.
We will assign this component in next step to player so it can do its job.
OnBegin play, I get owner (Player Character) cast to it and get a hard reference.
CreateScanner→ Create a sphere collision component on owning player character, set a size (radius) and save it.
CheckInteractables→ Simply binds to overlap events of the collision. If something enters added to array and if something exits is removed from array. Simply I can check CurrentInteractions around to do stuff. Then we go to UpdateInteractionStatus
UpdateInteractionStatus→ This is where we can define some rules and many more rules as you see fit. To keep it simple I just checked 2 things. Is there interactions around? Is any interaction around is on my camera view?
For each interaction around me I check with a function RuleCheckAngle (below screen shot) to determine if this is something fitting the rule I desire. If it fits I break the loop already, hold variable and call InteractionReadyEvent –>which has a bool and interaction component as variable that we will use in widget.
If there is no interactions call it with false and i set CurrentPrioritizedInteraction to empty null.
Also there is another event TryInteract_Event in graph.. create that event too simply we will use it to pass input (interaction request) to the component.
It simply check if we already have a prioritized interaction valid and calls event on Interacted in the component that we created at step 3.
6 - InteractionPrompt_WBP (The widget)→ 2 labels for action and title. Put an input key. Placed in Canvas and wrapped these elements with a container InteractionPromptContainer basically a verital box. Tried to put origin of it to top left middle.
In its logic as you will realise it is a listener. First it makes itself visibility collapsed.
OnConstruction→GoesOwner→TryFind the InteractionScannerComponent→If Valid binds to its OnInteractionReady event.
OnInteractionReadyEvent→True→SetsNewData make it visible ….. on false makes it collapsed.
There is a tick function basically bind to visibility of this widget.. If widget visible updates widget screen position to match interaction owner actor position by using ProjectWorldToWidget. So it appears on the actor nicely.
7- Binding All together/ PlayerCharacter → I go to my playercharacter and added scanner component to it.
OnBeginPlay first created my prompt widget and added to viewport
I created a new input action as E IA_Interact→Get InteractionsScannerComponent and call its TryInteract Event which we created at the end of stage 5
8-Tesing → Put my test actor to level, duplicate it like 3 and changed its variables of InteractionLabel , InteractionActionName so all have different data.
Results
These are overall the approach to the subject and let’s keep in mind it is for demonstration purposes, there are some things that can need to be improved especially on the rule/priority side depending on the game and gameplay aspects. An additional trace can be made single to check if the interaction is blocked or not, tags can be integrated even with GAS to control it nicely etc. However its quite extendable many terms you can add states as Locked,Active,Inactive, Depletec to InteractionsComponent to control further gameplay aspects.
You can simply change state of the interactionComponent and add rule to check if state is Active. So if you want during gameplay→You interact with something → it becomes depleted→ you cannot interact again (prompt doesn’t show)
or you can just delete interactioncomponent from actor OnInteracted so its not scanned so there is no prompt to show.
You can add a rule again in same place as RuleCheckPlayerStatus→ and you can query if player holding something. If holding something there is no interaction can be promoted.
I strongly advice doing these with gameplay tags if you are planning a sophisticated interaction hierarchy between objects. If a tag exists on player some things can be blocked or maybe not.
Adding a video below since screenshot quality on forums not the best, think video can improve readability a bit.
Let me know if it helps or have further questions around it.
1 Like
I followed the first 4 steps but from the 5th step it’s not fitting properly cause I’m using a fake first person view without character mesh, just collision
Not sure what fake first person view means but it can simply work with any viewmodel. This is just about proximity and camera look angle.
The Post images simply uses same architecture but ofcourse much more indepth systems design.
Whichever fits to your needs you can go with that, its just about what your game needs and the user experience that you want to nail down. There is no truly right or wrong between the systems unless you have further needs and previous system cannot respond to it.
1 Like
I guess I figured out that BP First Person Character thing but now…
I cant understand why I can’t add the node “add sphere collision” in the 5th step the way you did
I have many problems now so putting them in numbers.
- what error is it showing
- and the widget that I was editing stopped showing in the edit mode after I started working on it’s blueprint
- and I could not find the pink set node for text that you used here in InteractionPrompt_WBP:
so I used that indirectly somehow:
is it ok?
- and also I think the engine is telling me the value for CurrentInteraction variable is null or something like that
did I miss anything here? and did I put the variable types correctly?
- and I did not have the exact materials for the ‘select’ node that you were using in TestInteractionActor_BP:
so I used these Instead:
will it work or I gotta change?
I’m not allowed to upload video so can’t show the recording
- For error think you are missing this one
Since it is not hidden in the beginning , on tick it tries to find interaction and it can not
-
Think widget is not showing in editor is also related to this.
-
If text is changing in the widget its ok.
-
Yes should be related to one, since you start game and ui starts to give error since there is no “current interaction yet”, also make sure your character is not null after cast. you can simply debug it by printing something or watching blueprint nodes.
-
You can use whatever material you like, materials has nothing to do with logic but just a visual feedback. So it works with any material
Try to go over your InteractionPromp_WBP and validate that everything is as it should be like in the images. After you sure that your ui logic is correct, if you still getting null error when you get close and interaction promp not appearing properly etc check you interactionScanner component logic.
1 Like
The easiest approach I’ve found is to add a Widget Component (Prompt) to the actors I interact with. Then use a Widget Interaction Component in the character class to trigger the prompt.
The old way I did things was to have a capsule collision that protruded from the first person camera. It triggered Begin/End overlaps on the actors themselves. As long as I was close enough and focused on the actor it would display the prompt.
1 Like
Great so seems you have problem over here
seems it is returning null. Make sure you are passing correct reference to component here
When this event is called (True) your UI turns visible and tries to find owner of this in level (location) to display promp. If can’t find it, it gives error.
When status is (false) UI is coillapsed-invisible and does nothing.
Try to make sure the interaction variable not empty.
