1176 replies to this topic

[Big J]

I know, I use it to. That's the type of code I was glancing at that made the idea pop into my head. But I was looking at it and went "This isn't very clear. with is telling me that this is happening to another object, yet it's... not." It would just be neat to have something similar, and more apparent of what it's actually doing. Not necessarily the exact idea I proposed.

Or heck, if you were to use an idea like that one, just limit the scope of with to only include the object in with and have some keyword for getting the calling object:

with (instance)
{
    caller.variable = 0;
}

Or whatever. Weird ideas for sure...

Another way to do that, without using "other", is this:

var me;
me = id;
with (instance)
{
    me.variable = 0;
}

I don't think a temporary variables counts as an instance variable. I don't know how you'd describe it, it's almost 'global', but only within a particular piece of code. (it ceases to exist outside that code/script, as you will know)

So using other.temp_variable doesn't make sense, because temporary variables don't *have* an instance they exist in.

This is my best guess. I should probably start testing around now, I'm relying on memory.. :tongue:

Yes, that is an accurate description. As I said in a previous post, temporary variables behave like global variables, except they are temporary.

Edited by Big J, 20 April 2012 - 03:30 AM.

[icuurd12b42]

Yes, that is an accurate description. As I said in a previous post, temporary variables behave like global variables, except they are temporary.

When I started GM I got really confused when people used the word local, in contradiction to the industry common lingo

I think the trouble stems from this text in the help

Like any programming language GML contains variables. Variables are memory locations that store information. They have a name so that you can refer to them. A variable in GML can store either a real number or a string. Variables do not need to be declared like in many other languages. There are a large number of built-in variables. Some are general, like mouse_x and mouse_y that indicate the current mouse position, while all others are local to the object instance for which we execute the program, like x and y that indicate the current position of the instance. A variable has a name that must start with a letter and can contain only letters, numbers, and the underscore symbol '_'. (The maximal length is 64 symbols.) When you use a new variable it is local to the current instance and is not known in programs for other instances (even of the same object). You can though refer to variables in other instances; see below.

On the GMC you find the term global to define global variables and local to define instance variables

The problem is that in the real world, Local is already taken to mean the type of variable you guys are talking here.

Here is the proper terminology for GM variables
local variable - a variable that has local scope. Exists only within the local context of the current script (var varname;)
global variable - a variable that has global scope. Exists throughout the program (mouse_x, mouse_x, global.varname, globalvar varname;)
object variable - a variable that has object scope. Exists in all instances of the object (x,y,image_alpha). You can assume variables created in the create event can be considered object variables, though they are not, but better to assume.
in some languages, like GM:
instance variable - a variable that has instance scope. Exists only for the instance. Omitting to define a variable as local (var) creates the variable at assignment time for that instance, be it in the create myVar = 10; or in a script for program flow for (i=0; i<10,i++). other.anotherVar creates yet another instance variable.

[NakedPaulToast]

The problem started because at one point there was only two types of variables global and local, the var keyword had not as yet been implemented. The manual consistently used local to refer to variables that had instance scope. Functions were created that entrenched the usage of local as the proper terminology for said variables.

• variable_local_set(name,value) Sets the local variable with the given name (a string) to the given value.
• variable_local_array_set(name,ind,value) Sets the index ind in the local array variable with the given name (a string) to the given value.
• variable_local_array2_set(name,ind1,ind2,value) Sets the index ind1,ind2 in the local 2-dimensional array variable with the given name (a string) to the given value.
• ...

When the var keyword to implement local script scope, was created the ambiguity of the meaning of local was created and the manual didn't address it. Within the documentation and function names instance variables were consistently referred as local variables.

This has been addressed in the Studio documentation and re-enforced with the removal of the variable_local functions.

Variables And Variable Scope

Like any programming language GML uses variables as the basic unit for most programming operations. Variables are used to store information in the devices memory for later (or instant) use, and they are given a name so that you can refer to them in functions and programs. A variable in GML can store either a real number (like 100, 2.456575, -56 etc...) or a string (like "Hello world!").

A variable is something that we use to store a value for use in one or more operations or functions. Think of "pi", for example... it is a real world variable that holds the value 3.14159265(etc...). Why? Well, it's much easier to say to someone "pi" than "three point one four one five nine two six five"! So, naming things make life a lot simpler and it also means that should the value of that variable ever change, we don't have to change the number everywhere as the variable name is still the same. In GML a variable has a name that must start with a letter and can contain only letters, numbers, and the underscore symbol '_' with a maximum length of 64 symbols. So, valid variables are things like fish, foo_bar, num1, and invalid variables would be 6fish, foo bar, or *num. Now, In many programing languages you need to "declare" a variable before you can use it. This basically means that you tell the computer the name you wish to use so that it can assign a place in memory to store whatever value you decide to hold in that variable. With GML, that is not always neccesary as it depends on the scope of the variable. There are four main variable categories when you program with GameMaker:Studio and each his it's own scope (which is can be considered as it's area of operation, or reach). These variables and their scope are outlined below :



