Can't open door with key after opening widget blueprint

So, i’ve created a blueprint of a key, that is assigned to open a particular door. Then i’ve created a widget blueprint that will show after interacted with the key. But this widget code is invalidating the information to open the door after key is collected (i don’t have an inventory yet), how can i solve this issue? I tried many ways, putting the pick up key node before, after and along (sequence node) with the widget coding, but both never work. Some prints to contextualize:

The key bp:

And the door bp:

It’s not clear to me what the issue is per say based off of your description. That said, I do find it odd that you are calling “DestroyActor” on the key BP. What’s the intention there? If you remove that node, do you get the behavior you’re looking for?

I agree with ghost probably because your calling destroy actor so there is then no actor to pull data from, personally id implement a data table, and row handles on your key/door classes to pair them up, that way you can access data with or without any actors.

I get it, but when i leave connected only the nodes from pick up key and destroy, it works perfectly opening the door. Also i’ve tried leaving as the print shows, but disconnecting the destroy actor node, but still doesn’t open the door, so the problem is the widget, i guess.

Thats cool, perhaps you have some video to share? i’m kinda new in UE.

The issue certainly isn’t the widget itself…assuming there’s not funny business in the widget BP. I think you have a misunderstanding of the control flow you have implemented. Let’s walk through the flow…

  1. The user interacts with key BP
  2. key BP let’s the corresponding door know that the key has been acquired and then promptly sets itself to be destroyed
  3. Path A of the FlipFlop node executes, creates the widget, adds it to the viewport and sets the input mode to Game and UI (this assumes the key BP is not already destroyed, or in a “waiting to be destroyed” state…again, calling DestroyActor here feels off)

It’s important to point out that path B of the FlipFlop node never gets to execute. In order for that to happen you would have to call the Interactable event on the key BP again…which you can’t because it’s been destroyed. This means that RemoveAllWidgets never executes and setting the input mode back to GameOnly never executes. You can put prints in to verify this.

I believe this is the real source of your problem based off of the information we have available. It makes complete sense that if you remove the execution of the FlipFlop path that things will work. Right now you’re only actually executing path A of the node as is, leaving the input mode in a potentially undesirable state.

As @doctorpepperdan pointed out, there are certainly more elegant ways to do this. That said, you can still make this work potentially with a re-ordering of operations. The widget that you’re displaying, does this require user interaction or is it simply a message like “Key acquired”? If it’s simply a message then you could potentially add a delay node after adding to viewport…then after the delay node, remove from viewport…no need to change the input mode. THEN call DestroyActor. That of course assumes the widget doesn’t require user interaction. Again, not the most elegant solution but it could work.

Checkout Alamars dev domain and Ryan Laley on YouTube, both have great content Alamars is more c++ based Ryan is more BP based

1 Like