playMaker

Author Topic: Get/Set Actions and an "If Null" boolean  (Read 5567 times)

Murcho

  • 1.2 Beta
  • Junior Playmaker
  • *
  • Posts: 54
Get/Set Actions and an "If Null" boolean
« on: April 05, 2011, 11:04:12 PM »
I quite often find myself re-populating a variable with the same reference when looping through states.  While this isn't a major issue, it is a bit of a waste of processing time.  I use an Object Pool system, so these really don't need to be constantly updated.

I wanted to suggest a boolean be added to all the Get/Set variables actions, that reads something like "If Variable Is Null".  That way the action only gets called if the variable hasn't been populated with anything yet.


MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: Get/Set Actions and an "If Null" boolean
« Reply #1 on: April 06, 2011, 04:09:41 PM »
I'm not sure I follow you. Why don't you use a state (I call it "initialize") just to populate the variables, which is executed only once right after 'start'? Checking if it's null doesn't seem like it would work if you actually assign useful starting values to those variables anyways - which you should, imo.
--
Breno "MaDDoX" Azevedo
@brenoazevedo

Murcho

  • 1.2 Beta
  • Junior Playmaker
  • *
  • Posts: 54
Re: Get/Set Actions and an "If Null" boolean
« Reply #2 on: April 06, 2011, 09:13:57 PM »
I do set these up in an init state usually, however I'm using an object pooling system where prefabs don't actually get destroyed, just deactivated, then when they are re-activated the START global event is called on them again.  In this case, the variable is already populated, so retrieving and storing the variable again isn't required.


MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: Get/Set Actions and an "If Null" boolean
« Reply #3 on: April 11, 2011, 08:06:23 AM »
I do set these up in an init state usually, however I'm using an object pooling system where prefabs don't actually get destroyed, just deactivated, then when they are re-activated the START global event is called on them again.  In this case, the variable is already populated, so retrieving and storing the variable again isn't required.
Since variables aren't reset when enabling/disabling objects, you could check against a "started" boolean in the starting state and only if true you'd go to the "initialize" state. The descendant for both states, once finished, would be the same.
--
Breno "MaDDoX" Azevedo
@brenoazevedo