playMaker

Author Topic: Read Game Object  (Read 7106 times)

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Read Game Object
« on: April 28, 2011, 12:28:52 PM »
Why having a different kind of "Get FSM Game Object"? The point is, right now we don't have global variables, nor the ability to duplicate actions, so if you initialize your local variables with content placed elsewhere (quite a common approach to keep things organized) you're in for a lot of legwork simply to initialize your variables. You have to drag and drop the object that contains the source FSM, then select the FSM (if there's more than one, also far from uncommon) then select the source variable then the destination variable. That, per action.

So I decided I could do something to smooth up this process a little. 'Read Game Object' finds the source game object per name (meaning you can copy+paste it), same for the FSM name, then all you have to do is select the local variable. As long as there's a same-named variable in the source FSM, the content will be copied over.



To change the handy default source strings, besides the manual paste/typing method you have two options:

1) Edit the .cs file and change the strings in the "Reset" section (I've set it for the naming convention that I use):
Code: [Select]
       public override void Reset()
        {
            objectName = "_ GameFSMs _";
            fsmName = "fsmPrototypes";
        }

2) To make it "drag and droppy", simply use a variable. You can start the state/FSM with a "Get Name" action and assign the desired object name to a string variable which will be used for all following "Read Game Object" actions.

I imagine this will get deprecated as soon as Global Variables are introduced, but meanwhile I found it quite handy, hope you find it of use as well.

PS.: I'll be posting "Read" actions for other variable types as I need/make them
« Last Edit: April 29, 2011, 11:21:26 AM by MaDDoX »
--
Breno "MaDDoX" Azevedo
@brenoazevedo

tobbeo

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 186
Re: Read Game Object
« Reply #1 on: April 28, 2011, 04:25:42 PM »
Funny I was just dealing with this issue yesterday, albeit with Get FSM Bool in my case. A similar action for Bool would have saved me time, although it wasn't too bad. I think this is an issue that needs to be addressed by Huttong. Like you said, we need something like global variables though I don't know if that has any impact on performance? I guess it shouldn't.

Thank you for your action!

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: Read Game Object
« Reply #2 on: April 29, 2011, 11:32:32 AM »
NP :) Like I said, I've done the "Read Int" and "Read Float" (curiously no Read Bool yet heh) yesterday and will post in other threads. I've also made a small improvement to this one and reattached it.

As for your comment, bear in mind that global variables can easily break your code if not properly handled, so I might keep using these "Read" methods even when Global vars are included. In any case, I'm making a more detailed post about how I think things should work for global vars in Playmaker, I'll post it on the feature requests section.
--
Breno "MaDDoX" Azevedo
@brenoazevedo

qholmes

  • 1.2 Beta
  • Hero Member
  • *
  • Posts: 509
Re: Read Game Object
« Reply #3 on: July 18, 2011, 05:41:00 PM »
I think i want to use this group of actions you have created.. But i am not quite sure what exactly they are doing? I know that sounds strange but i cant quite follow what is going on with your description..

What i was thinking it was doing was you could get a variable from any FSM or game object as it would search for them and come back with the proper game object and then read the variable from it? Seemed like a good idea but i really dont know if that is what it does?

Can you clarify it for me?

Q

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: Read Game Object
« Reply #4 on: July 21, 2011, 12:10:52 PM »
Sure, here's an example on how to use them: Suppose you have a "playerLives" integer variable in an FSM called "gameData", and you want to copy its value to the current FSM.

1 - create a same-named "playerLives" variable in the receiving FSM
2 - add a "Read Int" action to the intended state
3 - select the playerLives variable.
4 - Done!

Basically what it does is copying the value of a remote variable, to a variable of the same type and name in this FSM. Did that make it clearer?

PS.: Thankfully those will soon be a thing of the past with the new Global Variables option in PlayMaker - yay! :D
--
Breno "MaDDoX" Azevedo
@brenoazevedo

qholmes

  • 1.2 Beta
  • Hero Member
  • *
  • Posts: 509
Re: Read Game Object
« Reply #5 on: July 21, 2011, 12:14:56 PM »
Cool.... but do you still have to specify the other game object?

Heheh yes 1.2 will change quite a few things.. Already loving it.

Oh and thanks!!!!

Q
« Last Edit: July 21, 2011, 12:17:27 PM by qholmes »

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: Read Game Object
« Reply #6 on: July 22, 2011, 11:11:04 AM »
Cool.... but do you still have to specify the other game object?
It's a string field exactly to facilitate that process, if you always use the same source gameObject (like I do) simply edit the _ GameFSMs _ string in the source c# file:

objectName = "_ GameFSMs _";

change it to whatever gameObject name you'll use, so that all you have to do is drag-and-drop the action and select the local variable.

Oh.. and you're welcome :)
--
Breno "MaDDoX" Azevedo
@brenoazevedo