I’ve run into a weird widget problem. Whenever one of four arrow buttons is clicked and this robot character I have moves from room to room, the arrow buttons are supposed to be collapsed until the animation is done. But, for some reason, the arrows appear too soon and are clickable when they aren’t supposed to be, even when I’ve set all four arrow buttons to be collapsed before the animation starts and become visible after the animation finishes and the delay is executed. Could this be a bug?
Here is the widget with four directional buttons. Next are the two links that show the behaviors of the left and right arrow buttons; all of these buttons operate on an counter-based integer that tells the program what room the robot navigating its way through the maze is in.
Not sure this is THE problem; however, your event will occur whenever it is triggered regardless if the prior event has completed execution given the “long” delays, or not. What might be happening is the previous event, or multiple previous events, might still be running trying to do its thing while the current event may be running trying to do its thing… …possibly resulting in a clustered mess.
On events similar to yours that I programmed into that I could not rework, I added a unique boolean flag to this process called something like “MyProcessIsRunning” which is checked at the beginning of the event for false, set true once started and set false when completed.
So basically, I should put in a Boolean that turns this and that off? Do you think I should make one for each of two widgets? One widget controls movement in the first half of a maze in part of a level, and the other widget controls the second half; that other widget is what I’m having trouble with.
I would say if the event is “long” in execution and that the goal of that event is to complete its execution prior to the next event, you may need some flags to prevent future event triggers from interrupting the current event being executed.
This might be the source of your issue (or) it might reveal the next Scooby clue.
This is part of a tech demo and in the final stretch of the fifth level, so it is part of a larger set of BPs, widgets and the like. Anyway, what would you suggest I make Booleans for? Or would it be a good idea if I, for example, had the arrows remove all widgets then refresh the current widget and set the Level Counter to its proper number?
So In my MainMenu I search for game sessions. There is a Join button. I want to prevent multiple events of “On Clicked (JoinButton)” until the current join process has completed. Thus, I created a boolean called “JoinPressed”. My BP code looks as follows:
This could be bad; however, I used the “Event Tick” to check to see if “JoinPressed” is true. If so, I wait at least 2 seconds (JoinPressedLimit) of which after that point I clear JoinPressed and allow for the Join button to cause the event’s functionality to trigger again.
Not super proud of this; however, I am proposing that given your code to add the equivalent “JoinPressed = false” at the end of your event’s execute paths (not recommending that you use Event Tick to clear your “I am processing” flag).
So, the Event Tick is to maintain the Boolean’s true state? And, each time an arrow button is clicked, that Event Tick would be used to make sure that the buttons are only visible while the Boolean is true?
Yeah the example is multiplayer but the point is that a boolean can be used to prevent additional events from happen while the current event is resolving.
The microprossor equivalent I am thinking of is that events are like interrupts in that there is an interrupt service routine which is the code after the red event block. If your interrupt service routine is too long, you have to disable future interrupts until that service routine is finished. Same is true in UE.
Add print statements right after the red event block and at the end of each possible execution path. I claim the desired result should be a begin print statement followed by an end print statement.
I claim your code might have multiple begin statements before a end statement is printed. If this is indeed happening, you need to stop, or prevent, this from occurring.
And the Event Tick goes in the widget’s BP, right? The two widgets are separate, but it would still make sense to put this tick in each, just to force each one to refresh itself.
My other example with “Event Tick” is overly complicated in that I did this because my “On Clicked(JoinButton)” event finishes fast; however, it calls the event “Join Session” which finishes slow and I am waiting the 2 secs incase the “Join Session” event fails for whatever reason. Actually, I also did this code because was really trying to prevent accidental double or triple clicks on the “Join Session” widget button. Essentially debouncing my “Join Session” button at a 2 second interval.
Er, wait. That stuff that I replace the function and delay with is the set of if-then-else branches with the level counters? And does this go in the widget’s BP? Or the level’s BP?
Your code/stuff/functionality replaces the made up function and the delay in the commented section. Do note that if you have multiple exit points in that event you will need a “WaitUntilDone = false” for each of those exit points…
