I have a line trace firing from the camera 1st person style. The line trace checks if actors struck are valid interaction target actors, and in addition, if it is currently a valid interact actor target. If the target is both interact valid AND is CURRENTLY interact valid, the idea is to draw a little “interact” text widget for the player, and of course if clicked, fire an interact event based on whatever the interact actor is (light toggle on/off, etc.). I’m sure this all sounds very bog standard to experienced UE4 users!
However, there are times when I want an actor that is usually valid to return currently invalid, such as a long door opening animation. In these cases, the InteractActorStatus interface function I set up for this job only seems to be working when I mouse away from the door actor, and back again. If I leave the mouse cursor over the door, my current “interact line trace” logic fails to catch this and turn off the ability of the player to interact, which is to say I can continually spam the interact button, which I don’t want
I haven’t looked too closely, but there is room for some logic error there.
Can I recommend a couple of options that would simplfy things greatly:
Rather than looking at ‘implements interface’, you can use the ‘hit component’ pin of the trace. Inside the BP, only the components you want the user to use can have a tag like ‘clickable’. You can check in your trace logic if a component is clickable and change the cursor. In the BP, you can clear the tags and reset them depending on when you want the component to be clickable. This also means you can limit the cursor change to just the doorknob and not the whole door etc.
It is also possible to turn the ‘implements interface’ on and off from BP. That might be another route.
It’s just that then you can drop the whole figuring out which actor has been hit variable from the logic.
Thanks for your reply. Since the game is first person, There is no cursor to change, and I wasn’t being clear about that in my initial question. What I meant by “cursor” was the center of the screen where the line trace is located.
This logic is firing off EventTick (which i cropped), and whenever the center of the screen, where the line trace is located, is pointed at a valid “interact” object (defined as an object using the interact interface i set up) AND in range, it returns a little “interact” text widget near the center of the screen.
when the player is no longer looking at the object, the logic returns false. And that’s working good. But additionally, i wanted to disable this logic immediately after interacting with a slow animation (in my case a door that takes several seconds to open). While the door opens, I have a boolean called CanCurrentlyInteract setting the “interact” to false on the door. My problem is then: if I look away and look back, the logic behaves as i expected, that is, a normally interactable door does not interact until the animation is finished. BUT, and here is the problem with the logic as i wrote it, if i don’t look away and keep the center trained on the slow door animation after i press my interact button, I can continue to interact with the door with my interact button, effectively spamming it and triggering the open/close flip flop before the CanCurrentlyInteract boolean is set back to true.
You can choose whether to write your movement logic to allow the player to ‘spam’ ( sometimes that looks good ), or not.
Assuming you have a timeline moving the door, just put a ‘doonce’ on the interaction event, which you have clear from the Completed node of the timeline.
I think you could also do it your way, but you have to put the code in somewhere.
Thanks again for your swift reply. Yes, DoOnce definitely works! If I place it in my door blueprint, and reset it once the animation completes, then the door is unspammable.
But it doesn’t solve the issue of the interact widget, and according to my blueprint script, the actor being line-traced is still interactable when I view it in the simulation. So I’m stuck with the feeling that DoOnce is a workaround.
I believe the solution has something to do with how the InteractActor variable on the player pawn is being cleared on an valid hit actor. Once that check passes, any further variables down the chain on the actor being interacted with, are not propagating back up the chain (nor should they, i think it should be caught before getting that far)… And I’m not good enough to figure out where this logic went bad.
I think you have a bit of weirdness going on with the InteractActor setting and checking. Why not just set it straight out of the gate from the trace? ( because it’s by definition the actor you’re interacting with ). The sequence node could also quite easily be running stream 1 before stream 0 ( as they do ).
That’s a great suggestion! I have tried something simpler before, but any time i slice out any portion that compares the hit actor to the interact actor… actors that were valid but are now invalid (such as a pickup item like ammo/health where i destroy the actor), return as “pending kill” errors, which as i understand it are crash-to-desktop errors in a compiled game. BUT, I will give it another look. There’s definitely an error in there, and i agree with your assessment that there is some bloat to this script…It’s the result of additional functionality creep added to the line trace over time.
I tried your set up and it seems that when I just set the line trace hit actor as the InteractActor straight out, it’s behaving how I want. Thanks! It appears I was wildly over complicating this.
