opened 05:51PM - 20 Aug 21 UTC
proposal
# Introduction
This is a patching pattern and a small library for creating an… d running State Machines' graphs directly in VL.
Related to the Quest #8.
For a long time I was using external Tools like [QFSM](http://qfsm.sourceforge.net/about.html) and contributions like u7angel's amazing [Automata UI](https://github.com/wirmachenbunt/AutomataUI).
But I always thought - how cool will it be to make State Machines directly in VL, without the need for any external editors. We already have nodes and links, why do we need anything else?
And then, I came up with a very simple solution. @gregsn has stripped it down even more and cleaned it up.
This solution is made in plain VL, no magic involved.
I hope one day vvvv's UI will support it a bit, reducing some copy-pasting and increasing readability.
The lib was already used in two production-grade projects.
# Usage scenarios
The machine can be used in two different ways:
1. Basic (classic)
States are just defined by their names (strings) and the rest of the system is listening to the active string.
2. Advanced
States themselves can contain many different properties, operations and even complete apps, that can run **simultaneously** or only when the state is active.
# How it works
**States** are represented by `Processnodes`.
**Transitions** between states are represented by `links` assigned to `operations`.
To trigger a transition from one state to another a corresponding operation is called.
An operation can be called directly (by placing a node) or by sending a string with an operation's name.
# How to use it
The lib will be provided as a nuget that should be referenced by your document.
For now it's just a single `VL.Statemachine.vl` document and some examples.
See the provided example patches. A video tutorial is coming soon.
Here is the **how to** in written from.
## Basic usage
1. Reference `VL.Statemachine.vl` from your document (for now, later it will be a nuget).
2. Open ` VL.Statemachine.vl`, navigate to `Definitions > .Templates.Internal`, copy the `StateTemplate` into your document and rename it. This is one of your states.
3. Duplicate and rename this state as many times as you need.
4. Create a class for your machine and place `processnodes` of your states in it.
5. Connect them with links and assign the links to operations (which are corresponding to the transitions).
6. The `StateTemplate` pre-defines 4 inputs, enable/disable them in the `Process node` configuration in the `Patch Explorer`. If your need more inputs, just create another copy of one of the inputs and assign it to a new operation.
7. One of the states should be configured as Initial (enable the `SetAsInitialState` in its `Process node` configuration).
8. Feed the `State Manager` to your state machine.
9. Trigger transitions of the machine by placing the nodes of the corresponding operations or sending the names of operations as strings by using the `SendEvent`.
**State machine class with states and transitions**

**State Machine in action**

**One of the states with two inputs enabled**

## Advanced usage
In order to provide properties, operations and/or whole `processnodes` to the states:
1. Define a new interface which derives from the `IState` and add Operations/Inputs/Outputs to it.
2. Use this interface in some of your states (instead of the default `IState`).
3. Use the `GetState` of the `StateManager` to get the active state and cast it to your new interface.
4. If the states are very different from each other, then their operations can by accessed by casting the active state to the particular class (without defining a new interface).
**A new Interface**

**Main state is implementing the new interface**

**Accessing the active state**

# Video presentation
The pattern was presented at 13. Worldwide vvvv Meetup (starts at about 2:09):
https://youtu.be/2gGPh84y-mU?t=129
# Library
[VL.Statemachine.zip](https://github.com/vvvv/VL-Language/files/7023297/VL.Statemachine.zip)
# Conclusion
This proposal can be seen as a ready-to-use library and as general patching pattern open to any modifications / customizations.
---
Also inspired by:
* [State Machines in Mars Science Lab](https://www.youtube.com/watch?v=VvssxOP95s0), although they use completely different approach.
I’ve been messing with the statemachine here, which is useful, but I’d really like to be able to be able to define a ToNext and ToPrevious, so that during debugging you could go back a state (and also have a 1 GO button for simple uses) I get that you can have more than 1 next or previous via other links, it more that if you have a link set to ToNext (and a link to from that to its next state) it shouldn’t action both ToNexts, but step 1 forward, and wait till the next ToNext…
Is there anyway of doing that?
My current usage is more theater cue list when you have a defined set of scenes that follow each other ( in my case also with some branching alternatives, where ToNext wouldn’t be defined, but ToPrevious would) But previously I have found it frustrating when trying to tweak transitions, when I have to go back to the init to get back to where I am working everytime.
1 Like
yar
November 8, 2023, 4:59pm
2
I’ve run into the StateMachine problem a couple of times in Gamma. I find the suggested option at the link interesting, but could never figure out how it works. It feels too complex to configure.
My suggestion is to use Nuget
You can look at a rather old implementation based on QFSM files. But I have also used the same Nuget in its pure form.
VL_state_machine.zip (21.7 KB)
bjoern
November 8, 2023, 5:05pm
3
There is also VL.AutomataUI .
1 Like
system
Closed
November 7, 2024, 5:06pm
4
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.