I am trying to do Walk / Jog / Sprint and that much is fine however i want to prevent backwards sprinting when the player is running backwards. If the player presses the sprint action key and runs forward but then presses backwards having never let go of sprint then they are sprinting backwards (not what i want!)
To overcome this i thought of adding a while loop that will check if they are moving backward or forward however i get the “Infinate loop detected”
While my code may not be the ideal way this is done its all part of my learning the engine and if you have a better way i would love to hear it, however i would still hope somone can explain to me why this is an infinate loop when i have tested the DOT value and it is indeed changing between 1 and -1
I also tried it this way so that the loop was not dependant on the DOT and still it detects infinate loop and i have no idea why
Correct me if i am wrong but the only infinate thing about this is if the player keeps his finger down!!
While loops are very rare in Blueprint since they are normally only used in calculations and calculations are often done in C++ instead.
Tick never triggers in a while loop so any value that gets updated on tick can’t be used for the condition in a while loop which is pretty much everything.
I would build the sprint into your Axis input. Set the Sprinting bool with the sprint key but gate movement with a branch, Is Sprinting AND Forward Axis >0. That way if the axis became negative it would stop the modifier.
The biggest thing I have learned about Loops is that they trigger a new loop every tick when an input is held. A change in input doesnt effect any loops already firing
lol this is one of reasons why I love state machines for gameplay logic.
I don’t even have to think about this kind of problem anymore…
I was working on a controller that is very similar to movement modes from Metal Gear series (run, sneak, crouching, wall cover, etc)
Before using FSMs for input/action graphs the problems were driving me mad and tired.
The only drawback is I often have duplicated graphs with tiny changes for each state and I end up using the “Switch on xxx” nodes a lot inside of animation blueprint when deciding behavior based on current state of the gameplay state machines.
Thank you **CaveMonkey72 **that makes it much more staright forward “pardon the punn”
**BrUnO XaVIeR **yea i have just binge watched a series on state machines / root motion and will be starting again from scratch on this. Still, im learning so i dont mind. I am glad i was able to work out at least a reasonable way to do it but its time to do it the right way!
Man ive seen some crazy complex looking ones but the results are so smooth!