[SOLVED] Is there a way to extend inherit properties of another object or FSM?

[ryf9059]

Is there a way I can inherit properties of another object or FSM? Similar to #include in C++ or import in java, or just extends in those common languages.
I basically have a object with multiple FSM and they share some variables and functions. But every time I pass a variable from one FSM to another I always need to create a copy and have a variable to store it. This caused a lot of duplication and I want to get rid of them. For example if I'm calling a few conditional statement I have to copy all the variables condition down to all FSMs and it just extremely wasteful and cause lots of duplicates, and we all know duplication is bad.

I thought of creating a script containing all those variables but when I use get properties I still need to store them in a temp variable which is still duplication in that scene.

Any advise on a workaround for this one?

P.S. I know I could use global variables but that doesn't quite fit the context, I want that variable only visible all the FSMs under that object, similar like const in C++ if you use #include

[jeanfabre]

Hi,

 If I understand well your needs, that' how I do it: I store the Fsmxxx variable itself, that's generally enough to keep data in memory to process it intensivly and efficiently. since you seem to be on control of your script, simply maintain an arrayList or hashtable, not strongly type so any FsmXXX can go in.

When I need to reference Fsm directly, this is then a standard monobehavior like anything else.

But can you confirm that you are not working within Actions? you deal with this outside playmaker fsm environment right?

bye,

 Jean

[ryf9059]

If I understand well your needs, that' how I do it: I store the Fsmxxx variable itself, that's generally enough to keep data in memory to process it intensivly and efficiently. since you seem to be on control of your script, simply maintain an arrayList or hashtable, not strongly type so any FsmXXX can go in.

When I need to reference Fsm directly, this is then a standard monobehavior like anything else.

But can you confirm that you are not working within Actions? you deal with this outside playmaker fsm environment right?

Actually I am working with actions and inside the playmaker fsm environment.

For example I have a logic FSM that takes inputs and plays actions like fire, jump, etc, which all have their own sub FSM. But for all the actions I need to determine if the player is facing left or right.

Here goes the problem: determine the facing direction takes me 4 actions and 5 variables and 5 events, the events can be global and the actions and variables can't, so in this case I need to make a copy every time I perform a direction check.

So for fire I have different skills and I play different animations for each which means I will have to copy those condition for all skills for fire, and that's just for fire itself. I have jump, run, fall, all other stuff, if I copy the conditional action and variables down to all of them there will be a tremendous amount of duplication.

Right now the temporary solution I have is to put the direction check in my main logic fsm and having all sub fsm calling back to get the result, but I still need to compare the result in order to take the next step in those sub fsms and that still takes 2 actions.

My logic looks something like this



So that's my situation and my approach. I can't think of a better way if #include mechanic is not there.

[jeanfabre]

Hi,

 Feels good to see nicely laid out Fsm. Nice and very "feng shui", just to be picky you could swap "Do Fire" and "Do Jump" to avoid transitions to cross 

I think you have actually a perfect example of how sub fsm can help. I don't see anything wrong with your approach. Duplication of variables isn't really there is you use sub fsm.

When I have high level variables like your left and right properties, I rely on fsm variable getter and setter, I don't see this as a problem. I simply go get the variable where I know it is up to date. I call them fsm "Meta" they only host variables, no logic at all, simply a repository of variables, that I only give access to certain fsm ( by convention). Now in your case you could also fire some global events "is Left" and "is Right" or something and then all your different fsm in need to such information can catch it without even accessing vars. and that's actually a very good technic in scripting. it completly separate your logic. A given fsm that only need to know if the user is left or right simply listen to the propery events, no hard binding and that's a good thing.

so "inheriting" is really a matter of you to enforce who has the right to inherit. It's been discussed many time to allow for fsm to declare variable as "visible" to its childs and stuff like that, but it's perfectly doable right now. it means having a local variable acting as a buffer if you need to do some computation with it.

1: get the variable from the "Meta" fsm, and store it locally
2: do some work with it
3: anytime you need to do some work again, get it first from the "meta" to make sure its value is up to date

It may seem like an overhead but internally it's not really different to access a local variable then a different fsm, it's just a different pointer, so don't worry about performances here. the obvious improvement is using events if the value is a bool or changes only few times ( like this left and right), for example in a the case of a player position, since it changes always, this becomes more of a problem and direct access it preffered of course.

Bye,

 Jean