State Switch to have an unoverwriteable argument so state switches in the same step cannot happen about snowstate

[sohomsahaun]

Sounds like the code logic needs fixing. Why is the state getting changed twice in one step?
If you want a workaround, queue the states for the objects to "lock" the change in the Step event, and execute the changes in the End Step event.

[Juiin]

I have for example, 3 States in my Player Object, Idle, Move and Stunned. When the Player presses the move Buttons it switches from Idle to Move or if he stops pressing them, back to Idle, now an enemy could make an attack which when it hits the Player he would need to switch to Stunned, which has priority over all the other states, but if the code from the Enemy happens before(within the same step) the Move Idle state switching, it would not happen(or happen only very briefly and get switched back to Idle or Move).

[sohomsahaun]

Understood. Then again, this feature shouldn't be included in Snowstate itself. What if the enemy hits 5-6 steps later instead of the same step? There could be a "state lock" buffer, but that would involve Snowstate constantly checking for that in the background, which is not very intuitive.

There are two solutions without any modification to Snowstate.

1. Use a state priority queue to determine which state to switch to.
2. [This is what I do]
   Use a variable to track if the player has been hit this step, and check for that variable in the states you want the player to get hit in. This keeps checking states for the player contained in the player itself, which is very useful when dealing with complex behavior and reduces code spaghetti.

Hope this helps.