the "Void" things...

[Red]

I've been reading up on the scripting and I'm unsure what these really mean when applied to using Playmaker.

For example, there are states (when using C# I think it is) where you can set functions or subroutines using code like

Code: [Select]

void Awake()
{
     //Do something
}

void Update()
{
     //Do something
}

void FixedUpdate()
{
     //Do something
}
And I think I can grok a bit of what that means since these are referring to hard-coded functions of the systems themselves... So, an "update" is what's called every frame, a "fixedupdate" is called at specific regular intervals (the references say this is best when interacting with the physics engine) and the things like "start" are pretty simple (that's what the "Start" state is, right?) and even "Awake" (which is similar to the "Start" but called when that particular component is activated much like how "Start" in the FSM will fire off when that component is activated.)

But I'm wondering how I'd approach something like this from an FSM point of view.

Reason I'm asking is I'm trying to adapt some code to use in a side-scrolling run-and-jump game I want to put together as a side project... And the code is showing me that I'd be using things like the fixed update for applying the force needed to move the object, the update for other non-physics things and it makes me wonder if this is something that's do-able in a FSM system to that level.

Because I've been working on this and right now I've got quite a lot of actions in states and it all seems to be half-way there but I'm at a bit of a loss how to adapt the rest and knowing how to apply the standard coding methodology to a FSM system more closely I think might help me understand how I can improve my noding.

[Lane]

What exactly are you trying to do? Adapting some code is a bit vague to really point you in the right direction.

You can basically port just about anything over from a code driven game into something composed entirely in playmaker. The M2H Games examples that Jean ported might be helpful to look at for example.

Are you trying to code some custom actions?

[Red]

Actually, I'm mainly trying to keep a system tight when manipulating the physics... I'm trying to basically make a side-scrolling platformer controller with tight and responsive controls like Megaman-X. So, for this I'm working through the forces involved (since I'm not sure what other best practices are ideal for something like this.)

So, basically, if you've played MMx then you'll know how very tight and responsive the controls are... And in the case of the system I have now the jumping is accurate but it's very floaty and loose. That said, I kinda want to have the ability to restrict the movement while in the air (and I have a system already made up that will detect if it's grounded with raycasts so that I can also add in that "wobbling on the ledge" thing if the player is on the edge.)

So, understanding this a little better I think would certainly help me in that respect.

[Red]

To help clarify what I mean here... I'll give some more specifics.

See, right now I have a character that's being controlled with the velocity/physics systems... It's independantly controlled and it works nicely.

Next I have a camera system. This is where I think the issue is having a bit of trouble. So, I have it set up trying to match the system from Super Mario World... So, you have the camera stay still until you reach a certain point and then it lerps to a spot ahead of the player so that the character is framed just to the left if you're headed to the right. Thing is, if I tell it to only use the lerp then the camera jitters a bit because the position that it's supposed to move to is always updating (one unit ahead of the player as the player is running.)

Thing is, I tried using the move-to, the iTween and none of them were acceptable. Why I'm asking about the update/fixedUpdate things is that I suspect that if I were to make these actions fire off at the same rate that would smooth out the jerkiness of the lerp.

And since I'm using the physics for the character and understanding that the character is using the fixed update, if I could find a way to make the camera also use the fixed update (instead of just the next-frame-event like I have to at the moment) that I suspect would resolve it.