Legacy GM [Solved] Is it wise to use "undefined" to check if object is using a set of scripts

W

Wayfarer

Guest
Edit: Nevermind, I think I'm overthinking this. It's probably better not to use undefined :D

Original Post
There are probably better terms to explain what I'm saying but basically I'm asking this...

1. Say you have various wall objects (all using the same wall parent)
2. Then you have a set of scripts called "grassFX" which contains "grassFX_createEvent" and "grassFX_drawEvent". The point of "grassFX" is to add grass only to walls that you would like to add grass to. So "grassFX" is like its own module (is module the right word?).

I'm aware you could do this by simply having a variable in the parent object like "grassFX_enabled" and then only activating those scripts when that is true. Well, this is what I'm doing currently. But then I had started to wonder if you could keep the "grassFX" module entirely independent to the wall object, and if you wanted to check if a wall was using "grassFX" you could simple check something like "if (wall.grassFX != undefined)". Are there any downsides to this approach?

Hopefully I've explained this clearly. I'm mainly asking this because I just want to check if there is anything that is inefficient or not recommended about this technique.
 
Last edited:

Simon Gust

Member
Doesn't work unfortunately. (does in gms2)
What you could do is having a seperate child object that doesn't fit the requirements
You could then in your parent check for the correct object index
Code:
switch (object_index)
{
 case grassFX: scr_grassFX(); break;
 case notSoGrassFX: break;
}
 
W

Wayfarer

Guest
Is using undefined in such a way a reasonable approach?
 
W

Wayfarer

Guest
My thought process was somewhat like this...

pWall is the parent.

pWall --> all logic of pWall is one way
It isn't aware of any of the modules attached to its children.

That way it's not cluttered with anything and everything.

When the player object lands on a wall instance, it can simply check if "wall.grassFX != undefined" and if so, run the grassFX_collision script which throws up grass particles.

It has the extra benefit of making the wall object easily re-usable in other games without taking everything else with it!
 

Yal

šŸ§ *penguin noises*
GMC Elder
I usually define a "NONE" macro that's a constant value I'll never use as an index (a special negative value that's easy to identify like -1234), and have parent objects define default values for every variable their children may have (usually set to NONE, or true/false for boolean stuff like whether the object is destructible). All child objects call event_inherited() in their create event before doing anything else, so they inherit the variables and the default values for everything, then they can manually override them if needed (e.g. to use a non-default value). When I interact with any child of these parents, I know they have the variables. If I ever need to add a new variable I didn't think of when making the parent, I can just add it in the parent and in the child needing it, and all other children will also get it via the inheritance.
 
W

Wayfarer

Guest
That makes sense and is similar-ish to what I usually do except I often just have a variable like "grassFX_enabled = true". The "NONE" macro does sound useful though!

Edit: After thinking about this more, I'm going to just leave it how I had it. I've probably been overthinking this. :D
 
Last edited:
Top