Looking at your states, there seem to be some confusion about how playmaker works. You need to think more like a programmer I think.
Alright, let's start with the basics
Most of the actions take input and give output. Therefore you have to think less modular, and more "If I do this, I get that, which then again , I can use as input in the next action".
As a practical example.
We're in frame 1. The mouse pick action kicks in. It creates a ray from the mouse coordinates into the scene. It then collides with a GameObject there. That means, whatever it collides with, that gameObject will be "under" the mouse cursor.
So of course, to check more specific things, we need to know what the current gameObject the ray collides with actually is. To do that, we create a gameObject variable and put it in the Mouse Pick action as "Store Game Object".
This is all that's happening for this frame in the MousePick action. So the action lets PlayMaker continue to the next action in the state, which is the Has Component action.
The first variable of the action is for input. Whatever we put into it, it will then check if the component is on that gameObject. By default it is set to "Use Owner", which in this case we do not want, because the Owner is the gameObject the FSM component belongs to. Instead, we change it the the gameObject variable which contains the output from our MousePick action before.
Now, apart from input and output we can also send events based on the result of an action. The HasComponent action will either say "Yes, such a component indeed does exist on the specified gameObject!", which programmers call a "True" statement, or it'll say "Nah, nothing like that on there!", which is called a "False" statement.
So if the statement is True, the true event is sent by our action. If it is false, the false event is sent.
In case you missed that, events are the things you can click on to drag a connection to other states. You create them by right clicking at a state.
Now, that understood, any action that returns the same event for both True and False events is entirely abundent. It's like saying if an apple is green, it tastes great. And any apple that is not green, tastes great also. The result of that statement would be "Any apple tastes great", hence the irrelevancy of the previous two statements.
So back to the HasComponent action, we want it to do stuff only if the gameObject under our cursor has that specific component. So we leave the False event empty, and set the true event to FINISHED. Then we create a transition on that state and use the FINISHED event for it.
We then create a new state, which we connect the FINISHED transition to. That new state will contain the EnableBehavior action. Again, the gameObject input of that action needs to be set to the gameObject variable we created earlier and which contains the result of our mouse pick.
Now, if your behavior does not appear in the dropdown next to the behavior input in the action, it is actually a component. Luckily the same action also supports components/objects. Just select the component in the inspector and drag it into the Component input of the action.
Enable defines whether it should activate or deactivate the behavior/component. Now, Reset on Exit does exactly what it says, and we definitely don't want that. With it set to True/On it would reset the changes once you leave your current state. Since we're going to leave the state immediatly after the action is finished, turn it off, else it will do nothing at all.
Now, what these 3 actions do, is in the first state, they will once per frame (60 times per second) first check what's below the cursor, then check if that gameObject contains the needed Component. If it does, it will go on and enable the behavior, if it does not, it will wait 1 frame and try again.
Attention: What we've just created is an infinite loop! What that means is that the computer tries to run it infinitely fast, which will crash unity. Why? Well after the mouse is over a gameObject with the right component, it will go to the next state immediatly. There it will finish its' work and trigger FINISHED automatically (FINISHED is the only event that gets executed automatically when all the actions in a state are done.). This will send it back to the first state, and it will run it again, but it won't pause for one frame as it would have if the first state would loop itself using the "every frame" option of the actions. Since the whole process takes only a split second, the mouse cursor has obviously not changes so the first state again returns true, and sends the FINISHED event.
All this loops forever and Unity tries to do this all in one frame. So because it's just one frame, it won't update your mosue, even after minutes. This makes unity freeze for you, even though it's actually just looping your 2 states forever at maximum speed.
We can fix this with the "Next Frame" action. It works just like the everyFrame option on actions. Once a new frame starts, it will send an event. If we put it at the bottom of our second State and set the event to FINISHED, it will then always wait one frame after activating the behavior and only then return to the first state to check again.
Now, this may be all nice and dandy, but you'll note that everything happens if the mouse is over the gameObject, and it does not care in the slightest if you just clicked or not.
To fix that, we create another state, which we will also make the start state (right click - > set start state). In this new third state, we will put a "Mouse button up" (mouse button down if you prefer) action. That action checks every frame if the mouse button went up or down, and if it did, it sends an event. So we create another FINISHED transition and set the event in the mouse button up action to FINISHED. we connect the state with our very first state. Then we look at our second state (the one with enable behavior) and connect the FINISHED event there to our new start state.
Now what happens is, in the start state it will check the mouse state every frame. If the mouse button goes up/down, it will go to the next state. in that state it will get the gameObject under the cursor and check its' components, if the component exists it will continue. If it does not, it will loop that state until there is such a gameObject under the cursor.
That is definitely not what we want. We don't want to click anywhere in the screen and then move our mouse over an object after our click only to have it continue as if we actually clicked on it. So what we do is we create another event, let's call it FAILED in the events tab. then we create a new transition in our state (the one which checks for the component) and then we use that event as our False Event. We connect it to our start state again, so it can once again check if the mouse goes up/down and try again once it does.
Phew, and that's it. Detailled explanation on the basics of playmaker
Do ask for specifics if something isn't clear.
Best,
kiriri
