I have a door blueprint listening for an “interact” interface. The door takes a few seconds to open and during this time I didn’t want the interact interface to be valid (so as to avoid spamming the interact while the door is opening/closing). Is there a node that lets me disable an interface and then re-enable it?
Interfaces are not listening (subscription) messaging system, the icons on node might be misleading, interfaces only relates unrelated classes with a common functionality (like in your case interaction) the whole thing is tied to class relation system and you just perform normal function calls just via interface type instead of class one. You simply need to ignore those calls or stop calling it when object is temperately non interactive by checking status of actor or disable component that makes it interactive (if you use such setup) during animation… or all of them in same time to prevent any potential glitches.
Only event system which you can stop listening to calls are delegates (they are called event dispatchers in blueprint), but i dont think it is good solution for something like interaction, as you would need to bind actors together first on function that does need content binding.
Just add a Branch on the handler for the interaction, have it check a boolean you set when the door begins moving, and that you clear the the door stops.
Like @anonymous_user_f5a50610 said, Interfaces are not Events and things don’t listen for them, They’re just a collection of functions that can be added onto an actor regardless of its Class, as long as its Class is set to implement that Interface.
So that’s why I suggest the branch/boolean check whenever it receives an interact function call (or the caller can check the target, thought that would imply the caller has to know something about the target, i.e. that it has a boolean to check on in the first place, so that’s more prone to human error).
Thanks guys for your answers.
Mightyenigma, when you say “handler” for the interaction, what do you mean? I had a boolean for “door opening” that flagged true when the door started moving, and flagged false when the door finished. however, this didn’t disable the ability of the player to interact with the door, it just stopped the animation being disrupted. If it’s not totally clear I am a beginner, so I’m trying to sniff out exactly which nodes I should be using.
I thought the door opening was the interaction. When you say interaction, do you mean user i terface things like highlighting the door or other way to indicate that it will do something if the player presses the interact button on their controller?
In that case you will need to have the player pawn or controller check the boolean. You can even include a getter function to return the Boolean valie so you don’t have to cast the interactable actor class.
Exactly. I have an interface that I named interact. in the Player Character blueprint, i have a line trace and anything that the line hits that also returns valid for Does Implement Interaction, draws a little “interact” text widget. I then outline what the interact logic is on a per blueprint basis.
I’d like my door to return not valid for Does Implement Interaction or in some other way get the game to understand that the door is not valid as an interact interface while the door is opening. And i can’t figure out which nodes in the blueprint scripting let me turn it off.
So I had my terminology mixed up a bit. Interfaces don’t listen, they simply allow me to tie together unrelated logic with a common functionality. Thanks!
So what node is the one that will “stop calling it”, in regards to temporarily disabling the interface for the door blueprint? I’m not having luck with “Disable”, it wants to operate on a per actor basis?
Oh okay. Since implementing an Interface is not a runtime thing, it’s a compile-time thing, you can’t turn it on/off during the game, it’s set in stone. But you can add a function to the interface, name it something like getCanInteract, which returns a boolean. Then in any Actor which implements the Interactable interface, you also have a boolean you can name something like bCanInteract. Set it to true when the door is created, and whenever it finishes moving.
Then for the getCanInteract on any such Actors, all you have to do in that function is return the value of bCanInteract.
Then in Player Character blueprint, after you check Does Implement Interface, then you call the getCanInteract function to find out whether the boolean has turned on/off. THEN your player character decides whether to display the “interact” label over the object or not.
The basic idea is the Does Implement Interface only tells you whether the object could EVER respond to interaction, and the getCanInteract function will tell you whether it CURRENTLY can interact.
Okay, I definitely understand the concept you’re communicating, thanks for that. Sadly I’m still shaky on function creation I made the new function (not piggybacking off my basic “Interact”) in the Interact interface, the input is a CanCurrentlyInteract boolean, and the output is another boolean…I feel like i’m close to understanding it based on what you’re saying, but all the pin connections are tripping me up.
The CanCurrentlyInteract function does not need an input pin. You can remove that (click the X next to the sorting buttons for CanCurrentlyInteract? boolean to remove). You don’t need an input because the purpose of this function is to find out if the actor can interact. The Actor doesn’t need you to tell it anything when you call the function; it is only telling YOU something (in the output pin).
So when you set up the function implementation in the Actor’s class (not the interface) then the function definition of the interface will be used, which only needs the output pin for the return node.
In your Actor’s implementation of that interface’s function all you must do is return the value of that actor’s CanCurrentlyInteract boolean variable, into the return node.
In this way, your Actor returns the information to whatever called the CanCurrentlyInteract function that the Actor has because of its Interface. The information returned is simply the contents of that Actor’s CanCurrentlyInteract variable, which is true or false.
So now all your Interactable actors not only have an Interact function, but also a function which tells the thing that called the function whether it is able to interact at that moment.
so if your Player Pawn calls CanCurrentlyInteract, then the actor it is called on should Return that boolean variable, which will be true if the actor is not moving, and false if it is moving, because we programmed it to set its variable that way. All the player pawn has to do is check what the CanCurrentlyInteract function returns for the actor you’re aiming at, before deciding whether to interact or not.
Ok, I have one (hopefully final) sticking point:
“In your Actor’s implementation of that interface’s function all you must do is return the value of that actor’s CanCurrentlyInteract boolean variable, into the return node.”
I get the concept: I’m trying to get the door actor to tell the player pawn if the current line trace target is a valid interactable, based on the true/false of a local variable affecting the CanCurrentlyInteract interface. So I figure it needs to fire off Event Tick since this info is needed every frame. But I’m not quite hooking it up correctly. This isn’t doing what I expected.
Let me clarify a little more; The Door should not be calling the CanCurrentlyInteract function. the Player should call it when the player is looking at the door, just as you have it.
Basically by the player calling the door’s CanCurrentlyInteract function, the player is asking the door "hey can you interact now?
So please don’t do this on Tick, and especially not the door’s tick or you will have a lot of doors ticking when they could just be waiting for the player to ask instead.
The CanCurrentlyInteract function on the Door doesnt need to be in your event graph.
Go to your left sidebar. There should be a way there to either add or change the CanCurrentlyInteract function for the door class. Click into that and a new tab will open up where you can set up a graph for the function itself. It will be a simple graph: function entry point and return node with the inputs (none) and outputs (one Boolean) you defined in the interface.
All you have to do is hook the entry node to the return node and feed the Boolean CanCurrentlyInteract variable into the red pin on the return node.
In that way anything can find out the value of any Door’s CanCurrentlyInteract variable without casting.
Sorry i dont have screenshots. I tend to answer these from my phone and i dont have unreal Editor installed on my phone 
thats why I was a little vague about how to implement the CanCurrentlyInteract function on your Door class which implements the interface that defines the function.
I think it is a button or something in the Functions list on the left side of your blueprint editor for the door class.
Its Okay. I think you just misunderstand what an Interface is.
Interface is a set of rules for what additional functions a blueprint class CAN have, and what inputs and outputs those functions MUST have.
It also provides the benefit of the Does Implement Interface node which lets you know whether you can call those functions on that Actor.
So for your Interactable interface, you have a rule that anything with that interface has a function named ActorInteractStatus, and that function must take no inputs and give one boolean output.
Those are the only rules. There is no rule which says how it chooses the boolean value that it will output when you call that function.
So it is up to you to change the graph INSIDE the ActorInteractStatus function inside of your Door blueprint class, so that instead of just returning default false, it will Get the value of the door’s CanCurrentlyInteract variable and return that.
Then when Player class hits it with an interact attempt, the player class gets the Door, calls the Door’s ActorInteractStatus function. Then the Door’ ActorInteractStatus function runs (without being in the Door’s event graph anywhere. It does not need to be connected to any events, not even Beginplay or Tick, because that function runs whenever something calls that function.
So you see nothing on the Door’s event graph about CanCurrentlyInteract boolean var, and nothing about ActorInteractStatus function, because they do not run because of an event firing. The Door has them but they do not need to appear on the event graph for the door.
The only thing about those that needs to appear on any event graph is the Player class should have a call to the Door’s ActorInteractStatus function, on the Player class’s event graph just before it is trying to interact the Door.
When the player calls that function on the Door, then it will execute any blueprint code you put inside of the Door’s ActorInteractStatus function (not the Door’s execution graph)
First let me thank you again for your patience dealing with this beginner/me. Most posts on answerhub do not extend this long before the asker figures it out. I’ve read over your response a few times. I don’t mind no pictures because it forces me to really critically think about this issue and not simply copy what you put up.
So in the interest of perfect clarity for me:
my interface logic = CORRECT/no changes.
my player pawn logic = CORRECT/no changes.
my door logic = INCORRECT, and I need to add a function to the door, in addition to the main event graph logic fixes
I tried to implement what you wrote as I understand it, but my logic results in no ability to interact at all with the door. My “interact” widget does not appear and clicking does nothing. This new function and graph is on the door blueprint only. I renamed my door function to ActorInteractStatus because a function and a boolean with the same name is confusing/bad practice on my part. When I look at the simulation, the player pawn logic always returns false on the CanCurrentlyInteract interface branch.
I think this sentence is where I failed: “All you have to do is hook the entry node to the return node and feed the Boolean CanCurrentlyInteract variable into the red pin on the return node.”
Also, I don’t understand how the door and the player pawn can interact without an interface (or at least a cast). In my original logic, which just checks interact validity only, before I posted to answerhub, the pawn logic knows if the line trace is hitting a valid “interactable” actor by checking for the presence of the “InteractAction” interface via a DoesImplementInterface node.
Wow! OK! That was it. I thought I understood interfaces after you and Shadow’s first explanation, but I didn’t. So basically interfaces are time savers so I don’t have to construct the same custom events over and over across blueprints, but I can ALSO edit them inside the local blueprint, and those local changes don’t propagate back up the chain to the “master” interface function. That was the key I was missing. Once I understood that, it took me 3 seconds. Thanks for the explanation and the patience. I was worried I was just wasting both of our times and thought I’d be stuck on it forever! Thanks again, mightyenigma.
You’re welcome.
Just one more clarification: They’re functions, not events and you’re correct, you can think of them as sort of mini function libraries that only exist on Actors that implement them.
I’m glad you got it working!
Now you have the arduous task of choosing who gets the credit for the Answer, lol.
There will be a checkbox at the top left of each thread on this question that has been marked as an answer. If you click it then that marks that answer as Accepted and gives karma points to whomever posted it. It’s only important to me because sometimes I get to see my name on the News and Community spotlight videos when I earn lots of Karma and that feels good reputation points basically.