instance : these are the most common variables and are defined within an instance. These are unique to that instance and can be used in any event and any function within that instance.

local : these variables must be declared using the "var" function. A local variable is only valid for the event or script resource in which it is created. So GameMaker:Studio will create the variable, use it for the duration of the event and then "forget" it again, meaning that if you try to use it later you will get an "unknown variable" error.

global : a global variable is one that belongs to the game world itself and not to any one instance. It has to be declared as global first, but after that any instance can check or change the variable and the value will always reflect the last operation done on it, no matter what instance or code box has performed the operation.

built in variables : these are special variables that are "built into" the objects and the rooms in the game world and they can be instance only or global in scope (but never local) .

object variable - a variable that has object scope. Exists in all instances of the object (x,y,image_alpha). You can assume variables created in the create event can be considered object variables, though they are not, but better to assume.
in some languages, like GM:
instance variable - a variable that has instance scope. Exists only for the instance. Omitting to define a variable as local (var) creates the variable at assignment time for that instance, be it in the create myVar = 10; or in a script for program flow for (i=0; i<10,i++). other.anotherVar creates yet another instance variable.

Creating a distinction between object and instance is silly. It is inconsistant with the documentation and will only contribute to more confusion to what has become ambigous terminology.

Proper terminolgy for GM is what is consistant to the documentation.

Edited by NakedPaulToast, 20 April 2012 - 05:40 PM.

[icuurd12b42]

Creating a distinction between object and instance is silly. It is inconsistant with the documentation and will only contribute to more confusion to what has become ambigous terminology.

Proper terminolgy for GM is what is consistant to the documentation.

Sorry, I did not know this was redone.

>>Creating a distinction between object and instance is silly
I was only using familiar terms of OOP; Object variable or Member Variable if you wish... which are basically what built in variables are now. By your words built in variables, which makes the distinction I made, is silly.

[NakedPaulToast]

Creating a distinction between object and instance is silly. It is inconsistant with the documentation and will only contribute to more confusion to what has become ambigous terminology.

Proper terminolgy for GM is what is consistant to the documentation.

Sorry, I did not know this was redone.

>>Creating a distinction between object and instance is silly
I was only using familiar terms of OOP; Object variable or Member Variable if you wish... which are basically what built in variables are now. By your words built in variables, which makes the distinction I made, is silly.

It's entirely possible the manual changes were implimented in today's update.

That Nocturne has been working his tail off updating it.

[icuurd12b42]

I know right!

[IKSB]

I didn't see another forum for this kind of topic. If I did miss it, then just move this there...


Two shortcomings in GM that keep coming up and bothering me are:
- Lack of control over tiles
- Inability to search game resources
- Changing parents

What I mean by this; TILES: Once you place a tile you cannot touch them aside from making a layer of tiles visible or not. I think it would be useful to expand upon this function by allowing you to control the blend, alpha, and depth of a layer. (If you were to change the layer into an already existing layer, then it would merge the two.) I think this would give much more control over the environment of a game.

RESOURCES: Whenever you try to import a resource package, it will check to make sure none of your assets have the same name. If two do have the same name, it refuses to tell you what the name of it is or which asset has the duplication. To remedy this you could have it just name it off, but I think it would be additionally helpful to have an asset search feature. I often find myself trying to find that one tiny object in a huge GM file and wasting time trying to find it.

PARENTS: Many times it is useful to have objects relate to each other by "class" which I execute by using parents. However, if I want to change the way objects react to each other, I cannot simply change the parent mid game (as far as I know). I don't know if this is possible, but I think it would be a good addition to have the ability to change an instance's parent.



These are just a small list of shortcomings in GM that aren't just a matter of my programming inability. My hope is that enough people feel the same way so that they are included in a future update.

Edited by IKSB, 22 April 2012 - 06:03 PM.

[Yal]

The keyword var in itself is a bit misleading, I've seen a bunch of newbie users trying to "declare" local variables with it and then they couldn't find the variables later because the variables ceased to exist after the Create Event. Also, since "global" refers to game world variables and "global" and "local" are counterparts in IRL context, I think most people refer to instance variables when they use the term local - at least I do - and call a var variable for a "temporary variable" or a "var".

