Accessing FSM variables or triggering events without giving name of them.

[crystani]

Using playmaker, I could almost finish the project. (TPS game for iPhone platform.) As I gave up supporting iphone 1,2 generations for shader, I couldn't notice garbage collection problem was that severe. However, when I run the profiler, it was obvious that there were lots of GC calls inside playmaker's update calls.

Maybe it would be a solution if playmaker Fsm can access other Fsms using integer tags (like what we do for load scens with numbers) or references of playmaker variables or events.   

[giyomu]

are you sure that the GC you see doesn't come from some certain action working with string op, because for what i see know and what i am using, i didn't catch any GC in profiler within fsm update() method, of course using playmaker GUI in editor will get you some due to GUI / GUIRepaint() stuff kicking in but other than that ...

well i didn't explore all action yet so..

[crystani]

are you sure that the GC you see doesn't come from some certain action working with string op, because for what i see know and what i am using, i didn't catch any GC in profiler within fsm update() method, of course using playmaker GUI in editor will get you some due to GUI / GUIRepaint() stuff kicking in but other than that ...

well i didn't explore all action yet so..

I think that if you use actions like SetFSMInt with EveryFrame option turned on for a few dozens of instances, this could make GC calls once a few seconds. But I couldn't notice it until I turned on profiler cause I used iPhone 4 only... It is not really bad compared to the case that I could see GUI/GUIRepaint()'s making lots of GC calls.

Maybe I have to fix my FSMs in order to reduce those actions that access other FSM's variables and events... However, I have to use them in many cases.

[Alex Chouls]

Those actions should cache the variable reference for better performance and reduced garbage collection - will fix this.

[MaDDoX]

It is not really bad compared to the case that I could see GUI/GUIRepaint()'s making lots of GC calls.

That's a quite important information. I'm getting some very bad playback hiccups (to the point of physics skipping collisions, etc) inside the editor, and those don't occur when I compile/deploy the project and play it externally.

Since the PlayMaker GUI is "auto-added" to the scene every time you remove it, what's the proper way to disable it? Setting it in preferences or something?

[jeanfabre]

I noticed as well these hickups. for a while I though it was my code, and then realize it was playmaker. And yes, it only happens during editing. when published, no problem at all ( at least with my builds).

We shoul dbe able to set wether we want gui to be handled by playmaker or not, in my case, no built in gui at all, so it's not needed.
 Bye,

 Jean

[Alex Chouls]

There's a preference to turn off Auto Adding the PlayMakerGUI Component. You can also use Enable GUI to enable/disable the component at runtime.

There is also some overhead to running the Playmaker editor, and unfortunately I don't know of a way to profile editor window code in Unity, so it's hard to optimize. But I'll take a look at some point - I'm sure there's some low hanging fruit

I might also add an option to enable/disable the editor window while running, so you can play the game without the overhead. As a workaround you could try hiding the Playmaker editor in a tab to disable it... that should work. Or create layouts with and without the playmaker editor so you can switch quickly.

[jeanfabre]

Hi Alex,

 Thanks for all the advices. Useful

 Bye,

 Jean