SOLVED Best way to change a value of a ds_grid accessor assigned to a instance variables

flyinian

Member
Is this a good way to add to a grid?

GML:
if(mouse_check_button(mb_left) && position_meeting(mouse_x,mouse_y,_Object))
{



var increase = ds_grid_get(gridname,1, 1);
increase += 10;
ds_grid_set(gridname,1, 1, increase);



};
 
It's a way, that's for sure. Personally, I'd do this:
Code:
if(mouse_check_button(mb_left) && position_meeting(mouse_x,mouse_y,_Object))
{
   gridname[# 1,1] += 10;
}
# is what's called an accessor. It allows you to directly access the grid value at the position you provide immediately after (1,1). You can both read and write using it. There's a multitude of other accessors, here's a little rundown:
Code:
list_name[| 0] = 1; // Set position 0 in a list to 1, using the | accessor (shift+backslash)
map_name[? "my_key"] = 0; // Set the "my_key" map entry to 0 with ? accessor
my_array[@ 1] = 10; /* This directly sets position 1 in my_array to 10, you don't necessarily need this unless you have done something like provide an array as an argument in a script and then want to change the original array without having to return it from the script. */
Further reading: https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml language overview/accessors.html
 

flyinian

Member
It's a way, that's for sure. Personally, I'd do this:
Code:
if(mouse_check_button(mb_left) && position_meeting(mouse_x,mouse_y,_Object))
{
   gridname[# 1,1] += 10;
}
# is what's called an accessor. It allows you to directly access the grid value at the position you provide immediately after (1,1). You can both read and write using it. There's a multitude of other accessors, here's a little rundown:
Code:
list_name[| 0] = 1; // Set position 0 in a list to 1, using the | accessor (shift+backslash)
map_name[? "my_key"] = 0; // Set the "my_key" map entry to 0 with ? accessor
my_array[@ 1] = 10; /* This directly sets position 1 in my_array to 10, you don't necessarily need this unless you have done something like provide an array as an argument in a script and then want to change the original array without having to return it from the script. */
Further reading: https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml language overview/accessors.html
I knew about the accessors, but didn't have much luck with them in the past.

Are there any downsides to using accessors?

I'm guessing they have the same functionalities as a variable?
 
The functionality of an accessor and the function calls (ds_grid_get/set) is exactly the same. In fact, the only time I ever use the built-in functions for lists is when I'm adding an item to a list and haven't bothered to keep track of the list size. Any other time I'm going to be using accessors and if I'm using something other than a list, I'm pretty sure I always use the accessor version. It's way quicker to type, it reads easier (the thing you are accessing is the very first thing you start reading, instead of reading through "ds_grid_set" or "ds_map_add" or whatever the function name is), it lets you do more with less (hence why I could cut your three line statement down to one line), just all around better, there is no downsides to using accessors that aren't present in the function calls themselves.
 

flyinian

Member
The functionality of an accessor and the function calls (ds_grid_get/set) is exactly the same. In fact, the only time I ever use the built-in functions for lists is when I'm adding an item to a list and haven't bothered to keep track of the list size. Any other time I'm going to be using accessors and if I'm using something other than a list, I'm pretty sure I always use the accessor version. It's way quicker to type, it reads easier (the thing you are accessing is the very first thing you start reading, instead of reading through "ds_grid_set" or "ds_map_add" or whatever the function name is), it lets you do more with less (hence why I could cut your three line statement down to one line), just all around better, there is no downsides to using accessors that aren't present in the function calls themselves.

Thank You, I'll give accessors another try.
 

flyinian

Member
The functionality of an accessor and the function calls (ds_grid_get/set) is exactly the same. In fact, the only time I ever use the built-in functions for lists is when I'm adding an item to a list and haven't bothered to keep track of the list size. Any other time I'm going to be using accessors and if I'm using something other than a list, I'm pretty sure I always use the accessor version. It's way quicker to type, it reads easier (the thing you are accessing is the very first thing you start reading, instead of reading through "ds_grid_set" or "ds_map_add" or whatever the function name is), it lets you do more with less (hence why I could cut your three line statement down to one line), just all around better, there is no downsides to using accessors that aren't present in the function calls themselves.
I tried the accessors again and found that you cant assign a ds_grid accessor to a instance variable.

Is there a work around for this?
 
Yes, you can't assign something like my_grid[# 1,0] to a variable (i.e. my_variable = my_grid[# 1,0] only contains my_grid[# 1,0] in the frame that it is called).

A possible workaround is something like this:
Create Event:
Code:
my_workaround_x = 1;
my_workaround_y = 0;
Step Event:
Code:
my_variable = my_grid[# my_workaround_x, my_workaround_y];
Now my_variable is always equal to my_grid[# 1,0] but if you want to check another x position in the grid, just reassign my_workaround_x to that x and my_variable will equal that, obviously the same is true for my_workaround_y.

NOTE: This is true for both the function calls and the accessors, so don't think of this as a weakness in accessors. Rather a particular way that GML works.
 

flyinian

Member
Yes, you can't assign something like my_grid[# 1,0] to a variable (i.e. my_variable = my_grid[# 1,0] only contains my_grid[# 1,0] in the frame that it is called).

A possible workaround is something like this:
Create Event:
Code:
my_workaround_x = 1;
my_workaround_y = 0;
Step Event:
Code:
my_variable = my_grid[# my_workaround_x, my_workaround_y];
Now my_variable is always equal to my_grid[# 1,0] but if you want to check another x position in the grid, just reassign my_workaround_x to that x and my_variable will equal that, obviously the same is true for my_workaround_y.
Thank You, i'll give this a try.
 

flyinian

Member
Yes, you can't assign something like my_grid[# 1,0] to a variable (i.e. my_variable = my_grid[# 1,0] only contains my_grid[# 1,0] in the frame that it is called).

A possible workaround is something like this:
Create Event:
Code:
my_workaround_x = 1;
my_workaround_y = 0;
Step Event:
Code:
my_variable = my_grid[# my_workaround_x, my_workaround_y];
Now my_variable is always equal to my_grid[# 1,0] but if you want to check another x position in the grid, just reassign my_workaround_x to that x and my_variable will equal that, obviously the same is true for my_workaround_y.

NOTE: This is true for both the function calls and the accessors, so don't think of this as a weakness in accessors. Rather a particular way that GML works.
I couldn't get it to work. Atleast for what I was trying to do.


What I'm trying to do:

GML:
// Creat event

_Addto = ds_grid[# 1,1];


// step event

if(something)
{

_Addto += 10;    // adding this value to the already existing value of ds_grid[# 1,1]

};

I may just avoid the instance variable and inherit the parent event for a work around.
 
I mean, I literally said that you can't assign a changing value to a variable without consistently changing the value in the Step Event. I really like the posts of yours where I've seen a little dismissal coming from the question answerers and you've taken it well, so I'm not getting frustrated at you. But basically you cannot assign a changing value at a single point (where the Create Event runs literally once and that is it, never getting updated) and expect that value to change later on. The only change you need to make is this:
Code:
_Addto = ds_grid[# 1,1];
if(something)
{

_Addto += 10;    // adding this value to the already existing value of ds_grid[# 1,1]

};
Is ALL in the Step Event.

The Step Event runs once per frame, so if ds_grid[#1,1] changes, the Step Event assigns the new value to _Addto. If you don't need _Addto to be referenced from any other event (i.e. the Draw Event), I would recommend making it a local variable by prefacing it with var, but that is beyond the basic point of if you need a variable to "gather" new information as the game runs, it HAS to be in an event that runs each frame.
 

FrostyCat

Redemption Seeker
When you do this in the Create event:
GML:
_Addto = ds_grid[# 1,1];
You are NOT creating a link from _Addto to position (1, 1) in ds_grid. You are setting _Addto to the value at (1, 1) in ds_grid at that point in time. Referencing or setting _Addto later will not magically copy-and-paste ds_grid[# 1,1] there.

Don't try to be crafty here. Skip your _Addto linking attempt in the Create event, and just do this in your Step event code:
GML:
if(something)
{
    ds_grid[# 1, 1] += 10; // adding this value to the already existing value of ds_grid[# 1,1]
}
 

Nidoking

Member
Think of variables as students with miniature whiteboards, and think of assigning a value as asking the student to write that value on their whiteboard. You can give a student a complex problem, and they'll work it out and write the answer on their whiteboard. You're the teacher - you can look at any student's whiteboard at any time, although depending on where that student is, you may need to walk into a different room.

Now, what you're trying to do is ask one student to keep an eye on another student's whiteboard and remember not the value, but the whiteboard itself. GML doesn't let you do that. Your students get bored and will quickly lose interest in anything that isn't already in their hands. The student is just going to copy down whatever's on the whiteboard right now, then forget they ever saw a whiteboard that wasn't their own. If you want the second student's whiteboard to update regularly, you're going to have to tell that second student directly when you want them to write a new value. The Step Event is your friend. It is your teaching assistant, rapidly bouncing from student to student and reminding them to update their whiteboards while you attend to more important things.
 

flyinian

Member
@FrostyCat & @Nidoking

@RefresherTowel My last reply to you was for a visual representation of what I was trying to do before your assistance, I should of been more clear. Sorry for the confusion.

I think I understand now, Need to update the variable/ds_grid/etc. with the current data per step/before use.

Thank You for the replies.
 
Top