• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

OFFICIAL 2.3.8 Betas Thread

Status
Not open for further replies.
๐Ÿ˜† me too.
Being accused of "When in actuality your poor programming broke your code" is that a big free offense and bullying , without considering the people involved and the hard times with the projects.
I use GMS almost 20 years (when is still Mark Overmars's), and 10 years I worked as freelancer coder.
I'm not the best coder, but enough to learn with my errors,learn new things, tweaksmy ways to code or to think, enough to get paid and pay bills of my family. And receive positives feedback of my previous/current skills (even that their are in intermediate levels) , and in the last years, the first 2 commercial games with my name in the credits.


So , despite I'm having years of experience, I and others here need adapt the "transition period" with collision changes. And are changes that even we don't know that is 100% due our "poor skills", or if it is a bug (or a unexpected effect).
And I understand the purpose of Beta and that Yoyo are trying their best to make the "best" program for our developers.
So due the uncertainty and sadness to have our projects being broken, we should have a little more respect with our fellow coders , that have different backgrounds and skill levels.
Bullying only create unnecessary hate and deviate the focus of the main thing : how we can overcame better this situation ?
Sorry for any english language errors. I'm from Brazil and just need give an opinion to a thing that I feel very unfair.
 

squircle

Member
I usually don't post, but honestly was cringing at some of these replies, so just FYI, I reported a collision issue for this beta and it was accepted as a bug. So yes, apparently collisions are wonky in this beta. Assuming anyone saying their code no longer works are exploiting bugs is not only ridiculous, but also none of your business because the very first post of this thread specifically states you are to post here if code that once worked in a previous version no longer works.

About the issue: something appears to be offset by 1. Whether it be the checks themselves, or bounding boxes, dunno. A solution you can try for something like collision_point_list is to offset your x and y check by + 1. If this sounds annoying, it's because it is, so my advice if your project hinges on sprite bounding box collisions is to just wait for the next beta.
 

COWCAT

Member
I've asked it once but... what are the plans for Long Term Support versions?
Frankly I've stopped updating a few versions ago because each "stable" seems to fix bugs and bring new ones.
Personally I don't need new features constantly, I need stability.
 
Then roll back, or live with the fact that changes are needed.

Did you both just ignore the changelog? There is a nice section at the top that applies to you...

From the Changelog:


They fixed a bug related to collision. That fix broke your code. Welcome to software development. If you read the changelogs you could have probably seen this coming, though, and planned accordingly. Blindly updating is a terrible practice, but even more so when you have an already released application that you plan to continue supporting. That's just ridiculous.
Do you think people can take a released consoles project and update the whole collision system? So you have an idea of how many problems, bug and working hours could need? Before talk i think you should consider in this world there are not only amateur programmer, maybe you are so open your mind and look a bit larger than your own feet. For sure for the update i had to use an old runtime but break the collision system is not the best solution also because the runtime 423 has other problems.
For new products is fine for old products is not the best. Keep consistency need to be a must.
 
Last edited by a moderator:

Posh Indie

That Guy
Do you think people can take a released consoles project and update the whole collision system? So you have an idea of how many problems, bug and working hours could need? Before talk i think you should consider in this world there are not only amateur programmer, maybe you are so open your mind and look a bit larger than your own feet. For sure for the update i had to use an old runtime but break the collision system is not the best solution also because the runtime 423 has other problems.
For new products is fine for old products is not the best. Keep consistency need to be a must.
  • It was in the changelog
  • You are using the Beta branch for a released product
  • You decided using this version for your released game was a good idea
  • You decided this for a released console game
  • You talk about keeping consistency in a product while deciding to make a decision that puts that at risk... willingly.
 
Last edited by a moderator:

rIKmAN

Member
I reported a collision issue for this beta and it was accepted as a bug.

About the issue: something appears to be offset by 1. Whether it be the checks themselves, or bounding boxes, dunno.
Was the bug you reported and had accepted related to this "off by 1" issue or for something else you had problems with?

I'm seeing a similar thing and have rolled back to IDE 451 for now which works fine.
I don't want to waste time fixing my own collision code if it's been acknowledged as a bug and will be fixed/reverted next release, rather than behaviour that will be the standard going forward with the change to collisions now using floats.
 
Last edited:

Alice

Darts addict
Forum Staff
Moderator
I think one important thing to acknowledge is that just because something was fixed in collision system, doesn't mean that nothing got broken alongside it. If anything, it makes something breaking even more likely.

If there was some explanation what exactly was changed in collision system, what is the intended behaviour now and how to adjust the old code to the new one, this would help people checking out the Beta quite a lot.

If I'm not mistaken, the situation at the moment is that:
- the recent Beta fixed something regarding collisions
- some people encountered issues in their collision checking code
- since we don't know what's the intended behaviour now, we can only speculate whether the issues are effect of the collision system being fixed or some bug introduced alongside it
- whether the problems arise from the now-intended behaviour or a newly introduced bug, we at least know for a fact that a bug in the bounding boxes was confirmed

So yeah, I'm going to sound like a broken record, but when a change like that is introduced, it'd help a lot to explain what kind of issues it's supposed to fix and what is the intended behaviour now, compared to the existing behaviour earlier.
 

squircle

Member
Was the bug you reported and had accepted related to this "off by 1" issue or for something else you had problems with?
Yes, here is the project I used to report:

Create an object with a collision mask of 16x16
Add four instances of it to a room, each right next to eachother so they form a square, and spaced out 16 pixels apart from eachother like this:
x x
x x
Then, if you use collision_point_list to check the bottom right instance's top left corner, its x/y position (16, 16), it will return all four instances.
In previous versions, it will only return the bottom right instance and nothing else. I checked and collision_rectangle seems to be similar.
The workaround in this case is to offset your checks by x + 1, y + 1, that will return the desired results. I did not check if it returns the correct results for collision_rectangle.
 
  • It was in the changelog
  • You are using the Beta branch for a released product
  • You decided using this version for your released game was a good idea
  • You decided this for a released console game
  • You talk about keeping consistency in a product while deciding to make a decision that puts that at risk... willingly.
You don't know what you are talking about.
Sometimes you need to use a beta to release for consoles because the stable is not updated and not make you able to build and pass certification.
Anyway i have no time to discuss with people like you, presumptuous and a kind of person that know everything.

I had to edit and remove some comments considered my previous post was edited by a moderator.
 
Last edited:

chamaeleon

Member
Yes, here is the project I used to report:

Create an object with a collision mask of 16x16
Add four instances of it to a room, each right next to eachother so they form a square, and spaced out 16 pixels apart from eachother like this:
x x
x x
Then, if you use collision_point_list to check the bottom right instance's top left corner, its x/y position (16, 16), it will return all four instances.
In previous versions, it will only return the bottom right instance and nothing else. I checked and collision_rectangle seems to be similar.
The workaround in this case is to offset your checks by x + 1, y + 1, that will return the desired results. I did not check if it returns the correct results for collision_rectangle.
I wonder what would happen if you set epsilon to zero. I'd try it myself, but I'm not near a computer and am just writing on a phone. Maybe nothing at all, but given the change from int to floating point it occurred to me.
 

chamaeleon

Member
(Nothing changes by setting epsilon to zero)

Changing the sprite mask for the 16x16 pixel instance to be manually 0 to 14 instead of 0 to 15 gets the old behavior while not missing any instances if iterating over integer indices near the corner of all four
GML:
    for (var _x = 14; _x <= 17; _x++) {
        for (var _y = 14; _y <= 17; _y++) {
            var list = ds_list_create();
            var count = collision_point_list(_x, _y, obj_wall, false, true, list, false);
            var i = 0;
            var msg = "[" + string(_x) + ", " + string(_y) + "] Instances = [";
            repeat ds_list_size(list) {
                msg += " " + string(list[| i]);
                i++;
            }
            msg += " ]";
            show_debug_message(msg);
            ds_list_destroy(list);
        }
    }
Using default automatic collision mask
Code:
[14, 14] Instances = [ 100003 ]
[14, 15] Instances = [ 100003 ]
[14, 16] Instances = [ 100003 100004 ]
[14, 17] Instances = [ 100004 ]
[15, 14] Instances = [ 100003 ]
[15, 15] Instances = [ 100003 ]
[15, 16] Instances = [ 100003 100004 ]
[15, 17] Instances = [ 100004 ]
[16, 14] Instances = [ 100003 100005 ]
[16, 15] Instances = [ 100003 100005 ]
[16, 16] Instances = [ 100002 100003 100004 100005 ]
[16, 17] Instances = [ 100002 100004 ]
[17, 14] Instances = [ 100005 ]
[17, 15] Instances = [ 100005 ]
[17, 16] Instances = [ 100002 100005 ]
[17, 17] Instances = [ 100002 ]
Using a 0 to 14 by 0 to 14 collision mask (excluding right and bottom edges from the mask) yields
Code:
[14, 14] Instances = [ 100003 ]
[14, 15] Instances = [ 100003 ]
[14, 16] Instances = [ 100004 ]
[14, 17] Instances = [ 100004 ]
[15, 14] Instances = [ 100003 ]
[15, 15] Instances = [ 100003 ]
[15, 16] Instances = [ 100004 ]
[15, 17] Instances = [ 100004 ]
[16, 14] Instances = [ 100005 ]
[16, 15] Instances = [ 100005 ]
[16, 16] Instances = [ 100002 ]
[16, 17] Instances = [ 100002 ]
[17, 14] Instances = [ 100005 ]
[17, 15] Instances = [ 100005 ]
[17, 16] Instances = [ 100002 ]
[17, 17] Instances = [ 100002 ]
 
In regards to the new collisions system, would it be feasible to add a button to toggle between the old behavior and new behavior in the IDE? That way you could still get the benefits of all the other misc bug fixes.
 

FrostyCat

Redemption Seeker
The addition of ev_pre_create in the 2.3.8 beta may look like an insignificant change, but it has the potential to be the final piece needed to solve one of the oldest problems in GML's history.

Passing variables to new instances before the Create event is now possible.

Yal's book line for passing variables to new instances has been around for years, but it has never seen widespread adoption because of its historic incompatibility with certain built-in instance variables (e.g. sprite_index) and variables declared in Object Variables. Following the release of post-2.3 GML, I wrote an expansion of it taking advantage of structs, but the same historic incompatibilities remained.

But then ev_pre_create was added to the beta, and that was the final piece of the puzzle:
  • instance_change to the new object without performing events
  • ** Perform ev_pre_create **
  • Change the variables according to the struct of customizations
  • Perform ev_create
Result: @Yal 's book line is now completely compatible with built-in instance variables and variables declared in Object Variables, with a syntax that any modern GML developer can understand:
GML:
instance_create_layer_ext(32, 32, "Instances", objThing, {
    sprite_index: sprThingGood,
    number: 100,
});

instance_create_depth_ext(96, 32, 0, objThing, {
    sprite_index: sprThingGood,
    number: 220,
    vspeed: 2,
});
I will be releasing the library to GitHub and the Marketplace after the release of 2.3.8 stable. This is one of the most exciting additions to my working stack, and I cannot wait to share it with everyone. Mark my word: The days of the one-step alarm hack are numbered.
 

Zhanghua

Member
The addition of ev_pre_create in the 2.3.8 beta may look like an insignificant change, but it has the potential to be the final piece needed to solve one of the oldest problems in GML's history.

Passing variables to new instances before the Create event is now possible.

Yal's book line for passing variables to new instances has been around for years, but it has never seen widespread adoption because of its historic incompatibility with certain built-in instance variables (e.g. sprite_index) and variables declared in Object Variables. Following the release of post-2.3 GML, I wrote an expansion of it taking advantage of structs, but the same historic incompatibilities remained.

But then ev_pre_create was added to the beta, and that was the final piece of the puzzle:
  • instance_change to the new object without performing events
  • ** Perform ev_pre_create **
  • Change the variables according to the struct of customizations
  • Perform ev_create
Result: @Yal 's book line is now completely compatible with built-in instance variables and variables declared in Object Variables, with a syntax that any modern GML developer can understand:
GML:
instance_create_layer_ext(32, 32, "Instances", objThing, {
    sprite_index: sprThingGood,
    number: 100,
});

instance_create_depth_ext(96, 32, 0, objThing, {
    sprite_index: sprThingGood,
    number: 220,
    vspeed: 2,
});
I will be releasing the library to GitHub and the Marketplace after the release of 2.3.8 stable. This is one of the most exciting additions to my working stack, and I cannot wait to share it with everyone. Mark my word: The days of the one-step alarm hack are numbered.
need both create before and after
 

gnysek

Member
The addition of ev_pre_create in the 2.3.8 beta may look like an insignificant change
Pre Create was there since "instance variables" were introduced, maybe it wasn't possible to execute it using event_perform (maybe it was, but there was no constant for it?), but it's not that hard to find errors with that event in Tech Support on forum. Seems like it was a bug that it wasn't available to use before :p
 

FrostyCat

Redemption Seeker
need both create before and after
I don't see a unique use case for "before" and "after". If you set variables before the Pre-Create event, they get overwritten by it. If you set variables after the Create event, a with statement on the returned ID already takes care of that.

If these use cases aren't what you mean, please clarify further.
Pre Create was there since "instance variables" were introduced, maybe it wasn't possible to execute it using event_perform (maybe it was, but there was no constant for it?), but it's not that hard to find errors with that event in Tech Support on forum. Seems like it was a bug that it wasn't available to use before :p
The ability to perform it synthetically through that constant is the key addition to 2.3.8. But you are correct in that the Pre-Create event has been around since at least the introduction of Object Variables.
 
I hope that you guys had a good christmas and happy new year soon.
Does anyone have issues with a player move over slopes during the beta test ? (like falling in the air when move down orstop at middle when move up a slope). And a problem that occur for a slope facing left/right , but no problem in the opposite facing ?

My collision system combine solid square tiles and slope objects with precision (a system that I work for 8 years). And isn't working more.
But if I replace tile checking with solid object checking , it works fine.
So far the solution is that when use my function tilePlaceMeeting(xx,yy,layerID) (that check collision with tiles (of LayerID) if entity is placed at (x,y) , I need change to :
tilePlaceMeeting(xx-1,yy-1,layerID) to make work it.

I wonder what is the reason to need make the shift (-1,-1) . Maybe because my function use bbox_left,bbox_right , .... values that are changed in the update. I don't know.
But I wanted share this detail if someone is struggling and need a new idea.

UPDATE : at runtime 423 , it doesn't have these issues.
 
Last edited:

Karlstens

Member
Odd, when I run my otherwise stable project through Beta GMS 23.1.1.451 - the project compiles and runs as per normal, both in VM and YYC, but then crashes without much error or reason about 5-10 seconds in.

When I take my same project back into the stable release, it continues to work as per normal.

What steps can I take to help isolate this issue so I can write up the detail and post to the devs?
 

gnysek

Member
What steps can I take to help isolate this issue so I can write up the detail and post to the devs?
If your game crashes in specific room, for sure you can delete others, and any instances that aren't exist in that room. Then, I would start to remove objects one by one to see if it still crashes. My feeling tells me, that if GMS crashes silently, it might be something with array or structs (usually when replacing/reading/deleting deep nested data), so searching for removing some of variables which have complex data structure is also a good way. Things like that aren't easy, if game doesn't crash at exactly same moment, but randomly, I've got several bugs in past like that and even spending whole day to make reproduction example doesn't gave me any results, but happily for all bugs like that next versions of GMS weren't crashing anymore, so someone else found a way to reproduce it.
 

Karlstens

Member
If your game crashes in specific room, for sure you can delete others, and any instances that aren't exist in that room. Then, I would start to remove objects one by one to see if it still crashes. My feeling tells me, that if GMS crashes silently, it might be something with array or structs (usually when replacing/reading/deleting deep nested data), so searching for removing some of variables which have complex data structure is also a good way. Things like that aren't easy, if game doesn't crash at exactly same moment, but randomly, I've got several bugs in past like that and even spending whole day to make reproduction example doesn't gave me any results, but happily for all bugs like that next versions of GMS weren't crashing anymore, so someone else found a way to reproduce it.
Excitedly, I've isolated my bug. The below works in the released version of GMS2, but causes a silent game crash when compiled via the Beta release upon execution;

GML:
phy_position_x    = infinity;
phy_position_y    = infinity;
What I'm attempting by setting Phy_X/Y to infinity is to suppress a physics when it's off screen and no longer in use, where it can then be placed into a pick-list and recycled when the time comes again for its use - in this example it's space debris floating off screen, I'm needing the object to exist but not be located anywhere - if that makes sense?
 

gnysek

Member
I don't think that setting physics to infinity is a good idea and probably it shouldn't be used in that way, but definietly causing a silent crash is a bug here, even if YYG team would tell that setting to infinity isn't allowed.

We're back in January, but there was still no beta this month, and even no new posts from team, so it seems that December and January are those two months "off" from schedule?
 

rIKmAN

Member
We're back in January, but there was still no beta this month, and even no new posts from team, so it seems that December and January are those two months "off" from schedule?
They've been back a few days after a long break, let's give them time to get their chairs warm before we write off the remaining 3wks of January for any more updates.

You might be right, but it's a bit early to think the worst just yet.
 

Dan

GameMaker Staff
GameMaker Dev.

Dan

GameMaker Staff
GameMaker Dev.
Excitedly, I've isolated my bug. The below works in the released version of GMS2, but causes a silent game crash when compiled via the Beta release upon execution;

GML:
phy_position_x    = infinity;
phy_position_y    = infinity;
I made a tiny sample which does that, and I do not get any difference in 2.3.7 versus the Beta today (or Beta 3's runtime). If you haven't filed a ticket with the small isolated code project, then please do so and we'll take a further look,
 

Posh Indie

That Guy
Happy New Year, all!

That's IDE v23.1.1.454 Runtime v23.1.1.432 now rolling out (your patience was appreciated, folks... ;) )

Perhaps most importantly for those in this thread, it fixes a few collision issues reported for Beta 3 and discussed above, but there is also a small stack of other things we resolved in the last few weeks (including some important IDE stability fixes).

https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html
Happy New Year, and welcome back!
 

Zixtix

Member
For the Ubuntu IDE, I am still getting the following error when compiling for Android YYC for a blank project targetting API 31:

This is with NDK 22.1.7171670, JRE 11:

ClangExeLocation=/bin/clang++

Error : Android ARM ToolChain directory "" does not exist
Error : Android x86 ToolChain directory "" does not exist
Error : Android x86_64 ToolChain directory "" does not exist
Error : Android ARM64 ToolChain directory "" does not exist
Using NDKDir = /usr/local/lib/android/sdk/ndk/22.1.7171670
Using PlatformDir =
Using ARMToolChain =

Ticket number is #192382
This issue is resolved, but I am still not able to build Android YYC on the Ubuntu IDE as now I have a different issue:

Code:
AndroidEnvironment
Manifest Permissions
Manifest Metadata
Check GML functions
Licensing
System.IO.DirectoryNotFoundException: Could not find a part of the path "/home/runner/work/gm-sandbox/gm-cache/Android/default/com.company.game/src/main/assets/game.droid".
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x00164] in <533173d24dae460899d2b10975534bb0>:0
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.IO.FileOptions options) [0x00000] in <533173d24dae460899d2b10975534bb0>:0
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,System.IO.FileOptions)
  at System.IO.FileSystem.CopyFile (System.String sourceFullPath, System.String destFullPath, System.Boolean overwrite) [0x00035] in <533173d24dae460899d2b10975534bb0>:0
  at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, System.Boolean overwrite) [0x00062] in <533173d24dae460899d2b10975534bb0>:0
  at Igor.AndroidBuilder.CreateTargetExe () [0x00d65] in <3400221ef1bc48e68cc5f10056028a1b>:0
  at Igor.AndroidBuilder.Package () [0x00259] in <3400221ef1bc48e68cc5f10056028a1b>:0
  at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
  at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <533173d24dae460899d2b10975534bb0>:0