Also, the documentation doesn't mention that the temporary variables count as global variables (aka, can be referenced with with(){} statements) within the script they exist in, which could arise further confusion.

Finally, it would be nice with some documentation with what happens if multiple variable names overlap - for instance if you have an instance variable, then use globalvar to create a non-"global."-prefix global. variable with the same name, and finally make a temporary variable using var. Would the state of the variable change, or would you get 3 variables with the same name, and if the latter, how to address them differently? (Obviously you can solve this problem by just make sure you always name your variables different things)

[icuurd12b42]

The keyword var in itself is a bit misleading, I've seen a bunch of newbie users trying to "declare" local variables with it and then they couldn't find the variables later because the variables ceased to exist after the Create Event. Also, since "global" refers to game world variables and "global" and "local" are counterparts in IRL context, I think most people refer to instance variables when they use the term local - at least I do - and call a var variable for a "temporary variable" or a "var".

Also, the documentation doesn't mention that the temporary variables count as global variables (aka, can be referenced with with(){} statements) within the script they exist in, which could arise further confusion.

Finally, it would be nice with some documentation with what happens if multiple variable names overlap - for instance if you have an instance variable, then use globalvar to create a non-"global."-prefix global. variable with the same name, and finally make a temporary variable using var. Would the state of the variable change, or would you get 3 variables with the same name, and if the latter, how to address them differently? (Obviously you can solve this problem by just make sure you always name your variables different things)

previous page, bottom posts around 1144

the with statement changes context to an object (list of object instances actually) or a single instance, it is quite logical that in that context you can access the instance variables for each instance, the global variables and the variables created in the script. There no confusion for me, you just need to be a little more aware of the context you are in and the scope of the variables you are using.

The confusion can be limited by using prefix in your naming convention. in c++ I am used to m_ for m_Member variable and g_ prefix for globals...
on create
m_Name = ""

I got lazy myself over here over the years though and last week, I got burned
object create
name = "";

file loading
var name;
name = file_text_read_string(hf))
with(instance_create(x,y,object))
{
name = name; //oops (which name)
}

In c++ this would yield an error.

In gm, name declared with var is used. My instance had no name.

GM could verify the scope but this would need to be done at run time and would bring GM to a crawl

[IceMetalPunk]

The keyword var in itself is a bit misleading, I've seen a bunch of newbie users trying to "declare" local variables with it and then they couldn't find the variables later because the variables ceased to exist after the Create Event. Also, since "global" refers to game world variables and "global" and "local" are counterparts in IRL context, I think most people refer to instance variables when they use the term local - at least I do - and call a var variable for a "temporary variable" or a "var".

Also, the documentation doesn't mention that the temporary variables count as global variables (aka, can be referenced with with(){} statements) within the script they exist in, which could arise further confusion.

Finally, it would be nice with some documentation with what happens if multiple variable names overlap - for instance if you have an instance variable, then use globalvar to create a non-"global."-prefix global. variable with the same name, and finally make a temporary variable using var. Would the state of the variable change, or would you get 3 variables with the same name, and if the latter, how to address them differently? (Obviously you can solve this problem by just make sure you always name your variables different things)

The smallest scope is always used. Scope, from smallest to largest, is script-local -> instance-local -> global. So if a script-local variable with the given name exists, that will be used. If not, it will try to use an instance-local variable with the name. If that doesn't exist either, then it moves up to globalvar variables. Only after seeing that that also does not exist will GM throw an "unknown variable" error.

So, as icuurd12b42 said, as long as you're aware of the scope you're in, just remembering that the variables are taken from the smallest scope in which they exist solves any confusion.

-IMP

[GStick]

The confusion can be limited by using prefix in your naming convention. in c++ I am used to m_ for m_Member variable and g_ prefix for globals...
on create
m_Name = ""

I got lazy myself over here over the years though and last week, I got burned
object create
name = "";

file loading
var name;
name = file_text_read_string(hf))
with(instance_create(x,y,object))
{
name = name; //oops (which name)
}

Good point. Lately, I've been using naming like this:

_variableName = 0; // local
var variableName = 0; // temp
global.variableName = 0; // global
globalvar variable_name = 0; // global variables that are recognized as resources, like sounds or sprites
VARIABLE_NAME = 0; // constants

