API Reference not complete

[ish]

Hi I was going through the API Reference in the playmaker manual via this link
https://hutonggames.fogbugz.com/default.asp?W127

I was very confused for a while because the API doesn't see complete. It doesn't show some methods. For example I don't see the Event method for FSM or the override methods for FSMStateAction. Which begs the question of what other awesome stuff is missing.

Should I find this reference elsewhere? Where can I find an exhaustive listing of the public interface for all these classes?

I also don't see any script that exposes this interface for me, just a runtime .dll.

[jeanfabre]

Hi,

 What are you trying to achieve? If you explain what you need, I'll see what can be done and what api methods you need to use. Documentation is running behind on this, that's true. So don't hesitate to ask here, I'll help.


bye,

 Jean

[ish]

As a developer I really do need to be aware of all the possibilities so I can make the best plan of action when I am working with Playmaker, and a half solution of only asking for what I need won't be optimal.

It would help me best if the API is completed. This is a major pain point to devs as we rely on API documentation if we don't have the interface code.

Check out the system for NGUI and Toolkit2d to see how they maintain their API every incremental version automatically.

What can I expect in terms of seeing a completed API for Playmaker?

[jeanfabre]

Hi,

 I agree. I am not sure what are the plans to update the api, but it's definitly something PlayMaker is aware of.

The main point of entry to learn the api is to study the custom actions. There is not much outside custom actions to be honest. PlayMaker api will not let you create fsm at runtime or edit fsm in a convenient an powerful way, it's possible with some hack but you will quickly run into major implementation issues simply because PlayMaker api is not meant to let you create Fsms. It's primarely here to let you create custom actions and bridges.

I personnally learnt by simply copy pasting the actions that were the closest to my needs and take it from there.

As for the playmaker api documentation itself, I would personaly choose a different direction and provide use cases as opposed to a dumb of class comments and hierarchy, I never was able to properly grasp an api by simply looking at references. It only becomes necessary in very rare cases, and since we have intellisense it's all there when you edit the scripts anyway.

There are plans to provide a proper online repository of well organized samples. PlayMaker Api will be covered for sure here.

Meanwhile, do not hesitate to ask questions, I'll do my best to provide samples and suggestion on how to achieve it.

 Bye,

 Jean

[ish]

It is very common for developers to use a documented API. It is a must, especially for a paid software. When can we expect the documentation for the API?

[jeanfabre]

Hi,

 I agree. I am thinking of building a script that woud as I said expose all the api one after the other that actuall make use of it, binding Fsm Variables with script variables, sending event back and forth between PlayMaker and scripts, how to bind delegates to playmaker events, how to check a Fsm state etc .

What exactly are you trying to do with Fsm and FSMStateAction?


Bye,

 Jean

[ish]

Hi Jean,

I need to know the API so I can see what I can do and formulate a plan from there. As a developer I won't be using Playmaker conventionally and will be making wrappers around FSMs. The wrappers and their versatility depend highly on the public interface (API) available. Another way to think of it is, I need to know what chess pieces lie on the board so I can determine my strategy.

[jeanfabre]

Hi,

 I see. To my knowledge, you will have show stoppers problems wrapping fsm, that is, don't expect being able to serialize fsm content and/or create fsm programmatically, it's something that is not really supported at the moment.

pm me if you can't talk publicly about what you are doing. But I hear what you are saying, and currently, there isn't any exhaustive api document.

bye,

 Jean

[ish]

No problem I can share what we are trying to achieve.

It's fine if we can't programmatically create FSM, it would be easier but we can create Instances of an FSM and use Unity magic to attach it to different objects.

What we plan to do is split the FSM from the logic/programming, so we can use the FSM as a transition manager, giving permission to change states. The script would handle the state changes.

The workflow may be something like objA.requestStateChange -> fsmWrapper -> fsm -> allow/deny -> fsmWrapper.stateChange

And we would extend it to allow for interrupting states and also queuing states.

And if possible have a wrapper that can wrap multiple FSM so as to create complicated state machines and transition logic.

[jeanfabre]

Hi,

 Yep, using Fsm for purely game state management is totally inline. I worked on a project where PlayMaker had this role for managing the whole ui windows, modals, menus etc, not being responsible for the actions at all, simply to control views ( states basically).

Fsm can be ran using templates, and you should definitly study sub fsm as well that allows you to run an fsm template within an action ( action: runFsm). that's powerful indeed.

now, there isn't any wrappers to combine multiple fsm. Instead I recommand doing like Ngui ( kind of), where everything is a gameobject, so you would have a hierarchy of gameObjects, each with its own fsm and "responsability", then you work out a way for all of this to communicate without any hardcoded links, typically, using either a fixed/standard hierarchy layout,and the expected interface.

For example, using "get fsm xxx" actions, you can access a gameobject fsm just with defining it's name and variable as strings. so if you object implement fsm "xxx" and has variable "yyy" then you are good. Very powerful, I use it all the time, it's allowing you to create loose connections between prefabs and complex/changing features.


 Bye,

 Jean