Igor complete.
Filed another ticket 192811
 
I hope that you guys have a good christmas and new year , despite of spread of covid , cold h2n3 and flurona.

So I tested I test runtimes 431 and 432 (both launched today) , and the tile collision error continue .
This error can be solved if I check a position (x-1,y-1) instead (x,y). Or continuing using runtime 423.

I will a create a separated simple project that shows the problem (I can't use the current one that I'm working , because it has assets with copyrights , so I can't share).
 

Zhanghua

Member
Ticket #192940

Why is the unicode key of struct invalid now ???

GML:
sprGroup = { "่กŒ่ตฐ" : sp_CharMove };//This is valid in the previous beta.



sprGroup = { "a" : sp_CharMove };//This is fine...
 
Last edited:

Yal

๐Ÿง *penguin noises*
GMC Elder
The addition of ev_pre_create in the 2.3.8 beta may look like an insignificant change, but it has the potential to be the final piece needed to solve one of the oldest problems in GML's history.

Passing variables to new instances before the Create event is now possible.

Yal's book line for passing variables to new instances has been around for years, but it has never seen widespread adoption because of its historic incompatibility with certain built-in instance variables (e.g. sprite_index) and variables declared in Object Variables. Following the release of post-2.3 GML, I wrote an expansion of it taking advantage of structs, but the same historic incompatibilities remained.

But then ev_pre_create was added to the beta, and that was the final piece of the puzzle:
  • instance_change to the new object without performing events
  • ** Perform ev_pre_create **
  • Change the variables according to the struct of customizations
  • Perform ev_create
Result: @Yal 's book line is now completely compatible with built-in instance variables and variables declared in Object Variables, with a syntax that any modern GML developer can understand:
GML:
instance_create_layer_ext(32, 32, "Instances", objThing, {
    sprite_index: sprThingGood,
    number: 100,
});

instance_create_depth_ext(96, 32, 0, objThing, {
    sprite_index: sprThingGood,
    number: 220,
    vspeed: 2,
});
I will be releasing the library to GitHub and the Marketplace after the release of 2.3.8 stable. This is one of the most exciting additions to my working stack, and I cannot wait to share it with everyone. Mark my word: The days of the one-step alarm hack are numbered.
Contrary to public belief, me and @YellowAfterlife are not the same person. But thanks for the undeserved credit!

(Also, GUI Variables also let you set variables before the create event, so you could do this kind of stuff already in the room editor - IMO when you're dynamically creating instances you might as well just have a setup script that creates them, sets variables and runs any code affected by those variables in one swoop, the only case you want the create event to check variables is when initially starting a room. But the more ways to do things the merrier, eh?)
 
Last edited:

Yal

๐Ÿง *penguin noises*
GMC Elder
Ticket #192940

Why is the unicode key of struct invalid now ???

GML:
sprGroup = { "่กŒ่ตฐ" : sp_CharMove };//This is valid in the previous beta.



sprGroup = { "a" : sp_CharMove };//This is fine...
Does it work if you begin the string with an @ symbol to prevent escaping? It's necessary for strings with embedded newlines now so it doesn't feel like a stretch it'd be necessary for unicode characters too.
Code:
@"่กŒ่ตฐ": sp_CharMove
 

FoxyOfJungle

Kazan Games
The addition of ev_pre_create in the 2.3.8 beta may look like an insignificant change, but it has the potential to be the final piece needed to solve one of the oldest problems in GML's history.

Passing variables to new instances before the Create event is now possible.

Yal's book line for passing variables to new instances has been around for years, but it has never seen widespread adoption because of its historic incompatibility with certain built-in instance variables (e.g. sprite_index) and variables declared in Object Variables. Following the release of post-2.3 GML, I wrote an expansion of it taking advantage of structs, but the same historic incompatibilities remained.

But then ev_pre_create was added to the beta, and that was the final piece of the puzzle:
  • instance_change to the new object without performing events
  • ** Perform ev_pre_create **
  • Change the variables according to the struct of customizations
  • Perform ev_create
Result: @Yal 's book line is now completely compatible with built-in instance variables and variables declared in Object Variables, with a syntax that any modern GML developer can understand:
GML:
instance_create_layer_ext(32, 32, "Instances", objThing, {
    sprite_index: sprThingGood,
    number: 100,
});

instance_create_depth_ext(96, 32, 0, objThing, {
    sprite_index: sprThingGood,
    number: 220,
    vspeed: 2,
});
I will be releasing the library to GitHub and the Marketplace after the release of 2.3.8 stable. This is one of the most exciting additions to my working stack, and I cannot wait to share it with everyone. Mark my word: The days of the one-step alarm hack are numbered.
Apparently we are getting closer and closer to bigger competitors like Unity (in 2D terms, of course). (I particularly find GMS 2 better for 2D games than Unity, anyway.)
Since in C# we can use void Awake() {}

C#:
using UnityEngine;

public class TestScript : MonoBehaviour
{
    void Awake ()
    {
        //GMS 2's Pre-Create Event
        Debug.Log("Awake Called.");
    }


    void Start ()
    {
        //GMS 2's Create Event
        Debug.Log("Start Called.");
    }
}

Of course there are slight differences between the two, as they work a little differently (example: In Unity, Awake is called even with script disabled), but the run-before-Start logic is the same as we will have now, and that it's very good.
 

Zhanghua

Member
Does it work if you begin the string with an @ symbol to prevent escaping? It's necessary for strings with embedded newlines now so it doesn't feel like a stretch it'd be necessary for unicode characters too.
Code:
@"่กŒ่ตฐ": sp_CharMove
No : invalid struct entry name ่กŒ่ตฐ

It's valid in pre-beta.

In the latest beta:
GML:
a = { "่กŒ่ตฐ" : 1 } or a = { @"่กŒ่ตฐ" : 1 }
is invalid, but following is valid.
GML:
a = {}; a[$ "่กŒ่ตฐ"] = 1
 
Last edited:

Karlstens

Member
Apparently we are getting closer and closer to bigger competitors like Unity (in 2D terms, of course). (I particularly find GMS 2 better for 2D games than Unity, anyway.)
Since in C# we can use void Awake() {}

C#:
using UnityEngine;

public class TestScript : MonoBehaviour
{
    void Awake ()
    {
        //GMS 2's Pre-Create Event
        Debug.Log("Awake Called.");
    }


    void Start ()
    {
        //GMS 2's Create Event
        Debug.Log("Start Called.");
    }
}

Of course there are slight differences between the two, as they work a little differently (example: In Unity, Awake is called even with script disabled), but the run-before-Start logic is the same as we will have now, and that it's very good.
I can't believe I hadn't hit this snag until recently. I think I'm late to the "Create Event" limitations party as I've been wasting time figuring out my own custom Object Life-Cycle system, where instances are never destroyed - they're simply recycled.

Can't wait to try ev_pre_create, if only I could find an example or documentation on it.
 

gnysek

Member
Of course there are slight differences between the two
We gonna get closer to gorgeousness when events like create/destroy/pre-create/cleanup will be added to constructors :p (ok, pre-create and create are just constructor body and they exists now, but there's nothing for destroy/cleanup).
 

rwkay

GameMaker Staff
GameMaker Dev.
We gonna get closer to gorgeousness when events like create/destroy/pre-create/cleanup will be added to constructors :p (ok, pre-create and create are just constructor body and they exists now, but there's nothing for destroy/cleanup).
There are no plans to add a destructor for structs - we have good reasons for this as it vastly complicates the garbage collector (user code in destructors can easily and inadvertently resurrect structs which invalidates the current sweep and causes big problems) - so this will not happen. (For similar reasons JavaScript does not allow destructors either).

Use the WeakReference for structs that you need to track and perform clean up on so that you can easily clean up an object once it has been destructed.

We do not have plans to expose the ev_pre_create (it was erroneously exposed in an earlier Beta) using this would be abusing the system just use the normal create event, we have already heavily optimised the creation and memory usage of Instances.

Russell
 

FrostyCat

Redemption Seeker
We do not have plans to expose the ev_pre_create (it was erroneously exposed in an earlier Beta) using this would be abusing the system just use the normal create event, we have already heavily optimised the creation and memory usage of Instances.
There are times when we cannot just use the normal Create event, because it happens too late and is already responsible for other setup.

Passing variables to the Create event is a problem that has been discussed throughout GM's history. All current workarounds have known deficiencies:
  • 1-step alarms leave a gap in time where an instance is fundamentally unready, and also hides setup in a place other than the Create event.
  • YellowAfterlife's book line fails to set certain built-in variables because the Pre-Create event overwrites them.
  • Post-creation edits (e.g. with (instance_create_layer(...)) { ... }) happen too late for the Create event to act on its changes.
But now there is a chance for a solution that has none of these faults, and controlling the timing of the Pre-Create event in relation to the injection of passed variables turns out to be important. And according to this post, there are further practical applications to controlling the Pre-Create event, not just this one.

Please reconsider exposing ev_pre_create. It has more practical utility than you think, and in fact it is already being leveraged.
 

Karlstens

Member
There are no plans to add a destructor for structs - we have good reasons for this as it vastly complicates the garbage collector (user code in destructors can easily and inadvertently resurrect structs which invalidates the current sweep and causes big problems) - so this will not happen. (For similar reasons JavaScript does not allow destructors either).

Use the WeakReference for structs that you need to track and perform clean up on so that you can easily clean up an object once it has been destructed.

We do not have plans to expose the ev_pre_create (it was erroneously exposed in an earlier Beta) using this would be abusing the system just use the normal create event, we have already heavily optimised the creation and memory usage of Instances.

Russell
Thanks Russell, I created a YoYo Feature Request recently regarding the inability to pass argument or new values upon calling instance_create_layer() / instance_create_depth() - and that was before reading up on the forums and discovering just how many other users are experiencing this same difficulty. What is YoYo's current stance on this in general? Are there plans to make life easier for users here, or does YoYo have a preferred method that users should be using?

I'm still very surprised by this limitation, considering I've used the app on and off for a couple of years now, this particular limitation is a real annoying challenge.
 

rwkay

GameMaker Staff
GameMaker Dev.
There are times when we cannot just use the normal Create event, because it happens too late and is already responsible for other setup.

Passing variables to the Create event is a problem that has been discussed throughout GM's history. All current workarounds have known deficiencies:
  • 1-step alarms leave a gap in time where an instance is fundamentally unready, and also hides setup in a place other than the Create event.
  • YellowAfterlife's book line fails to set certain built-in variables because the Pre-Create event overwrites them.
  • Post-creation edits (e.g. with (instance_create_layer(...)) { ... }) happen too late for the Create event to act on its changes.
But now there is a chance for a solution that has none of these faults, and controlling the timing of the Pre-Create event in relation to the injection of passed variables turns out to be important. And according to this post, there are further practical applications to controlling the Pre-Create event, not just this one.

Please reconsider exposing ev_pre_create. It has more practical utility than you think, and in fact it is already being leveraged.
I understand the limitations (I don't necessarily agree with them all) but exposing the pre-create event constant will do nothing for this as all it does is exposes an event (that is compiler generated) that is intended to be called before the create event is called so pre_create is intended to go hand in glove with the create event (pre_create is called before the create event, for the avoidance of doubt). I do not see how exposing a constant (that is all the value is) would help in any case (it is 14 btw fact fans) It is not intended to be called in any other way.

Personally I would prefer to allow a struct to be passed into the instance_create_* functions the contents of which would cloned into the instance before the create event is called - which from what I know would satisfy the requirements that I have seen.

Russell
 

Alice

Darts addict
Forum Staff
Moderator
I do not see how exposing a constant (that is all the value is) would help in any case (it is 14 btw fact fans) It is not intended to be called in any other way.
As I see it, exposing a constant is making a sort of promise: "When you use this constant in such and such way, that thing will work properly."

For example, "When you pass fa_right to draw_set_halign, the drawn text will be right-aligned going forward."
At this point, it doesn't matter for us if fa_right has a value of 2 or 3, or if it has different values across platforms. The important thing is that I can reasonably expect draw_set_halign(fa_right) to align my text to the right side, and that it works that way for all applicable platforms. If I used draw_set_halign(2), I wouldn't be so confident that it would work the same across platforms or that it wouldn't be changed sometime later; theoretically there should be no reason to, but it's still an undocumented behaviour of sorts which leaves some room for doubt.

For similar reasons, if "ev_pre_create" was exposed - even if it would only ever be used in the event_perform(ev_pre_create, 0) context - I would feel safer using an officially exposed constant compared to more "hacky" and undocumented event_perform(14, 0)
 
Status
Not open for further replies.
Top