I realize this may sound like a strange question, but I’m currently using the FlipFlop node to control object interaction for my game. When the player left clicks on an object, it is picked up using a physics handle. If they left click again, the flipflop node routes to the action “drop” (B).
My problem is that I also have a third option for throwing the object with Right Click. The problem is that if I pick up the object and then throw it, the flipflop isn’t toggled (IE it remains set to B after I Right Click) and I need to left click on the next object twice to get it back to the “pickup” state (A).
I’m wondering if there’s a way to trigger the flipflop after I throw the object or if there’s a way to reset it back to its default state (A)?
So basically the problem is that when you Left Click “Interact” is activated and you are holding an object. Then if you press Right Mouse, it activates “Throw” and you are not holding the object but the Flip Flop still thinks that you need to activate Drop so when you press left mouse again. So when you try to pick up another object, the first Left Click activates “Drop” and then you press it a second time to activate “Interact” again. I’m trying to figure out if you can tell the FlipFlop to switch after “Throw” so that its ready to do “Interact” again after both drop and throw.
Maybe I should use some other method to handle this? I don’t know what that is though.
My solution is to set a boolean variable that can be applied as a condition to a branch just after the flip flop. Specifically: on the B stream: if this condition is TRUE, then route back up to the A stream. If it’s FALSE, then continue on the B stream.
So, for you, the C action (throw) would set the boolean to TRUE. Then when you want to pick up another item (having just thrown one), the B stream (drop item) would check the bool and simply route back up to A (pick up). I guess you’d need to have the A stream reset the bool to FALSE in order for the sequence to resume normal flow. But that’s as far as I’ve got with my logic.
–
But here’s my problem: my flip/flop is in a HUD widget (where the alternate A/B events are triggered). My C action (which puts it out of whack) takes place in my main CameraPawn BP. It’s a left mouse-click.
So I’ve been trying to send an interface message from the C action that sets the bool in the HUD —but the HUD isn’t receiving the message! Grrr. Can’t seem to call a left mouse event in the HUD. Hmpf. Might need to take a break from this—my head’s spinning.
I never did solve this… came up with an alternative work around that wasn’t ideal. However, now that I’m thinking about this again, you could solve this problem easily using Event Tick and a boolean.
With my situation of having “Pickup”, “Drop” or “Throw” what I would do is create a bool called “Thrown?” and link this to Event Tick and then after the object is thrown I would set Thrown to True and on Pickup (flip flop A) set Thrown? to False. Then on Event Tick when Thrown? is True, trigger the flip flop again. This way any time you throw the object it will trigger the flip flop once and essentially reset back to it’s proper state. Haven’t tested this but I think it would work.
Your solution looks like it might fail if you throw the object after the second interaction. First interaction - sets A to False, Second Interaction registers as False and then sets A stream to True but then when you press the Throw object button even if you’re not holding an object it would set to True and then immediately be set back to false when you pick up the object again. You’d need to add a check in front of Throw to see if you’re holding an object and only if you are do you allow the A stream to be set to true.
Now that I think about it though, a better solution might be to not use a flip flop at all. You instead connect a Branch to the Left click and connect a Bool named “Holding Object?” to the branch. If it’s false you would run the “Pickup” event and if it’s true you would run the “Drop” event. Then on the “Throw” and “Drop” events you set “Holding Object?” to false I think this would solve the problem without having to try to figure out the logistics of the various states a Flip Flop node could be in.
