OOh, nice!
Hadn't thought of that.
In the interests of modularity, though, how do these "nested" FSMs get treated? For example, what would I have to do to set up a routine in a "nested" FSM (one that's only ever used within an FSM with the "Run FSM" action) so that it will detect what it's "parent" is so that I can have, say, a couple different objects all using this template but each one having slightly different values that it needs to pass back?
For example, say in a multiplayer game you have the game instance running with the main player character and the instanced visiting player characters... Each character has the same general FSM that's controlling things like the position, rotation, etc... But in the case of the visiting player's gameObject it reaches in, grabs it's identity (as either a host or visiting controlled) and then determines what subset of nodes to run through?
I dunno... I know that this idea may not be the most ideal for this kind of situation... But communicating between parentFSM and childFSM is something that I think would surely help in being able to parse and understand so as to know how to address this kind of setup.
right now I'm thinking that the most ideal use I can think of right now would be using these FSMs to have controls for the camera system I'm working on... Since it has multiple modes and both horizontal and vertical being separate I'm wondering if it would shave down time, energy and CPU cost if I had each mode running an instance of the movement and having a way of detecting "This is the vertical controller" or "This is the horizontal controller." Since there are some minor differences between the two but the over-all modes behave nearly identically in how they do their thing.
