Question regarding Object Order and script_execute in GMS 2.3

Akhos

Member
(I'm not currently in the beta so I thought I'd pose the question here, hopefully someone can help me before the official release!)

So in my current project (a fighting game), I have the ability to save replays and play them back. I have a fast forward feature that lets you play through the replay faster which works by just executing all of the step events of each object in the room multiple times in a single event before going through the events normally. To ensure this works the same as the game just playing through things normally, I have to know what order the objects are going to be executed in. Fortunately right now in 2.2, the order of code execution is the same as the order you have your objects arranged in the resource tree, and multiple objects are executed in their spawn order. So if I have:

obj_fighter
obj_projectile
obj_effects

The code will be executed in that order, and in my room controller, I can just do event_perform using with statements in that same order to achieve the fast-forward effect that I need. This is also used for the netcode (in the future, haven't gotten that far), when the game needs to roll back to a previous state and play it back, I'll need to do the same thing to ensure things would be played back exactly as if it had played through those events normally, I can't just fast-forward by doubling animation/move speeds.

With the new asset browser and being able to organize any asset regardless of type, does this same order of execution still apply? For example, if I kept all of my objects in their own object folder and kept them in the above order, would the code still be executed in that order in-game?


Now for script_execute. Reading through the 2.3 blogs, I see that scripts have been changed in order to support functions. In my game currently, each character has a ton of scripts assigned to them, and I store the script names in ds_list to be easily accessed later. As a short example:

GML:
ds_list_add(script_list,scr_rock_stand_hit_high_light);
ds_list_add(script_list,scr_rock_stand_hit_high_medium);
ds_list_add(script_list,scr_rock_stand_hit_high_heavy);
So it adds the script index to the ds_list. So for example, when I define an attack script for a character, I have which animation state the opponent plays when struck assigned to a number. So, say, hitbox_state[0]=33, references item 33 in the ds_list, which is stand_hit_high_light. So when a character is struck, it will set their script_index to 33, which will play that script for them getting hit. This allows me to just assign a single value that applies to every character, instead of having to have a massive switch statement any time a damage animation needs to be played and have to update all those switch statements any time a new character is added.

My question (I hope the explanation of how it currently works is clear); would this still work in GMS2.3? Or will I need to rewrite it all to use the new functions? In theory, using functions would make my current method a lot more convenient (IE have one script that defines all the damage functions for a character, and instead of assigning a script_index I assign the function name), but it would be nice to not have to rewrite everything with this new version.

Note; I can't really stick with GMS2.2 on this one. I want to use the YYC compiler so the game runs the best, but there's currently a bug where any call to the hat functions for gamepads returns undefined if you do that. So I need to know if I'd need to change how I handle things in 2.3, which I believe has fixed that issue.
 

TsukaYuriko

☄️
Forum Staff
Moderator
The event order is not something you should rely on; the manual is very clear about this.
When considering Events in GameMaker Studio 2, it should be noted that the exact order that the events are going to occur in each step cannot be clearly stated, simply because it depends on the internal workings of GameMaker Studio 2 and this is subject to change as the software develops.
Stuff being executed based on the object order is also an undocumented quirk which, for the same reason, is not something you should rely on.

If you need things to execute in a specified order, you'll have to rearrange your setup, as your current one may break at any time.


script_execute is another story. Upon import to 2.3, scripts will be converted to the new format, wherein a function of the same name as the script's name is defined. You can use this function in conjunction with script_execute the same way you have been until now. Since the name is the same, nothing about the code where you call the function will change.
 

Akhos

Member
If you need things to execute in a specified order, you'll have to rearrange your setup, as your current one may break at any time.
Ah...I would miss something that basic. My bad.

Guess I'll go with my backup plan after all and just change all the step events to user events, and have my controller execute those events for each object in whatever order I need them. Probably should have gone with that in the first place, but got a bit too lazy. Live and learn I suppose~

script_execute is another story. Upon import to 2.3, scripts will be converted to the new format, wherein a function of the same name as the script's name is defined. You can use this function in conjunction with script_execute the same way you have been until now. Since the name is the same, nothing about the code where you call the function will change.
Awesome! That's a relief.

Thanks for the quick response, that helps a lot.
 

kburkhart84

Firehammer Games
They are supposedly deprecating script_execute. It still works in the beta, but if your system is something you are going to be using for a long time, I'd recommend you switch to calling functions directly instead. The way the new functions work though, you can easily replicate how script_execute used to work. You can still pass around the functions and then execute the functions somewhere else accordingly. In my easing system, I have 31 ease types. The equations for those are in an array of functions. When you request an easing, you supply it a constant(I'm using macros for this). Then, it indexes the array to call whichever function you are requesting. I'm not having to go through a switch statement to handle this. I can also copy those variables around just like other ones and it simply copies a reference to the function, just like when you were copying the scripts around by name and using script_execute.
 

TsukaYuriko

☄️
Forum Staff
Moderator
They are supposedly deprecating script_execute.
They are not. Not sure where you got this from, but the manual states the opposite. It is certainly recommended to use method binding, but script_execute is explicitly not deprecated.

While this function is designed primarily for legacy support - and you are recommended to use the method() function for newer projects - it is not deprecated as it still has it's place in networking and remote procedure call situations. It is also worth noting that this function is slow, and using it a lot may adversely affect performance.
 

kburkhart84

Firehammer Games
I had made a post in the beta forum about it here. I noticed that script_execute() was working the same as before in my specific project, so I questioned if it was getting deprecated since I had expected the compatibility stuff to maybe change it to a direct script call or something. I won't post the whole thing here, as I specifically questioned what they were doing with the docs and they said they needed to update those as well. But the more relevant response is below.
Hello Kenneth,


Thank you for your post.


New information about the function can be found in the Manual page "script_execute(Legacy)" which states, at the top of the page:


"IMPORTANT! This function is provided for support of legacy projects created before the introduction of user-defined functions, and as such should not be used in any new projects."


Hope that answered your question about the documentation.


I'll go ahead and mark this thread as Answered.


Thanks again,


Alice
It seems that Yoyo people are not on the same page, they haven't updated the docs to reflect their final decision on this, or they simply haven't fully decided internally what they are going to do with it.
 

Akhos

Member
Should be easy enough to make the switch to functions (albeit a tad time consuming, switching the script references around), but as long as script_execute still works for now when the full release drops, I should be good to go for a while.
 
Top