Discuss and collaborate on GML scripts

You are not logged in.

#1 Re: Script Submission » scale_val » 2024-04-20 03:50:56


Hi, maras. Thanks for suggesting this. We have a script similar to this already.

#2 Re: Script Submission » Foreach [v3.0.1] » 2022-01-10 16:35:20


Whoa! I'll have to think about this.

#3 Re: Script Submission » foreach » 2021-06-20 22:16:36


That doesn't really work. If you have grid and list ids that are equal, your grid would identify as a list. That misidentification could lead to all kinds of problems.

Expandgrid = ds_grid_create(5,5);
list = ds_list_create();

switch (ds_get_type(grid)) {
    case ds_type_grid:
    case ds_type_list:
    case ds_type_map:

#4 Re: Script Submission » foreach » 2021-06-17 17:23:37


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.

#5 Re: Script Submission » foreach » 2021-06-17 12:44:05


Not like that. I would use case statements like you already do but with constants instead of an arbitrary string. This is faster and uses less memory (admittedly tiny optimizations) and it is also self-documenting and easier to remember.

Expandforeach(list, ds_type_list, some_function);
		case ds_type_list:
			var len = ds_list_size(data);
			for(var i = 0; i < len; i++) {
				if f_each(data, i, data[| i]) break;

As you've found, right now a data structure reference is simply a global index value of real type and not a resource or reference with its own type (or value from which a type can be derived). Because of the way GameMaker generates the values, there can be collisions, eg. the first list and the first grid will both have the same index value. One day you'll be able to detect them properly, but for now ds_exists() can only tell if an index is valid and cannot tell indices of different data structure types apart in an implicit way.

#6 Re: Script Submission » base64 URL encode / decode » 2021-06-17 10:39:34


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.

#7 Re: Script Submission » foreach » 2021-06-17 10:27:23


Thanks. One change I would make straight away is using the GameMaker constants instead of strings to identify the data structure types. In the future, this should not be necessary but for now, identification is needed. I also might extend this for all data structure types.


#8 Re: Script Submission » SHA1 <-> buffer » 2021-06-15 16:21:18


Thanks, Juju.

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


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.

#9 Re: Script Submission » Precise Tile Collision » 2021-05-25 14:50:24


Thank you. These will require some testing. I'll contact Pixelated Pope about these adaptations.

Apologies for the late reply.

#10 Re: Script Submission » Draw point of specified size » 2021-05-25 14:43:56


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.

#11 Re: Script Submission » intercept_course_precise » 2021-05-25 14:40:39


I need some explanation about what this does differently than the existing function.

Apologies for the late reply.

#12 Re: Script Submission » draw_line_pattern » 2021-05-25 14:37:19



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.

#13 Re: Script Submission » BB like text formatter draw_text_bb » 2021-05-25 14:26:26


This seems like an extremely useful script. It will require a lot of testing and maybe some tweaks. Thank you.

#14 Re: Script Submission » raycast » 2021-05-25 14:21:59


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

#15 Re: Script Submission » string_get_between » 2021-05-25 14:19:17


Hmmm. I have to think about this. I'm trying to imagine how I would use this in practice. Also, it seems like this could be simplified and sped up with `string_pos_ext()`.

Apologies for the delayed reply. I've been changing web browsers a lot lately and forget that I'm not always logged in here so I miss new messages.

#16 Re: Script Submission » Merge 2 lists, return 1. ds_list_merge(a,b) » 2021-05-25 14:06:42


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.

#17 Re: Script Submission » string_match - a RegEx like script » 2021-05-25 13:53:02


Thanks for the submission, this looks very impressive. It's rather complex and will need some testing and maybe some structural changes to better accommodate this library of scripts. I'm not happy with so many helper functions in the global scope. I want to look into making them method functions inside the primary function. It's not something I've dealt with up to now.

#18 Re: Script Alumni » collision_circle_list » 2021-05-25 13:37:21


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. … 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.

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: … ywords.htm

And you can read about with here: … 2Fwith.htm

And you can read about var and local variables here: … iables.htm

#19 Re: Community » GMS 2.3.x compatibility ? » 2020-09-21 07:08:51


Nothing is set in stone. I may freeze GMS1 scripts but I could still serve them. Working in GMS1 is a miserable experience when every click and key press takes 750 ms to respond. Sometimes it runs OK, like today, but most of the time it doesn't. I need to figure out what is causing it to act badly if GMS1 is to see meaningful support.

#20 Re: Community » GMS 2.3.x compatibility ? » 2020-09-13 15:40:28


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.

Board footer

Powered by FluxBB