State Machine Plugin -v.91 - Beta[updated 2/17/20]

New releases and general discussions.

Post » Tue Feb 16, 2010 8:24 pm

I changed them to on state activated and on state deactivated for the next build.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Tue Feb 16, 2010 9:54 pm

This is so cool :D
Thanks!
B
33
S
15
G
6
Posts: 242
Reputation: 4,343

Post » Thu Feb 18, 2010 1:46 am

Plugin has been updated a bit. Im working on the adaptation to a behavior.

Deadeye gave me the idea to have the option that when you set a state to true all other states are turned to false by default. this would be in addition to the normal changing state options. Do you guys agree or disagree?
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Thu Feb 18, 2010 8:10 am

If it is optional, sure. That'd work like a semaphore. However, when you have multiple state machines, say one for each "activity" - hunting, showering, mating etc. each has a set of states - you'll probably want it all neatly organized into sets or such :)
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Thu Feb 18, 2010 3:15 pm

how would these sets of states work? could you tuen the entire set off. can you define this idea a bit better so I have a better vision of what you would like.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Thu Feb 18, 2010 5:01 pm

I think he means something like a family. Example for the family "door", I might want door_is open, door_is closed, door_is opening, door_is closing. Then if the state is door_is closed the whole family would be negated.
Image Image
B
161
S
48
G
89
Posts: 7,345
Reputation: 66,245

Post » Fri Feb 19, 2010 4:36 am

[quote="Aeal5566":2yyrevbh]Plugin has been updated a bit. Im working on the adaptation to a behavior.

Deadeye gave me the idea to have the option that when you set a state to true all other states are turned to false by default. this would be in addition to the normal changing state options. Do you guys agree or disagree?[/quote:2yyrevbh]
Well, if more than one state is on, then it's not really a state machine so I'd say it's a good idea.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Fri Feb 19, 2010 4:41 am

You can have states nested within states. so more than 1 state returns true.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Wed Feb 24, 2010 1:33 am

[quote="Aeal5566":3q0euelx]You can have states nested within states. so more than 1 state returns true.[/quote:3q0euelx]

This is what a Finite State Machine looks like. A door cannot be opened and closed at the same time. You could, however, have ANOTHER finite state machine that is only used while inside one particular state (thus addressing nesting properly).
For example, following the door diagram: the door could have a locking mechanism. When in the closed state, you could change to a lock state in the door machine. When in the lock state of the door machine, you could have access to a lock machine, that upon reaching a certain state, issues an unlock rule to the door machine, which takes it to the closed state again. This sounds rather complicated here, but it's veeeery simple using separate machines, and they never mix up.

Pert diagrams allow multiple active states, that is how concurrency is designed. FSM are completely different from Pert diagrams.
A finite state machine has only one active state, which is the current state of the machine. If there were any more active states, it woudln't be a state machine per definition.


All that said, I[size=150:3q0euelx] have a request[/size:3q0euelx] (two actually).
[list:3q0euelx]
[*:3q0euelx]First the simple one: an expression to get the current state.[/*:m:3q0euelx]
[*:3q0euelx]Second: A FSM is much more useful with transition rules. Could one add rules in the form of rulename->destinationstate? so then one could just do Sprite[FSM].trigger("jump") and if any rule in the current state matches "jump", it would go there. Additionaly, a loop for traversing these rules would be nice (with currentRuleName and currentRuleTarget expressions). One should also be able to check if a state has a certain rule or not, in the form of Sprite[FSM].ruleExists(state,rulename).[/*:m:3q0euelx][/list:u:3q0euelx]

The above, coupled, would enable pretty good AI.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Wed Feb 24, 2010 6:24 am

So rules would be a part of states so you could add rules to states I guess I really don't follow what you are saying...
If you could draw a picture or give an example of what you are talking about it would be easier for me to understand.
The get current State is easy enough I can do that no problem.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 1 guest