I have a small tree that waits for some user input before triggering a switch statement that diverts the flow depending on input. My intention is to reset the branch when a specific event or variable changes so that the flow can be re-run as a clean slate.
I have tried to fix my issue in several ways with no success, but my current implementation consists of some events and blackboard variables that I use to control the flow to wait for some user interactions.
The branches that run in a, sort of timeline format, trigger some logic in parallel runs with some [Wait] nodes and after all of these action nodes, there is a [Wait for all] node that then, triggers some other nodes with similar logic and arrangements. At the very end, I have an event that triggers the user interaction flow again.
The user interacts again with some UI and after this happens, the leaf sends an event that (supposedly) restarts my logic branch and restarts the whole flow again.
The main issue is that, after one loop, the debugger shows all the flow nodes as success (the checkmark icon) and nothing gets awaited. It all runs at the same time and some nodes even get run and started more than once.
Is this a bug or am I doing something incredibly wrong.
PD: I have tried the reset node with some conditionals without success. I am making sure that all the child nodes are finished before re-triggering them and there is no repeat nodes.
Yes, I’m including some screenshots of the behavior graph. I will also include some with it running in debug to showcase the issue. I’ll open a Ticket shortly and post as well.
The Screenshot showcases a version of this that is a bit disorganized because of the testing that I have been doing. In reality, all these modes are running in separate behavior subgraphs, but for testing I copied one of the subgraphs directly to the master graph to see it in action, with the debugger.
Hi @AlejandroGamezS , thank you so much for the reply and the screenshots! I believe this is the same issue we’re already looking into so hopefully we can get you a fix soon. Unfortunately it probably won’t be available for tomorrow’s release as we will need to test it thoroughly
I’m sorry for the inconvenience with that and will communicate as soon as we have something for you.
We actually think the fix is quite simple, in ParallelWaitComposite.cs, the OnEnd for WaitForAllComposite instead of decrementing m_StartCount, set it to 0 by default.