several triggers in one state? does each process complete fully?

[jeanfabre]

Hi,

 I'd like your opinion on a situation:

 I have one object that collides with two distinct colliders. Ideally I would like to have one state with collider enter and exit actions for both colliders. when entering or exiting any of the two colliders, I simply set a bool flag on and off and straight away return to the state.

Now what happens if the object colliders at the same time on both colliders? knowing the fact that all subsequent transitions and state only work with onEnter and Finished transitions, the series of actions following a trigger is in my opinion one "stack" and not spread into several frames.

So does each collider triggers in turn or the process can be stopped because the second collider trigger kick in before the full series of transitions and actions completed for the first trigger?

 Trying to build a scene to debug this, problem is I don't know if it works because its fast enough, and could happen at lower framerates or lower spec machines.

This also raise some vocabulary problem: How do you call a series of transition and states? a flow? or else? It's difficult to express myself clearly to describe what I mean.


 Thanks for your insight,

 Jean

[LordShaggy]

Any chance you could post the FSM so I can take a look or at least try to be clearer on the issue. 

Also (good point) on vocabulary.   Probably would be good to figure out or set some standards on what to call some things.

[jeanfabre]

Hi,

 Here is a screenshot of the fsm I did.

 The key is that in the "check for pipe" state, I have two set of triggers ( enter and exit ). Knowing that all subsequent transitions and actions back to this state are synchrone ( not using "everyframe" or actions doing asynchrone job).

 Scenario:
--  powershoe and topgrippers triggers are perfectly aligned, so in theory both triggers are entered at the same time.

Let say that the "enter" trigger action for the powershoe kicks in . State transit to "raise Powershoe flag", etc etc until it comes back to the start state.
At what point does the "enter" trigger for the topgrippers kicks in?

 Can it happen while the powershoe set of states and transition is in process? or does it kicks in only when it's finished? Again, the series of states following a trigger is continuous ( setting boolean values, checking for boolean values, that's it).

Bye,

 Jean
 

[LordShaggy]

Ok, so the actual check for the collision can only happen when you are on the state that is looking for it. That means that whatever the computer decides is the one that happened first is going to go down that path.

That means, if you are looking for a both collisions.  The first to be read will start traveling it's (Path).  Unless you are checking for the other collision at every point on the (Path) then no other collision will be detected till you return to your "Check for pipe triggers" state.

Remember 1 FSM can only be at 1 state at any given point in time.

If you want to be able to check them both at the same time and have more control.

Split this into 2 separate FSMs on the same object. Use one where you are going to use as your main reference for variables. This is more just for cleanness and handling things easier.

I understand they happen at the same time but your going to have to treat the 2fsms as 1 more or less.  "brother and sister"   that way you can do whatever you want to do at the same time.  Otherwise, your at the mercy of what the computer perceives as the first collider and the time it takes to run the path before the other one can even happen. 

Which honestly, that collision might not even be present any more for that state to pick up on it.

Try doing what I advise and tell me waht happens. 
-Copy that FSM
-Add another FSM to the object
-Past the copied version
-Uncheck all the logic that tells it to go one of the pathways.
-Do that to the opposite one to the opposite pathway you want.
-If you have a lot of logic that is based on states or where things are within these FSMs
-REMEMBER the getFSM state action.  You can actually check on which state a FSM is in and make logic based on that.


That should solve the issue.
If there is some concern over having more than 1 FSM on the object and efficiency situations.  I would go ahead and do it to see how much more haul it actually causes.  You could probably make cuts elsewhere if this is a very important detection.
---------------------------------


So far in my experience, it is best to split up your actions as much as possible.  I usually try to keep a single action to 5action per State.   There are cases where you have to have a bunch of simultaneous calculations,  like if you are trying to get an object to track the mouse or things like that... but I have found otherwise it keeps my FSMs cleaner, more understandable, and easier to debug.

[jeanfabre]

Hi LordShaggy,

 thanks for your insight. I agree on all your points and suggestions, and yes spitting fsm is the key when in doubt or when complex simultaneous behavior is required.

 My solution currently works tho ( sorry if It wasn't clear). I can't fail it at all. I am just unsure if this is reliable as I don't know how internally playmaker works.

 Bye,

 Jean

[LordShaggy]

Thanks.  Hmmm it must be firing off really fast... I would split em just to ensure the consistency, but that's neat that it works.  From glancing at it, I would not have thought it would.

[MaDDoX]

I haven't read it thoroughly, but just skimming through it it looks like my lead coders' FSMs I'm with Shaggy here, trying to process circumstances involving two different objects from the same FSM is calling for trouble, and it *will* result in trouble if both objects can have their states changed simultaneously, as rare as it is. If you're 100% sure this will never happen, you can go for it, but it will make the FSM harder to build/debug/follow than if you split FSMs.

What really sucks in this (needed) process is that you can't have more than one playmaker editor window open at once, and we don't have more than one "panel" in the playmaker editor. In that sense it's a step behind of any decent text code editor.