GMLscripts.com

Whoa! I'll have to think about this.

Oh, whoops. I missed the array. Hmmm, that's unfortunate. Checking if it is an array first might be the way to go. If it is, ignore the given type. That needs some testing because GameMaker always finds a way to make things weirdly difficult. Such a shame Mark Overmars didn't design the data structure system with unique indices mapped to types.

I'm adding this here for my notes. Passing 0 (zero) could mean array but that shouldn't be relied on since these constants could conceivably change.

Expand// data structure constant values
// ds_type_map      == 1
// ds_type_list     == 2
// ds_type_stack    == 3
// ds_type_queue    == 4
// ds_type_grid     == 5
// ds_type_priority == 6

Also considered rearranging the parameters, making type the final parameter and optional, defaulting to array if not given but I'm not sure I like it aesthetically.

Thanks. After looking into this issue some I think this is probably the best way to go. I will be making some very minor tweaks but it will function the same.

Thanks, Juju.

Whoa! Real works on hex now. When did that happen?

This:

Expandfunction buffer_read_sha1()
{
    var _buffer = argument[0];
    var _lower  = ((argument_count > 1) && (argument[1] != undefined))? argument[1] : true;

...can be this very soon:

Expandfunction buffer_read_sha1(_buffer, _lower=true)
{

Any thoughts about that? As soon as the current Beta moves to Stable I'm thinking this is way forward here. Unfortunately, this breaks with outdated Runtimes.

That's an interesting observation. Also, calling this a point, which strictly speaking has no length, area, or volume, is a bit weird. But I can see the practical utility of it. I'll need to think about this.

Apologies for the late reply.

Very interesting idea for a script. All the string manipulation makes it a lot slower than it could be. I might make some changes to improve that.

It also looks like you've found a bug in the forum's image tag parser. I'll have to look into that.

I'll have to study this and see how it may improve on this existing script with a worse name:

https://www.gmlscripts.com/script/range_finder

Thanks for the submission and welcome to the forum. I'm somewhat surprised this doesn't already exist here. Perhaps someone else has submitted something like this in the past but it was never added.

I would make some changes to this. I don't feel it quite does what it suggests. It actually inserts the first list into the second list, changing it. That could be useful but that's an important side-effect. Also, the list that is returned is inconsistent. Usually, it's the second list but sometimes it's the first. It makes some sense but it doesn't sit right with me.

In general, I think it would be more useful, more predictable, and less dangerous if the script/function returns an entirely new list. Let the user decided what to do with the original lists after calling this script. If either of the lists is invalid, let the script fail and produce an error. The user is probably doing something wrong and the script should not obscure that.

First, I guess you are using a legacy version of GameMaker. This script has an equivalent built-in function now that has some additional features as well.

https://manual.yoyogames.com/#t=GameMak … e_list.htm

If you are using GMS2, you should not be using this script.

The variable dsid is a local variable declared at the start of the script on line 14.

https://www.gmlscripts.com/script/collision_circle_list

Expandvar x1,y1,radius,obj,prec,notme,dsid,i;
                                ^^^^

If you have modified this script to work in GMS2.3 by turning it into a function with a proper function signature at the top and you have removed lines 14 to 20 to make it work, that could explain the problem. The parameter variables in the function signature collision_circle_list(x1,y1,radius,obj,prec,notme) are automatically declared and set when the script function is called. But two of the local variables on line 14 still need to be declared: dsid and i

While the script is executing, local variables should always be visible and have precedence over any instance variable that might have the same name. Using other in the way you suggest would force the script to use an instance variable belonging to the calling instance, the instance outside of the with construct. Likewise, using self there would force the script to use the instance that is currently in scope, the instance being iterated upon inside the with construct.

If dsid had NOT been declared as a local variable in the script, this would cause the error you saw and your suggestion could fix it. It would also create a new variable in the calling instance, or if that variable was already being used in the instance, it would change its value which could cause a bug somewhere else. That's why local variables are used. It prevents a script from accidentally messing up any instance variables that might have the same name or wasting memory and time caused by creating new variables that are not needed outside of the script/function.

You can read about self and other here:
https://manual.yoyogames.com/#t=GameMak … ywords.htm

And you can read about with here:
https://manual.yoyogames.com/#t=GameMak … 2Fwith.htm

And you can read about var and local variables here:
https://manual.yoyogames.com/#t=GameMak … iables.htm

Well, the site and script repo will definitely be transitioning to take advantage of 2.x features like JSDoc. Some of the scripts have been updated but not pushed to the site/repo. Anticipating the new function definitions and JSDoc changes, I was waiting for 2.3 to come out of beta first, which it has now, but the switchover may not happen before 2.3.1. It's a lot of extra labor to maintain multiple sets of scripts. I'm considering the possibility of dynamically converting 2.3-style functions to 2.2-style scripts using code generation but I expect it will be somewhat imperfect.

Since 2.3 has been pushed into the main release channel (despite the huge impact it has on 2.2 projects), I'm not sure 2.2 support makes sense now. It appears it will remain possible to use 2.2 along side 2.3 if one continues to use the 2.3 beta install. YoYo has done a poor job of communicating this, contradicting themselves in places. First they say 2.3 beta should not be used anymore, elsewhere they say the 2.3 beta will continue to receive updates. Other ways of running 2.2 and 2.3 side-by-side (ie. in separate installation directories or by using retail and Steam installations), are doomed to fail because they all share the same configuration data. I'm hoping YoYo will make their intentions more clear soon, so I can make more informed decisions.

Regarding legacy support, when GM:Studio 1 came out I thought it would be nice to have a way to switch between GM versions. It does complicate things significantly and does not easily fit the way pages are currently generated. In the last two years my desire to continue to support any legacy versions of GameMaker (including GMS1) has all but vanished. Something with the last few updates of GMS1 has made it run very poorly on my machine. The interface has become so unresponsive it is a burden to do anything with it.