GMS 2 Send variable 'link' to script

Is it possible to send a variable to a script for direct writing? I don't mean send the value, modify the value, return the value. I mean send the script something so it knows what variable to update. In other words I want a script to do something based on the values it has been given and directly modify the variable that has been requested.

I do not know what the requesting variable name will be beyond what the script has been passed.

Note: I did not want the script to assume what the variable name will be.

Update this variable with the calculated result. Not get the result and update it manually with the result or just knowing what the variable is beforehand.

Update variable "abc" with input data xyz. 'abc' will equal xyz without returning the value.

This is a hard one to explain I hope someone can explain.


Forum Staff
This is not recommended. Input arguments should not be modified by the functions they are passed to. This is what return values are for.

If you decide to do this against better judgment, you can pass the variable name as a string and use variable_instance_set.
I see what you mean. No that screams fudge. The reason I want to do it is that I have several objects of all different kinds with very different functions.

What they have in common is an x and y offset and expand horizontal, vertical, and diagonal.

I have a grid and a number of different buttons sets. It's difficult to do the tell without the show.

I wanted to keep my naming convention consistent and easy to identify. I have two objects, for example, one with grid_x_offset and another with palette_x_offset (palette is a parent of lots of other button sets)
the problem is they have basically the same code except that they have differently named variables for the offset. I do it like this so that when I access them externally I know that grid offset is the grid and not a palette child or something else.

I could just name them all the same as current_x_offset but I use current_ for temporary stuff.

Ahh this is so hard to explain.

Edit: I will try to calm down a little. There are a million ways to do things I just don't want to get it wrong. As much as abstraction makes life easier it does disturb my spirit somewhat. :(
Last edited:


Another option is to put the values in global space, then give each object a user event that copies those values into the appropriate instance variables.
That basically what I wanted to avoid. It would make sense for my project but I like to keep objects as self-evident and self-contained as possible. Maybe I shouldn't be striving for that. I seem to go through these self-hatred cycles and end up recoding things unnecessarily.


Anything that works off IDs (e.g. data structures, buffers, etc.) and arrays support pass by reference. When GMS 2.3 comes out, structs will also pass by reference, and even object instances can implement their own methods.


Either every object has to know how to manage itself, or some controller has to know how to manage every object. I don't think there's any other solution, and I don't know how that fails in any way to be less "self-contained" than "something knows what variable names to pass into a script that just puts values into places". That's messy, clunky, non-object-oriented, and basically looking for the hardest possible way to do things, as far as I can tell. It's the kind of programming exercise a professor might assign just so that the lesson can be "now that you know why it's a bad idea... never do this again".
Thank you. I never actually 'did it' before but I was very close to doing it. I think I should trust my intuition more. There comes a point where things get worse not better.
I think your quest for neatness is interfering with the actual computer science that is going on. Use the solution that is best for the problem, not "think of what you, as a human, consider a neat solution and then try to come up with a convoluted method to achieve that result".
I agree with you but the computer 'science' gets fuzzy when you have a black box. But you are right I need to adapt my attitude somewhat to gear it towards modern platforms. Otherwise it's just like 'why don't you program in assembly for an x86. I do agree logically. My heart just says no. I have to get over this.