Input stuck at first state - point the error

[ivankio]

Please point the mistake in the attached FSM.

Intended behavior:
To rotate an object using mouse X, Y (while button is pressed) and Scroll Wheel. Then I set new gravity from a child of the rotated object.

The bug:
As soon as I press fire or scroll the mouse, the FSM keeps reading the same first value every cycle and the scene performance starts to suffer although it will not freeze as the "next frame event" prevents the infinite loop.

Obs:
I had succesfully achieved the intended behavior in a 2 states FSM, using mouse down and up events while the actions are very similar. But I'll add more functions to the wake state and I'm following the "Spread the Load" advice of the Playmaker online help.

Additionally, when I add force to a physics system, shouldn't I do that in the "Fixed Update" instead of in every rendered frame? I come from Quest3D and I had a problem with that before.


Edit: video description of the problem:

[jeanfabre]

Hi,

 I would suggest few things to test and debug:

 --I see you are duplicating the scroll behavior, this is in my opinion something you should seperate totally and make it as single fsm.

       So have one fsm that just deals with scrolling.

      to avoid duplicating your "set gravity and wake" state, make it also as another single fsm with a special event, that you can then trigger from other fsm.

-- no need to send a finished event in "just scroll" state. The "finished" event is called automatically as the last action on that state processed its OnEnter function ( correct me if I a wrong here).

    Remove this last action and see if it runs better.

-- Why are you using "next frame event". I don't see the need ( actually never had a situation where I needed this kind of thing actually). I might miss the point here tho.


-- instead of FloatCompare action I would use floatChanged action in "waitInput" state.

-- I would even go further and don't even bother with checking if it changed, and simply have a state running permanently ( rotating by 0 if no scroll). I don't think it makes much difference ( actually, I kind of trust Unity to be efficient and rotating by zero having no effect really on the transform). So instead of checking a float permanently and all the logic of it ( which is prone to more potential bugs and issues), you simply rotate by most of time 0. The less the better I would say.

-- setting the gravity to world.up in setGravity action is really not necessary here. Do this at start yes but not everytime you enter that state, unless I miss something.


Could you explain what you intend to do with this "set gravity and wake" state, I am bit confused as to the result of this state in the world?

 Bye,

 Jean

[ivankio]

Hi. Thanks for your input, Jean. I made a video to, hopefully, better expose the case as I'm not fluent in english:

Good point on the scrolling isolation. I applyed this hint in the sound management. Meanwhile, I did isolate the scroll but I am sticking with only one FSM for those actions to better understand the frame update cycle of Playmaker and to pratice things I'll eventually have to deal - otherwise I foresee I would end up doing one State Machine per action and I would not be taking much advantage of playmaker.

The worldUp was  an unfortunate name to a variable so in the video I explain why I set gravity and wake all rigid bodies everytime I "rotate the world".

As you mentioned, I also thought that the send finished event would be redundant, but as shown, it became necessary. I'm not shure why.

Why are you using "next frame event". I don't see the need ( actually never had a situation where I needed this kind of thing actually). I might miss the point here tho.

I think the key point here is that instead of using this specific state machine to handle long lasting states, I'm trying to do everyframe logic, as stated in the online documentation:

Spread the load:
Remember you can transition through multiple states in a single update, so you can spread logic across states.
Spreading decisions across multiple states, each making a simple decision, makes it easier to author complex branching behaviours.

If I did not hold there, it would be an infinite loop and Unity would freeze.

----

I think I better isolated my misunderstandings. So why:
1 - Input values are getting stuck in the shown situations?
2 - FINISHED events are not happening after the actions on the states finish?
3 - The next frame event "Done" is sent only once?

Bye,

André

[jeanfabre]

Hi,

 I watch your video carefully, thanks for this, it helps understanding exactly what you want to achieve.

 You have interesting issues 

 When I get infinite loop in playmaker, it's always been because I missed something. In your case, I don't see anything wrong tho. Not sure what to say if you want to keep it all in one fsm.

 onto my suggestion to fix this behavior:

 I do think that the key is to have a separate fsm AND logic. One dealing with your input management and another one dealing with "set gravity and wake".
the idea is that your maze should itself automatically adjust gravity, not just because of the user inputs.

So, you have on one side a fsm that check for input and rotate continously even by a 0 amount, no problem here. Another totally separated fsm would check if the maze has its transform changed, in which case would mean the gravity has to be set and RB waken up. This way you break the link between rotating the maze and acting upon this rotation. You let unity internally detect that indeed the transform has changed.  For future enhancement of your project this is positive, cause you could have the maze rotating because of other factors, not just user inputs, and your system would work just fine. Always separate the user input from the behavior itself. It always comes handy sooner or later. The "possible" downside in your case could be that it introduce a one frame delay between the rotation and the RB management, but you could do that in LateUpdate and maybe a custom action. I mean there is way to go around this is it turns out if works well but with a one frame delay.

 If I am not clear, tell me, I will try again to explain better

 Bye,

 Jean

[LordShaggy]

There is a section in playmaker were you can adjust what throws as an infinite loop threshold.

[Alex Chouls]

There's a bug in Next Frame Event. Please replace with attached file and see if that fixes the problem.

For custom action authors interested in the bug: Finished() was called after sending the next frame event. Since Events are processed immediately, the state had already switched when Finished was called. This can lead to unexpected behavior like that seen in the video.

Since Events are processed immediately, you should generally just return after sending an event. It's also tempting to put Finish() at the end of the method because it feels right, but the safest thing to do is put it at the beginning, before you send any events (it just sets a finished flag in the action).

There may be other problems at play here, but this should help.

Personally, I tend to avoid the Next Frame Event action. I would handle the input with states using Get Button Down and Get Button Up, transitioning between an Idle state and Controlled state. And maybe split into 2 FSMs as others have suggested (input and behavior).

[ivankio]

It did solve the Next Frame Event issue, although the input update issue remains. But luckly the problem is more isolated and I recorded a short video reply (2:40)

1. Get Button and Get Axis in the "Wait Input" state are not updating their variables (0:23) unless previously reset. Is this the intended behaviour?
2. Shouldn't the rotation happen as is without the imposed delay? (1:55)

I imagine I can be hitting some order-of-execution misunderstanding. (BTW, your 3rd paragraph was directed to custom actions authors, right?)

Thanks for the support. I know it doesn't come without resources/effort/time.

Also, I liked the idea to separate input and logic for the triggered states, but as I'm dealing in part with simultaneous axes, even playmaker examples (GetAxis and GetAxisVector) show them being read inside the very states that do the logic. Otherwise it would be overkill to Set FSM Float with separate FSMs, right?

I mean, I'm not reluctant to do things in a different way. I did it as shown in the start of the first video, it was working with Controlled states - not exactly but very similar to how both of you would approach. I'm just trying to understand what is theoretically possible and suggested: to use single frame state transitions to do logic every frame. That's powerfull and I will be able to delay the development of custom actions .