Ok so I think its a good idea to add a disable and enable behavior to flowlab, heres some good examples. lets say the player gets damaged and you want it to give the player knock back but you don’t want them to move during that, then you could use a disable behavior to disable that line of behaviors so they cant move during it. I think im asking a bit much but it would be nice to have this.
1 Like
One way to do this is to make a global variable attached to a switch block. If the global variable is true (the player should be “disabled”), then turn off the switch. Your movement keys can go through the switch block, so that if the global variable tells the switch block to turn off, then the player’s movement doesn’t work until the switch is turned back on.
I like that idea. Yes you can use switches, but that can end up quite messy.
Maybe have a disable input for the bundle blocks that would disable everything inside them.
Would even save more wiring.
That way you could activate/disable different actions for your player quite easy.
(1st step towards finite-state machine ? )
1 Like
Isn’t the enable behavior suppose to do this??
Enable set to false
is suppose to stop the object and make it not solid.
If you need it to be solid, use a switch to disable movement and have 0 in forward velocity.
I think that the intent here is to disable a set of behaviors, not the entire object.
@TinkerSmith saw right away that this is basically what we need for State Machines, which was my first thought as well 
4 Likes
YES … state machine WHOOP WHOOP
Thanks for understanding my cross-wired tinker thoughts @grazer
1 Like
wait so were actually getting this! 
Meanwhile, you can always use Switches, Bundles and the “enable” behavior to do this.
2 Likes
Can somebody explain what a state machine is please? My brain is empty right now…
1 Like
No worries @MetaNinja , it is a fancy word for a programming concept.
On the phone right now, hard to find a simple explanation, only have these at hand here:
https://jessewarden.com/2012/07/finite-state-machines-in-game-development.html
Sounds utterly complicated, but basically its a way of organizing your code to make it easier to use. (VERY SIMPLIFIED … I KNOW)
In a way we can already do this in Flowlab. Imagine you put every action your player can do into a bundle. ‘Walk’, ‘Jump’, ‘Shoot’, ‘Got hit’, ‘Die’
Then you have a main bundle/part that evaluates what input is available or what is happening around the player and then activates the state/bundle accordingly.
So direction key press -> state:Walk , space pressed -> state:Jump
States are exclusive to each other, so while you jump you can’t walk, etc.
For sure (I hear it coming) IT CAN ALL BE DONE WITH SWITCHES AND FILTERs, LOL … I said it first
But what do you prefer, 2 screen wide scrolling to fix something in your wire jungle, or reorganizing connections between state/action blocks. For sure, inside your bundle/state you still have to wire everything up. But now, if something is wrong with the jump for example, you know immediately where to go.
Above mentioned discussion, to be able to activate/deactivate everything within a bundle would make this even easier. You could have different [shoot] states, let’s say for different weapons you pick up along the way. [shoot1] = pistol, [shoot2]= rifle, etc. That way you can change the player behavior easier = more recoil for the rifle.
Again, this is very simplified and written in a rush during my break.
I try to find a better example tonight when I’m at home, but without giving to much away here an example what it looks like inside something @todorrobot and myself are working on:
Ok, not really a state machine but a good example how organizing your code can make life easier. If there is a problem … I know where, if we want to change the game flow … easy-peasy
So see it as super smart bundles that get better ways of talking to each other