DebugLog

[habitoti]

Hi,

just bought Playmaker, since I like the idea of a visual FSM (as an old-school programmer, though, I feel it is too much clicking and too little effect for some of the actions, like property/variable manipulations...so I prefer to attach scripts for that...that being said, an easier script integration -- for example just write some inline code in the FSM itself -- would be great, especially parameter passing in both directions when invoking methods...)

But that's not what I wanted to ask ;-) ... I tried to output a variable to the debug log, and it changes pretty often. So the log fills up quickly, however it does not scroll automatically, so I can't see the actual output while it happens. I tried to redirect to the Unity log, but then it just shows the fact that it wants to output a variable, but doesn't show the value. Is there any way to make the log scroll live?

Thanks, habitoti

[jeanfabre]

Hi,

 I use playmaker simply to wire my logic, and I regularly rely on scripts and frameworks outside playmaker when the tasks to perform are not really fit for the FSM approach. For example all your logic for screen managments, or player status are way easier to manage with playmaker, and you let scripts deal with hardcore algo such as IK, involving data processing etc etc.

https://hutonggames.fogbugz.com/default.asp?W1096

this is an amazing little tool you can get on the asset store, and it will make your debugging life much better

http://forum.unity3d.com/threads/149130-Graphical-Analyzing-a-debugging-tool-for-programmers-RELEASED


bye,

 Jean

[habitoti]

This looks really cool, but I think it's even a bit too much for my usecase. I just want to see the output to the log as it happens. This would require the log to live scroll (which I believe should be -- and usually is -- the standard way of doing this...). Or to output more meaningful data (i.e. the whole output that would also go to the Playmaker log) to the Unity log (which behaves correctly).

I see that you use the FSM as I plan to do it. For this, a more "natural" connectivity or even much tighter integration of scripting would be great!

Regards, habitoti

[jeanfabre]

Hi,

 PlayMaker Actions, the building blocks of playmaker, are plain c# scripts. With few custom actions ( they are really easy to write, just copy paste from the set of official actions bundles with playmaker) and you are good to go in 2 mn.

 The connectivity is really all there between playmaker and scripts, only, I agree, not documented so much, but if you study all the various port I did with various assets on the asset store, you'll see that there are indeed no limitation as to how playmaker and scripts can work together.

https://hutonggames.fogbugz.com/default.asp?W714

If you have questions on how the playmaker api works, let me know.

bye,

 Jean

[habitoti]

So far, I integrated some of my existing scripts by having them send FSM events in the one direction, and calling them through "InvokeMethod" action the other way around. Having to first set some public script parameters before calling a parameter-less facade method feels a bit clumsy, though. It would be great if the method to be invoked could be parsed and the parameters be provided within the invoke call. Nevertheless I believe you are right, in principle every imaginable integration can be done that way. Are there other significant means of bonding script and Playmaker world (I know of sending events, of course...)?

Maybe I just need some more time to change my "workflow" (and "thinkflow" ;-)...I am always thinking: wouldn't it be worth to do this and that calculation rather in a separate script, and then I end up with 4 lines of code that could have well be done in the action (and thus prevent scattering code snippets around). In such cases, It would be great to have something like an "inline scripting" that embeds a small editor, and you have access to the local scope of the FSM and just write some code (basically as an extension to the FSM script itself). I wouldn't mind if it was c# only then ;-)

[jeanfabre]

Hi,

 Yes, inline scripting action would be great, if you find a good library that can compile c# code at runtime, please let me know, we can then turn it into an action very easily.

indeed, I like your "thinkFlow" wording, it's very much the case here that you need to adapt your technics more than try to configure playmaker or else, cause the problem will be true even on pur c# frameworks. Take vectrosity and nGUi... two different worlds in terms of technics and how it's built and how it communicates with the outside world, and it's not really possible to change this fact. It's the same with playmaker I guess.

 Tho, indeed I would like too a more beefed up api, for example to have delegates on events firing, getters and setters for fsm variables to be able to hook to changes easily, more control over the actions interfaces, a proper xml based fsm description, so that it can be regenerated on a web page for example ( for docs, etc etc). so indeed keep coming with proposals and your experience, it's very much helping.


bye,

 Jean