Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kocosephia

Pages: [1]
Hi, I can confirm there's a bug with the arrays of custom types resetting on play  :-[

I'll get a fix into the next update.

The workaround, for now, is to make an array variable of the appropriate type and use that in the action parameter. You can use New Variable in the variable selection menu to quickly make the array variable (instead of multiple menus in the Variables tab). 

Sorry for the inconvenience!

Thanks so much for letting us know! Looking forward to the update. In the mean time, is it possible to use an FSMObject array and set the FSMArray.ObjectType property shortly after the array gets created? I notice that this works, but I'm not sure of the right place to do this. If I set the FSMArray.ObjectType in void Reset after a null check, this will work if I reset the action once after creating it, but won't create with that object type as the FSMArray is still null in the reset function.

So, is where is the best place to set FSMArray.ObjectType so that it gets set right after the instantiation of a new action?

PlayMaker Help / What is the FsmStateAction Init method for?
« on: April 13, 2018, 09:18:03 AM »
It's signature is

public virtual void Init(FsmState state);

I want to override it to initialize the object type for an FSM array in a custom action, but I'm not sure when this method gets called and what its intended use it.

Code: [Select]
        public override void Init(FsmState state)
            if (AudioArray != null)
                AudioArray.ObjectType = typeof(AudioClip);

Does anyone see any problems with this?

Thank you Derek for you suggestions. Unfortunately neither ActionTarget or Objecttype worked in this case.

Where is the right place to set [FSMArray.ObjectType]? If I could answer that question, I could solve me problem.

Hello! I have a hopefully simple question. I'm writing a custom action that wants to use an FSMarray of AudioClips as an input field.

I've tried using the array editor attribute on my public FSMArray fields:
Code: [Select]
[ArrayEditor(typeof(AudioClip), elementName: "Clip")]

But when I do this The values I play inside those arrays are cleared on play (serialization problem?)

I've also tried:
Code: [Select]
[ArrayEditor(VariableType.Object, elementName: "Clip")]

This works, and I can use audio clips fine in the action after doing some type checking, but there is a problem where I cannot select FSMArray variables in my FSM unless they are of type Object. I assume the problem is that the my FSMArray.ObjectType isn't set yet. But if that is the case, what is the correct way to do that in my action?

I've Tried
Code: [Select]
override Reset()
    [FSMArray] = new FSMArray();
    [FSMArray].ObjectType = typeof(AudioClip);

but this doesn't seem to work. Anyone have any suggestions for the correct way to do this?

PlayMaker Bug Reporting / Actions being called twice
« on: March 16, 2017, 11:26:34 AM »
Has anyone else had this problem? I'm pretty sure it's a playmaker bug.

1) What happened

Actions on an action sequence set to execute before any other action that uses the update loop will execute twice instead of once.

2) How can we reproduce it

Create new FSM

Create three states:

State 1: Empty, transitions to state 2

State 2: (Action sequence state)
   Action 1: int add action to increment variable X
   Action 2: wait any amount of time
   Action 3: int add action to increment variable Y
   Action 4: wait any amount of time then trasition to state 3
State 3: Empty

The result will be Variable X will have been incremented twice while Variable Y will have correctly only been incremented once.

Hi Jean,

Your post was hugely helpful! Thank you! I'm going to mull over the information you've given me, but I'm sure I'll be back in the next couple days to ask more questions. I really appreciate it!

Just couple quick questions:

"use nextFrameEvent wisely on critical operations to give time for an event ( and its associated data) to spread inside an Organ and Also for Unity to process things up, it's an important point for the sanity of your project."

I'm taking this to mean that when sending data through an event it should look something like this:

1. Sender sets event data
2. Sender sends event to receiver
3. Receiver transitions to a new state via sent event
4. Receiver consumes the event data with GetEventData/Properties
5. Receiver uses a nextFrameEvent action to make sure that all received data has been properly processed before continuing and using the received data.

Is this right?

Second, I would love if there was an example resource or project I could look at, that in your opinion does things in a very good way. I love your analogy of organs for a body, do you have an example of an organ that you feel is set up "the right way" I could comb through?

Again, thanks so much! Playmaker is a great asset, for sure.

Hello everyone!

We are using playmaker to try and build what essentially amounts to a level editor for a project we're working on. That is, we want to have simple behaviors encapsulated in actions like playmaker already does so well, but we also want to have larger, complex behaviors that are composed of actions encapsulated in some way as well. The idea is to be able to string together these complex behaviors to give ourselves even bigger building blocks than actions.

A couple examples of complex behaviors might be:

-Make this object drag-and-droppable and wait for it to be dragged to a target, firing onHover and onDrop events as necessary.

-Explode this game object by adding colliders, an explosive force, a selected particle effect, etc.

-Ask for keyboard input from the user by bringing up a UI and store that input in some specified variable.

Now, we're not sure exactly the best way to go about this but we had some ideas, and I'm curious to see what other playmaker users have done or what they would do. Some of our ideas are as follows:

1. We've thought about using templates to encapsulate complex behavior, in which case the current runFSM and Foreach actions feel a little limiting (specifically for running behavior on multiple targets simultaneously and providing input to the templates). But this might be the best solution if we were able to create custom actions to run FSM templates.

2. We've thought about just making large, complex actions, or maybe just scripting singleton objects that hold behavior that's simply manipulated by playmaker actions. This solution has the problem of bloating the code-base and being less flexible and reusable.

3. We've thought about just using FSMs prefabs that we instantiate which take input and provide output. This is like solution 1, but without the limitations of templates, losing some benefits of ease of use and creating a problem where multiple instantiations of gameobjects that hold FSMs are required for many objects running the same behavior (say 50 targets all exploding at once).

Anyway, all of our potential solutions seem to have a common problem that needs solving, namely: What is the best way to communicate between FSMs? The built in way seems to be to use event data and events for communication and data delivery,  but is this truly the best method of communication between FSMs? Does anyone have a project where they've done it better? The problems with event data for us is that
(1) it's not transparent to one FSM what data another FSM requires to be bundled with an event. We have an action we are working on that does some playmaker-style reflection to try and make that clearer, but it's messy right now. (2) Only one data-object of each FSM type can be sent at once. We build our own send event info action to overcome this limitation, but it's a little clunky, packaging a custom data object and sending it through the FSM Object event data slot.  (3) Bloating the global event namespace with a thousand different event names and requiring senders to have prior knowledge about what events another FSM responds to. We might be able to overcome this somewhere through a strong naming convention, but that's a little bit of a band-aid.

Sorry for the longish post, but here's my curiosity: Has anyone else wrestled with the kinds of problems that we currently are? (How to use actions to compose larger, most complex yet reusable behaviors, and creating robust inter-FSM communication.) And if so, what solutions did you end up coming up with? Or, is there some resource out there that has suggestions on this kind of thing?

Thanks a lot guys! And happy playmaking.

Pages: [1]