I wish GM would make local variables private though, with public properties (I've been using C# a lot lately... definitely preferring properties over get/set functions). I've also been trying out the concept of separate scripts for private vs public access with something like this:

ScriptName();
Public_ScriptName();

It's been making things a lot easier to keep track of. I know that any script not prefixed with Public_ that I create, with the exception of scripts in specific folders, are all meant to only be used within the object they appear in. Helps a lot. It's helped me eliminate silly all-purpose scripts.

[icuurd12b42]

...

Good but stop thinking of local and temp that way... The new help, as stated, reinforces proper terminology

_variableName = 0; // instance scope
var variableName = 0; // local scope
global.variableName = 0; // global scope
globalvar variable_name = 0; // global variables that are recognized as resources, like sounds or sprites
VARIABLE_NAME = 0; // constants

I may add, but it's up to you, in the industry, variables with a leading _ and __ tend to mean temp variables. temp variables are usually global variables (or in GM, instance variables) used to hold data that will be fetched readily... You can see where the use of the term temp variables on the GMC to mean var brings a whole lot of confusion for people coming in with prior experience there.

example c++

float __nz,__ny,__nz;

float normalize(float vx, float vy, float vz)
float d; d= sqrt(vx*vx + vy*vy + vz * vz);
__nx = vx/d;
__ny = vy/d;
__nz = vz/d;
return d;


normalize(100,200,300);
float nx = __nx;
float ny = __ny;
float nz = __nz;

It's a bad example, but it has a more pertinent use in GM and in languages that do not allow retuning multiple values via the arguments.

[GStick]

Well, I'm using the leading underscore as a by-product of prefixing member variables with 'm_' or just '_', and then using no leading underscore for variables used inside functions. I realize that, for example in C#, a lot of people are sticking to the standard and using the this. prefix but the only thing resembling it in GM is self. which I've never really seen anyone use to serve this purpose.

[icuurd12b42]

Well, I'm using the leading underscore as a by-product of prefixing member variables with 'm_' or just '_', and then using no leading underscore for variables used inside functions. I realize that, for example in C#, a lot of people are sticking to the standard and using the this. prefix but the only thing resembling it in GM is self. which I've never really seen anyone use to serve this purpose.

It's alright, pretty sure the _ thing is not universal though common in my region.

[Big J]

The smallest scope is always used. Scope, from smallest to largest, is script-local -> instance-local -> global.

The potential problem is that variables declared with globalvar override instance variables.

For example, objectA has this Create event:

value = 0;

This Step event:

value += 1;

Suddenly, objectB does this:

globalvar value;
value = 0;

Oops, now the Step event of objectA will forever increment the global value. I think self.value could solve that, but that's messy.

Of course, the ideal solution is to avoid using the same names for globalvar and instance variables in the first place.

Edited by Big J, 23 April 2012 - 10:17 PM.

[Desert Dog]

Of course, the ideal solution is to avoid using the same names for globalvar and instance variables in the first place.

I don't really understand why one needs to use globalvar, anyway. Although typing out global.everytime might be a little annoying, readability wise, it's worth it, surely.

[IceMetalPunk]

The smallest scope is always used. Scope, from smallest to largest, is script-local -> instance-local -> global.

The potential problem is that variables declared with globalvar override instance variables.

For example, objectA has this Create event:

value = 0;

This Step event:

value += 1;

Suddenly, objectB does this:

globalvar value;
value = 0;

Oops, now the Step event of objectA will forever increment the global value. I think self.value could solve that, but that's messy.

Of course, the ideal solution is to avoid using the same names for globalvar and instance variables in the first place.

Oh. Then the correct scope hierarchy is globalvar->var->instance-local->global. You can tell I don't ever use globalvar at all. Like Desert Dog, I prefer the global.variable syntax because it keeps global variables clearly in the global scope.

-IMP

[icuurd12b42]

Of course, the ideal solution is to avoid using the same names for globalvar and instance variables in the first place.

I don't really understand why one needs to use globalvar, anyway. Although typing out global.everytime might be a little annoying, readability wise, it's worth it, surely.

It's helpful in the case where you originally had an instance variable that now needs to be global. adding globalvar variable; allows the variable to be accessed remotely without the need to go though all the existing code that referenced the variable.

For example, I had a zoom variable in a particular instance with a lot of code associated with it. Then I started to need to use it everywhere external to the instance that created it and I did not want to switch context because from now on, that variable would be used intensively.

[time-killer-games]

-import multiple include files at once.
-select and delete multiple include files.
-select and delete multiple resources in the resource tree even if they aren't in a resource group.

[Magicnanners]

Please for the love of god move the drag and drop tabs from the side of the object creator to the top. It is so hard to read them without physically rotating my head.