Mac OSX Variable Definitions set in Workspace/Room ignored

[tanukidreamz]

Hi there!

I'm finding if I set the variables through the variable definitions (either in the room editor or in a workspace) they are always ignored. By both parent and child.
Writing the code in the step/create event works fine. (But applies to all instances so defeats the purpose of this feature).

Trying to use the feature to change values per instance via the room editor - does nothing.
Also has no effect if I set it for a child object itself when the parent has variable definitions.

It's like the feature doesn't exist at all. Have done a full day of tests. No luck.

Has anyone got this working?

I'm on ver 2.3 and most recent runtime as of yesterday.

Any advice or sign posting greatly appreciated.

 

[tanukidreamz]

Also worth noting while the screen shot is using integer - I have also tried setting the exact type as variables used in my code (real for real, boolean for boolean etc - no difference)

 

[Nocturne]

I use this feature extensively in my current WIP and have found no issues with it... certainly nothing like you are describing. Are you ONLY initialising these variables in the Object Variables window? I ask, because those are parsed before the Create Event, so if you also have them in the Create Even, then they will be getting overwritten.

 

[tanukidreamz]

Thanks for the reply.

Nope, they're I have them in the initial parent object's create step, the code of works fine if I set things manually.


// create

charName = "Enemy";
hp = 1;
spd = 1;
atk = 1;

facingDir = 1;
i💩💩💩💩 = false;

z = 0;
zpush = 0;
zfloor = 0;

followdistance = 0;
moverandom = 0;
isflying = 0;
isBoss = 0;

alarm[11] = room_speed * random_range(1, 3); // alarm
max_dist = random_range(1, 100); // The distance from the instance to set the point to
var _randomdir = random(360); // Get a random direction for the point
xgoto = x + lengthdir_x(max_dist, _randomdir); // Set the point position
ygoto = y + lengthdir_y(max_dist, _randomdir);




I've tried the child with and without inheriting this create step (as wanted to test).
If I set / use any of the variables in any of the steps or child steps they work fine no errors when I type it in.

(I was just resizing the sprite for a boss, increasing the hp etc)
If I just set those in the child sprite and inherit everything else, the code works. But again it applies to all instances.

Just the variable definitions are always ignored regardless.

 

[Nocturne]

Hmmmmm... My current project was previously a 2.2.5 project that I have updated to 2.3. I wonder if that makes a difference (as I've seen a couple of other topics talking about issues with object variables but not had the probelms)...? Have you tried making a new project as a test and creating a couple of objects (parent and child objects) and then seeing if the issue persists? That said, I think it is still worth filing a bug with YoYo Games and including a YYZ of the project, since something is obviously not working correctly.

 

[tanukidreamz]

Good idea, thanks, I'll try that today - it's possibly worth mentioning also the scale / flip settings (that you can click when in the room editor for an instance) get ignored too. Co-ordinates are fine though.

 

[tanukidreamz]

You were dead right, it's because they're being overwritten by the create step.
So I either have to use the Variable Definitions then erase them from all of my create steps?

I can't use both systems?
If I don't create these variables in the create step - which some of my code needs it'll throw errors of looking for variables before they've been set.
It seems strange that this feature runs before the create step rather than overwriting the settings in it.

I've tested and I can instead set these in the creation code for the instance. And it works if I just type it manually.

Would have been nice to have this working in combination. Otherwise I'd have to refactor every objects step code for it to work. And manually create all those variables. And never be able to use them in the create step or they'll be over written.... I just can't get my head around the use of it if it doesn't override the info in the create step.

 

[tanukidreamz]

Thanks for the help by the way - I'm managing to at least progress with this game jam - by just using the creation code per instance for now.
Definitely need to research the variable definitions more - as it would be more convenient to see them there.

 

[Nocturne]

You were dead right, it's because they're being overwritten by the create step.

Ha! I love being right... Thanks for letting us know too!

So I either have to use the Variable Definitions then erase them from all of my create steps?

I can't use both systems?
If I don't create these variables in the create step - which some of my code needs it'll throw errors of looking for variables before they've been set.
It seems strange that this feature runs before the create step rather than overwriting the settings in it.

The system is correct and works as planned. Really, the whole idea of object variables is to use them in a parent-child hierarchy, and pretty much omit 90% of variables from the Create Event of the objects.

For example, in my game, I have a top level "init" parent that ALL objects in my game have as their parent (even the player). This object has a couple of create event variables that I use in all objects to control things like pausing the game and collisions. These don't need to be in the object variables as I want every instance to have them and won't need to ever modify them in the room editor. Then I have a couple of child objects of that parent, that are ALSO parent objects... These parents are for "solid" objects, "moving" platforms, "enemies" and "interaction" and have specific object variables that can be edited in the room editor and that are going to be used by all of the children objects. Then I have the final child object that has MORE object variables to control very specific things like attack patterns (enemies) or buttons and doors (interaction). Some of those are actually also parents, and add more variables!!!! By the time I get into the room editor and start placing instances, they can have anywhere from 4 - 5 to 15 - 20 variables in the object variables list. Do I use all of them? Nope! Or at least yes, but not in all the instances... each variable is for a specific thing, time or place.

Just to expand a little more, My enemy parent has about 12 variables in the object variables and ALL the code for the instance is in the Step event. And when I say ALL the code, I mean ALL the code for every movement type and situation. Now, some of the object variables are for setting horizontal or vertical speed, some are for setting whether to walk on platforms or float, some are for setting paths... What this means is that I can simply create a new enemy object, give it a sprite, and then drop it into the room, and then set the instance variables to modify the behaviour of the enemy in the room editor and without touching the code! This takes a bit of initial setting up, but then makes level design a LOT easier, especially if you are working in a team. You can have your programmer set everything up then have your level designer use all the variables to create levels, and neither really needs to know anything about what the other is doing.

In this context it makes sense to not use the create event except for things that won't need to be edited in the room editor. If you're NOT planning on using multiple parents or editing objects in the room editor then stick with the create event.

 

[rIKmAN]

If I don't create these variables in the create step - which some of my code needs it'll throw errors of looking for variables before they've been set.

I'm not sure of the exact order they are run nor whether they are run per object or all in a batch, but as Nocturne says the Object Variables are parsed before the Create Event (which is why you see the Create Event overriding them), so I'm not sure how/why you are getting errors for variables not being set as they are actually being created earlier than would be in a Create Event.

Maybe it's some use I've not tried / encountered myself and I've done no testing.

in the create step

For clarity going forward, you should probably call it a Create Event because there is another event called the Step Event and so using "Create Step" might cause some confusion for people as to what event you are actually referring to when describing things or getting help and it's always best to try and be as unambiguous as possible.

 

[tanukidreamz]

Thank you! Will do.

 

[tanukidreamz]

Thank you for such an in depth explanation @Nocturne - really interesting.
It also really helped me work out how to approach this particular mechanic I'm working on (where a player or enemy is a mech composed of multiple objects at work as interchangeable limbs as well as whole). I've recoded it from the base up and is finally barebones working.

Would love to get more into initialising objects and constructors - am but a padwan early on the journey!

I'm doing a game jam at the moment and it's massively helped!