Hey everyone. Fumbling through an interactive system and having an issue with when the call is available to be made.
I have a UI that is drawn when the player character overlaps with the door.
In the UI I have an event from a keypress that triggers a function from a BPI. This BPI function is an event in the door actor which causes it to open and close.
I had thought that destroying the UI once the overlap ends would prevent the key press even to continue to be available, however after the UI is removed from parent, I can still open/close the door from anywhere in the level.
‘new function’ event is triggered from the player character when it overlaps with the door.
Question: Why is the UI still listening for a key press and triggering the BPI? Is there another way that I should be destroying this UI and its functions?
From my view, I can see the problem lies with your first screenshot. You see, whenever you press the “E” key, it will always succeed as the actor exists in the world regardless of your player’s location. Again, it will simply work everywhere. This is what we call “Logical error”.
A better approach is to cast a trace in front of the character and observe if it hits any respective actors. If it hits, then from the return value of the hit actor, you may then execute/call your interface message function.
This doesn’t explain why the ui widget is still receiving inputs even though it was ‘removed’.
I’m not confused by why it’s affecting the door from any location. once creted it acts as if the ui widget is never destroyed… So that was my concern. Do these widgets never get destroyed?
I made a system that uses a component that gets destroyed instead and it works perfect.
Because it never will. Your widget never gets ‘removed’.
Good for you. But can you do the same with this? If not, then it means your chosen method is not scalable. If yes, then good, apply the same thing to this problem.
In any programming, we have to consider two things. One is the code must work and the output is as expected. Two is the code must be scalable, meaning it can be easily tweaked, modify, remove, inherited and copied.
I gave you an approach/idea that may fulfil these requirements and I don’t mind sharing this more but if you still think that this method is bad, then I’m afraid you will have to figure this one yourself.
Thanks for the concern. Of course scalability etc are things that need to be considered and I will be testing out different methods including yours. However I am still a curious person and would like to understand widgets more. The scope of this question is widgets.
Per the guides, to remove a widget you simply ‘remove from parent’. Which I do.
I couldn’t find any specific destruction methods unlike with actors.
Are there no destruction methods? If that’s the case, that means that I need to think about how many widgets total get loaded into the level, as there would be no way to remove.
When you “Remove” a widget it will however get garbage collected similarly to Destroyed Actors but Only if nothing else is referencing the Widget anymore.
The following nodes will trigger the corresponding Events within the Widget Create a Widget triggers Event On Initialized Add to Viewport triggers Event Construct Remove from Parent triggers Event Destruct
“Event On Initialized” is only called once but “Event Construct” and “Event Destruct” can be called multiple times on the same Widget object.
This is why things that should only happen once per widget object should be made in “Event On Initialized”
It would be better to use “Listen for Input Actions” rather than using the “Input Event” node which doesn’t work well with Widgets.
“Listen for Input Actions” will Stop listening when the Widget has been Removed from Parent or if you explicitly call “Stop Listening for Input Action”
