playMaker

Author Topic: Action Malfunction [solved]  (Read 4499 times)

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 318
Action Malfunction [solved]
« on: July 07, 2011, 10:24:44 PM »
I'm having a hard time figuring this issue out.  

I have an object in my scene that tracks the player.  It has two states: moveToPlayer, and atPlayer.  It is designed to move toward the player when over a specified distance away, and when it's within the specified distance it waits.  When the player moves out of range it returns to it's moveToPlayer state and tracks it until its within range again.

The issue seems to be that it just decides to stop using the Move Towards action randomly.  I have no idea why this is, but at some point it will be in the moveToPlayer state, and the Move Towards action will grey out, and while the debug info clearly notes that it's out of range from the player (and should be moving toward it in this state), it no longer moves.

Here is an image of the two states along with their specified actions:


You will notice that the Target Object in both states is set to a gameobject variable known as "activePlayer".  My first thought was that this variable was being changed to something else, but this is not the case, (which means don't look there, it's not the answer).

The only other hypothesis I have is this: I set the speed at which the tracking object travels to the target object via a distance variable.  I believe it's possible that at some point the target object will be at a distance of 0 to the player, and thus set the Max Speed variable of the Move Towards action becomes 0.  The issue with this is that I have NO IDEA why this would "shut off" the action itself.

EDIT: I just tested this theory, it was not correct.  The action "shuts off" when the target object is well away from the tracking object.  Oh well!

Any help is much appreciated!  Thanks in advance.

« Last Edit: July 16, 2011, 11:19:21 PM by artician »

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 318
Re: Action Malfunction
« Reply #1 on: July 08, 2011, 10:18:13 PM »
I think this issue is a good example of my ignorance about how this system really works.  I hope someone can answer this one for me.

I do not understand what causes the greyed out actions.  Here is an example:



This is a simple state that I am using to scale down a block in my scene until it's at a specified size that it will trigger the second state to Destroy Self.  Two states for this, and that's it.  When I play my scene with this object, the top-most action "Animate Float V2" is greyed out. 

Understanding that I have no idea what causes this to begin with, I have tried several configurations of these states to see what will cause it to activate.  If I loop the state back on itself (through the FINISH event that I'm calling in the Float Compare action), it's a massive performance hit that acts like an infinite loop.

If I leave the state alone to sort itself out, there is no change, and only the Set Scale and Float Compare actions are active.

Sorry for more of my forum-spam-of-ignorance, but please let me know if you can explain this to me so I can put it behind me once and for all.

Thank you.



justifun

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 280
Re: Action Malfunction
« Reply #2 on: July 14, 2011, 07:57:42 PM »
For one thing your "time" field in the animation curve float" is set to none, so its not going to scale over any amount of time, that could be why.  It fires off (possibly over zero seconds) and since its complete, it goes grey.  Or it goes grey because it doesnt like being set to None.

"Time" is how long in seconds its going to take it to progress through your animation float curve.

You might want to slow down "speed" as well. 

Speed is usually a default of 1 which represents playing your animation curve at 100% speed.  By cranking it up to 128, you are asking your animation float curve to play 128 times faster than however long you set it in the curve window.

« Last Edit: July 14, 2011, 08:04:04 PM by justifun »

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 318
Re: Action Malfunction
« Reply #3 on: July 16, 2011, 10:22:39 PM »
Thanks for taking a look.  I figured the second case out.  I thought Time was an optional field, when it was Speed that didn't need to be set.  

Do you have an opinion on the first case?  I still can't solve this issue.  The only thing that changes is that the "activePlayer" variable gets changed, but I can see in the debug info that its still targetting the correct object.  For some reason, it seems around when it hits the Finish Distance value of the Move Towards action, the Move Towards action just greys out.  It does not do this when the regular player object is set.  There aren't any changes happening though.

I can try to give more information if it will help.  I really can't get this one.  It's the second issue I've stumbled on where it feels like a bug in Unity or PlayMaker, but I make enough mistakes due to my own ignorance I can't be sure.

It's also probably worth mentioning that the Action will reactivate itself for an unknown reason.  Seemingly randomly.

Thanks for reading.
« Last Edit: July 16, 2011, 10:42:07 PM by artician »

justifun

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 280
Re: Action Malfunction
« Reply #4 on: July 16, 2011, 11:09:22 PM »
The problem you are having with the first one not picking up the "move towards" action a second time, is cause you are setting its target position to a Y value of 1, and it eventually gets there, then stops since its achieved its goal.  Try setting the target to "none" instead of specifying a value.  My guess is since you've specified a value its taking priority over the target object choice.

I put together a test scene with the same setup and that's the result i got.


artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 318
Re: Action Malfunction
« Reply #5 on: July 16, 2011, 11:19:05 PM »
That was it!  Why?! 

So odd.  At least you've given me another place to look.  I don't know why it does this to one player object and not the other though. 

Thank you again!