OFFICIAL 2.3.8 Betas Thread

[rwkay]

No : invalid struct entry name 行走

It's valid in pre-beta.

In the latest beta:

a = { "行走" : 1 } or a = { @"行走" : 1 }

is invalid, but following is valid.

a = {}; a[$ "行走"] = 1

Yes this is not a legal id (they must be of the same form as all variables i.e. they can start with anything in the set ['_', 'a'-'z', 'A'-'Z',] followed by any number of chars in the set ['_', 'a'-'z', 'A'-'Z', '0'-'9']

Russell

 

[rwkay]

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)

Exactly I don't want you to feel safe doing that.... I do not intend for you to do that... which is my point

Russell

 

[Alice]

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.

Oh, didn't see that edit earlier.
I guess if instance_create_* function could have struct values passed to it, it would indeed remove the primary reason why people would want to call ev_pre_create.

 

[rwkay]

Oh, didn't see that edit earlier.
I guess if instance_create_* function could have struct values passed to it, it would indeed remove the primary reason why people would want to call ev_pre_create.

Agreed - I would rather go for the proper solution rather than exposing something that would encourage half baked solutions.

Russell

 

[FrostyCat]

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.

instance_change and instance_copy can both induce situations where both the Pre-Create and Create events are bypassed. If only the Create event is exposed, there would be a way to fill in for missed Create events, but no way to fill in for missed actions from the Pre-Create event (e.g. important variable definitions in Object Variables).

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.

That would satisfy the use case I presented in this topic, but it may not be a simple clone if the struct contains methods and issues with method ownership are involved. If you look in the demo, I rebind all methods owned by the struct to the created instance, but not methods owned by other things.

In any case, I would love to see a built-in solution to the 20-plus-years-old "pass variable to Create event" issue. Would you be willing to look into it soon, if I file a ticket for it now?

I am also not sure if that would satisfy the use case that YellowAfterlife mentioned in his reply. This is the library that he is apparently using it in: GMRoomPack

Yes this is not a legal id (they must be of the same form as all variables i.e. they can start with anything in the set ['_', 'a'-'z', 'A'-'Z',] followed by any number of chars in the set ['_', 'a'-'z', 'A'-'Z', '0'-'9']

Quite frankly, this is something that I would rather see NOT checked anymore, as per the previous beta. Please DO NOT step up enforcement of these standards in struct keys when they are provided as strings. In fact, please step it down to the minimum possible.

JSON is a major use case for untyped structs and the struct literal syntax. The literal syntax should be at parity with the [$ ] accessor when the key is specified as a string (i.e. accepts the same range of things), but in 2.3.7 and below it is not, and it has been a significant pain point. We end up needlessly splitting a definition into two parts, those with "GML legal" keys in a literal, followed by "GML illegal" keys in a bunch of accessors that follow. The behaviour in the previous beta was an answer to a request I made some time ago (#178377), and now it has slipped from our grasps again.

The JSON standard does NOT have demands like what you stated on keys, the only condition is that they are valid strings. Many JSON-based standards, such as linked data, have keys like @context and @id, and being able to build structs containing those in literal form is useful for API work. Many game-related APIs also use score as a key, something that the unquoted struct literal syntax wouldn't allow (i.e. { score: 475 } is currently illegal). Quoted struct keys should allow us direct access to these and more, and they should not be synthetically handicapped.

 

[rwkay]

Quite frankly, this is something that I would rather see NOT checked anymore, as per the previous beta. Please DO NOT step up enforcement of these standards in struct keys when they are provided as strings. In fact, please step it down to the minimum possible.

JSON is a major use case for untyped structs and the struct literal syntax. The literal syntax should be at parity with the [$ ] accessor when the key is specified as a string (i.e. accepts the same range of things), but in 2.3.7 and below it is not, and it has been a significant pain point. We end up needlessly splitting a definition into two parts, those with "GML legal" keys in a literal, followed by "GML illegal" keys in a bunch of accessors that follow. The behaviour in the previous beta was an answer to a request I made some time ago (#178377), and now it has slipped from our grasps again.

The JSON standard does NOT have demands like what you stated on keys, the only condition is that they are valid strings. Many JSON-based standards, such as linked data, have keys like @context and @id, and being able to build structs containing those in literal form is useful for API work. Many game-related APIs also use score as a key, something that the unquoted struct literal syntax wouldn't allow (i.e. { score: 475 } is currently illegal). Quoted struct keys should allow us direct access to these and more, and they should not be synthetically handicapped.

This is not in JSON (we do not check within JSON strings) this is in struct literals that DO require id's on the struct literals as they are going to be checked at compile time - the constant behaviour is just mapping directly to id's at compile time and these are checked properly - if you want to use non-ids then you need to use JSON or using variable_struct_set/get to assign and get them.

Russell

 

[FrostyCat]

This is not in JSON (we do not check within JSON strings) this is in struct literals that DO require id's on the struct literals as they are going to be checked at compile time - the constant behaviour is just mapping directly to id's at compile time and these are checked properly - if you want to use non-ids then you need to use JSON or using variable_struct_set/get to assign and get them.

Russell

I understand that in struct literals with UNQUOTED keys, the keys map to IDs at compile time, and therefore need to comply with standard variable naming rules:

var json = json_stringify({
    foo: "FOO",
    bar: 583,
});

But for struct literals with QUOTED keys (apparently new to the 2.3.8 beta?), is it possible to make the quoted keys map to variable_struct_set assignments (or an equivalent that doesn't have the compile-time check that unquoted keys do), such that the following is possible?

var json = json_stringify({
    "@context": "https://mysite.com/contexts/scores.jsonld",
    "@id": "https://mysite.com/scores/5942",
    "name": "Alice Anderson",
    "score": 583,
});

This will address what Zhanghua has been getting at, and also allow a greater degree of interoperability between JSON and GML.

 

[Karlstens]

…
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

This would be amazing. I posted my workaround by more-or-less abandoning use of Create Event and using Room Start and User Event in its place, this seems to do the trick until we can feed values for use into the Create Event, as per your struct suggestion. Fingers crossed we see this in a 2022 beta.

 

[Zhanghua]

Yes this is not a legal id (they must be of the same form as all variables i.e. they can start with anything in the set ['_', 'a'-'z', 'A'-'Z',] followed by any number of chars in the set ['_', 'a'-'z', 'A'-'Z', '0'-'9']

Russell

It's funny. In previous beta，it is valid.
If a

Yes this is not a legal id (they must be of the same form as all variables i.e. they can start with anything in the set ['_', 'a'-'z', 'A'-'Z',] followed by any number of chars in the set ['_', 'a'-'z', 'A'-'Z', '0'-'9']

Russell

// this statement is valid in last beta
// but can't be compiled in this version
// error message:
// invalid struct entry name 行走
// malformed assignment statement

a = {"行走":123};

// the equation statement following is fine
a1 = {}; a1[$ "行走"] = 123;
show_message( [a1,a1[$ "行走"] ] )

a2 = json_parse("{\"行走\":123}")
show_message( [a2,a2[$ "行走"] ] )

 

[gnysek]

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.

Already done that - if anyone interested, my garbage collected ds_xxx implementation using structs is available here for free: https://github.com/gmclan-org/ds_structs-but-gc (and it's probably a good example of how to use weak ref, but you're welcome to report issues if there are any ).

 

[rwkay]

I understand that in struct literals with UNQUOTED keys, the keys map to IDs at compile time, and therefore need to comply with standard variable naming rules:

var json = json_stringify({
    foo: "FOO",
    bar: 583,
});

But for struct literals with QUOTED keys (apparently new to the 2.3.8 beta?), is it possible to make the quoted keys map to variable_struct_set assignments (or an equivalent that doesn't have the compile-time check that unquoted keys do), such that the following is possible?

var json = json_stringify({
    "@context": "https://mysite.com/contexts/scores.jsonld",
    "@id": "https://mysite.com/scores/5942",
    "name": "Alice Anderson",
    "score": 583,
});

This will address what Zhanghua has been getting at, and also allow a greater degree of interoperability between JSON and GML.

That is not the intention - it will not be happening in the current time frame, the initial bug fix was because some common names are counted as constants by the parser so built in names were not able to be used - I will look at changing how constants strings are handled.

The original bug fix stands, allowing built in names to be used - I may fix it so constant strings are NOT allowed.

Russell

 

[Dan]

Beta 6 (IDE v23.1.1.455 Runtime v23.1.1.433) is rolling out now. IDE changes are pretty small workflow bug-fixes, but there are a few things of importance changed in the new runtime...

This version introduces secure web sockets support on almost all platforms, so please do give that a try if this is something you have been waiting for. Any issues, let us know asap.

It also adds a change to the fx_create() function so that GMS2 will now detect the filter names you pass into this (as a plain old string in your code - it can't work out variable values, or array/struct contents, etc.) and ensure these are part of your game compile, saving you the need to create a potentially-redundant layer in one of your rooms just to call that filter/effect type to make your in-game code work later on.

And we also fixed some stability/silent crash issues when passing incorrect values to some functions.


As always, see the full notes for more details:
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html

 

[7 Raven Studios]

I saw a strange thing in the room editor since few betas, i'm not sure it is intended and in which terms.
If i have a room with 3 or 4 instance layer and choose to mark one not visible clicking the eye icon it disappear correctly in the editor but in some case all objects in it also disappear in the game, when run, in other case the objects are all visible.

The documentation do not explain if marking a layer visible/hidden using the eye icon also make all the instances visible/hidden in the executable. In the past i remember it was working exactly as expected, what is marked invisible is not present in the room during the run.

Something is changed? there is a rule somewhere ? Why only some instance layer are affected and others not ?

Thanks

 

[rwkay]

I saw a strange thing in the room editor since few betas, i'm not sure it is intended and in which terms.
If i have a room with 3 or 4 instance layer and choose to mark one not visible clicking the eye icon it disappear correctly in the editor but in some case all objects in it also disappear in the game, when run, in other case the objects are all visible.

The documentation do not explain if marking a layer visible/hidden using the eye icon also make all the instances visible/hidden in the executable. In the past i remember it was working exactly as expected, what is marked invisible is not present in the room during the run.

Something is changed? there is a rule somewhere ? Why only some instance layer are affected and others not ?

Thanks

This has always been the case with layers - the eye is showing you the `visible` flag on the layer and this is exported to the Runner if you want to see them at runtime just set the layer to being visible see https://manual.yoyogames.com/#t=Gam...rhsearch=layer visible&rhhlterm=layer visible

See https://manual.yoyogames.com/#t=The...rhsearch=layer visible&rhhlterm=layer visible in the first paragraph which tells you how this works.

Russell

 

[7 Raven Studios]

This has always been the case with layers - the eye is showing you the `visible` flag on the layer and this is exported to the Runner if you want to see them at runtime just set the layer to being visible see https://manual.yoyogames.com/#t=GameMaker_Language/GML_Reference/Asset_Management/Rooms/General_Layer_Functions/layer_set_visible.htm&rhsearch=layer visible&rhhlterm=layer visible

See https://manual.yoyogames.com/#t=The_Asset_Editors/Room_Properties/Layer_Properties.htm&rhsearch=layer visible&rhhlterm=layer visible in the first paragraph which tells you how this works.

Russell

That's fine but why some layer works in a way and other layers of the same kind works different ?
In my current project i have 4 instances layers, where in one i use the player and other things like enemies, in another the collectable objects, another for the lights and in the top one the hidden objects.

Now if i mark not visible the player and enemies the room not works at all because all major objects are not visible.
If i mark not visible the collectable objects layer they are yes not visible in the room editor but become visible in the room also if i never wrote a line of code to enable/disable them.

This for me is a bug and happen only on instance layer not for the others. I'm talking of 2 instance layers visible/hidden with 2 different behavior when the game run without manipulate them via code.

 

[rwkay]

That's fine but why some layer works in a way and other layers of the same kind works different ?
In my current project i have 4 instances layers, where in one i use the player and other things like enemies, in another the collectable objects, another for the lights and in the top one the hidden objects.

Now if i mark not visible the player and enemies the room not works at all because all major objects are not visible.
If i mark not visible the collectable objects layer they are yes not visible in the room editor but become visible in the room also if i never wrote a line of code to enable/disable them.

This for me is a bug and happen only on instance layer not for the others. I'm talking of 2 instance layers visible/hidden with 2 different behavior when the game run without manipulate them via code.

That sounds like a bug - please report it.

Russell

 

[Mehdi]

CTRL+Tab is working perfectly in the latest beta just released. (It doesnt need holding the buttons and works instantly). Please for God's sake maintain this for January stable release and keep it for as many future releases as you can!

 

[Leandro Saccoletto]

The collision error still persists at 433.
But my bug report was yesterday, so it would take time.
I hope that can be found a solution in the next updates.

 

[gnysek]

But my bug report was yesterday, so it would take time.

From my experience, small percentage of helpdesk "confirmed and added it into our bug database" answers are false-positive, so collision bugs might be for sure a slippery topic (even for helpdesk team, as they also were used to previous system), so it would be good to get more detailed info what could change with new system (changing int to float doesn't say too much), as maybe our expectations are beyond features it provides now.
Of course, that doesn't mean your report is a case which I mentioned, and it can be included in next updates, as after introducing secure sockets I'm nearly sure we gonna have few more betas yet.

Btw. since we have secure sockets now, Intellisense is next feature to be introduced (2.3.8 or 2.3.9 - who knows). I'm trying to calm down, but I'm so happy for that!

 

[Karlstens]

Beta 6 (IDE v23.1.1.455 Runtime v23.1.1.433) is rolling out now. IDE changes are pretty small workflow bug-fixes, but there are a few things of importance changed in the new runtime...

This version introduces secure web sockets support on almost all platforms, so please do give that a try if this is something you have been waiting for. Any issues, let us know asap.

It also adds a change to the fx_create() function so that GMS2 will now detect the filter names you pass into this (as a plain old string in your code - it can't work out variable values, or array/struct contents, etc.) and ensure these are part of your game compile, saving you the need to create a potentially-redundant layer in one of your rooms just to call that filter/effect type to make your in-game code work later on.

And we also fixed some stability/silent crash issues when passing incorrect values to some functions.


As always, see the full notes for more details:
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html

Thanks for this, I’ll give it a whirl this afternoon. I think YAL will be happy with these recent changes as they’ll work well with testing FX layers in GMLive.

 

[gnysek]

YAL

YellowAfterLife, not YAL

 

[rIKmAN]

YellowAfterLife, not YAL

It's YellowAfterlife (no capital L in life).

I only know as I saw a new account the other day called YellowAfterLife (with a capital L) that posted directly underneath a comment by the real YellowAfterlife.
I don't think case should matter when it comes to usernames for a few reasons - one of them being the mistake you just made.

 

[Stra]

@rwkay one of you guys once mentioned the percentage of opened DnD vs. GML projects, which was interesting.

Do you perchance have the stats on opened projects in the Win vs Linux vs Mac versions? (Only if it is public, of course).

 

[Dan]

Beta 7 (IDE v23.1.1.457 Runtime v23.1.1.434) is rolling out now. Pretty small bug-fix release this time, tbh, but one thing to note is that we did reverse the change to the Left Ctrl key in the last couple of Betas.

As always, see the full notes for more details:
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html

 

[gnysek]

In-Game: [Opera GX] Cursor is made invisible on game start and remains so until it is moved off the game window [a Game Option to enable the cursor was missing, you will need to select this option to get the fix]

This is very good information! In fact as for less than two days there's lot of fixes in this version.

I've also noticed, that roadmap changed a little today (Web Sockets marked as "in beta" now, Single Layers Filters entered into list after them), and from what I understand they are marked as "in development" as this is for in-IDE support, not only GML which we have already - but I like that we're getting some features in parts that are done to start testing them and even already use them in projects (keeping in mind that they might change a little, but for experienced users it shouldn't be a problem to fix experimental code)

 

[Mehdi]

I've also noticed, that roadmap changed a little today

I'm always dreaming the day that finally "UI system" goes under "In Beta" category. Please God! Keep me alive until that day.

 

[Leandro Saccoletto]

I did some tests and I narrowed more the collision issue.
I created an object with a sprite that is a 32x32 square and placed at (32,32) , surrounded by tiles.
And I coded a looping to check positions inside of the object. It detected tiles at left side and bottom side of sprite. So I decided see the bbox_* values of the objects . So :
bbox_left = 32 , bbox_right = 64 , bbox_top = 32 , bbox_bottom = 64.

bbox_right and bbox_bottom should be 63 , not 64 (one less pixel). I placed objects in others parts in the room, test different collision mask modes (full, automatic, manual) , and the result is the same.
I think that we need more details about "bounding box values being floats" , because it is clear that has a rounding error at right,bottom sides.

 

[gnysek]

If bbox is inclusive (I think it is), that says all about this issue. I'm writing from mobile now so I can't check in GMS2 to be sure, but as I remember, when creating 32x32 sprite it's bounding box is from 0 to 31 (so like in arrays, starts from 0). It's probably because that doesn't mean which pixels should collide, but between which x/y-coordinates collision should happen (>=0, <=31). If sprite width is 32, then when placed on x=0, on x=32 it's already empty space, same on 64, 96, 128 and so on, so it seems to work OK.

Edit:

bbox_left = 32 , bbox_right = 64 , bbox_top = 32 , bbox_bottom = 64.

even on sprite editor, you can see, that with this settings collision mask is OUTSIDE of sprite by 1 pixel:

as this mask have 33 pixels (inclusive) of width and height. When setting collision mask, put coordinate if where pixels you want to include are starting, not where sprite ends.

 

[rIKmAN]

@squircle confirmed on the last page that he had an "off-by-one" ticket accepted as a bug and I asked and was told that there are issues with collisions in the beta so there is obviously something amiss with them no mater how many explanations are offered for workarounds/solutions.

I have a project that worked fine upto Runtime 423 and every version since (including the latest beta) has issues with collisions when running the same project in each.
It's likely it's the same bug squircle had accepted but it could be something else, once that bug is reported as fixed I'll retest and report it again if the issues are still happening.

@Dan just to clear up any confusion, can you confirm there are still outstanding bugs regarding collisions that are still due to be fixed?

 

[Leandro Saccoletto]

I did further tests now and things gets worsen.

If I place the 32x32 square surrounded by solid squared objects (called oSolidPar) , and uses place_meeting(x,y,oSolidPar) , it returns false (the correct value). That shows that place_meeting doesn't use bboxes values directly. The same happens for instance_place())
But if I make a looping over the square area (using bboxes values as limits) with position_meeting(i,j,oSolidPar) , it returns true in the border (at 4 sides). Same happens if I use instance_position().

So in the end :
--> with tile collision, it gets true at bottom,right side of object (looping over square with tilemap_get_at_pixel() ).
--> with object collision , place_meeting()/instance_place() detect false/noone.
--> with object collision , position_meeting()/instance_position() detect true/ != noone at right,top,left and bottom sides. (looping over square with position_meeting()/instance_position() ).

 

[Leandro Saccoletto]

even on sprite editor, you can see, that with this settings collision mask is OUTSIDE of sprite by 1 pixel:

Just a small correction, because I wasn't clear. I didn't see the bboxes values at sprite editor. I saw in the game, using show_debug_message().

 

[gnysek]

Just a small correction, because I wasn't clear

You're not clear at all, as you describes something, that doesn't seem to have any sense.
When having 32x32 square surrounded by solid objects of same size, aligned to 32x32 grid, place_meeting should return false, as collision functions detects overlapping, not touching with edges. So for collision at least one pixel or coordinate should happen. If you use "solid" flag, and try to move instance using speed/dir or x/y value changes it might indeed looks like they are detecting collision on edge touch, but the truth is that it detects collision on overlapping, and moves instance back to previous position (that happens especially if you uses integer numbers which when dividing grid size, returns no fraction part, eg. when speed is 4, 32/4=8, so there will be no spacing between instances when solid collision happens - but try to use 7...). So, in below example, there's no collisions:

However, indeed there's still some error, as when I played with it a little, seems that position_meeting and place_meeting returns different results for left-top corner of transparent rectangle (it moved along cursor, so it's position is integer, tested on Ubuntu):

So, yeah, some clarification and maybe even a blog post about how collisions should work would be welcome, as that update introduces a lot of mess.

 

[Leandro Saccoletto]

@gnysek yes it doesn't have sense, but is that what happens. My concern in using a workaround for position_meeting() and bbox_right/bbox_bottom is that , in a next update, I need remove this "fix".
All the results that you show me are the same that happens with me.
We both got place_meeting() false in the first and second images.
If your sprite's origin is at (0,0) , I know that your position_meeting(x,y,Object1) will be true , because bbox_left = x and bbox_bottom = y (when run the project) and the error at position_meeting().

 

[gnysek]

because bbox_left = x and bbox_bottom = y

bbox_left on x sounds good, but indeed, bbox_bottom is y+sprite_get_height(sprite_index), not y+sprite_get_bbox_bottom(sprite_index), which means it's 1 pixel too far (in case described above only, not when using manual collision shapes/coordinates). From what I noticed, position_meeting returns wrong values only if it's x/y is higher than object with which we're checking, which might be connected to wrong bboxes on right and bottom side.
Since that's already reported, seems we need to wait until they solve that, as making more tests instead of finding bugs may lead to wrong assumptions on how it should work now

Edit: yep, it's bbox_right and bbox_bottom which are broken by +1 pixel, but it's interesting that for place_meeting it seems to use proper values:

 

[Yal]

seems that position_meeting and place_meeting returns different results

This has been a common occurence AFAIK, I had some really hard-to-track-down bugs a couple of years back that ended up being caused by place_meeting and collision_point having different ideas about how the collision mask worked. (And as for how any collision function treats non-integer coordinates when the mask is defined in pixels... let's not go down that rabbit hole)

Right now the best workaround is to set your game up so you don't need collisions to be accurate (small hitboxes for enemy/bullet collisions, manually check points for terrain collisions instead of using the sprite mask - IMO it's a good practice to use different collision masks for hazards and terrain anyway) but you definitely shouldn't mix different collision functions together if you can avoid it.

 

[Amon]

Right now the best workaround is to set your game up so you don't need collisions to be accurate (small hitboxes for enemy/bullet collisions, manually check points for terrain collisions instead of using the sprite mask - IMO it's a good practice to use different collision masks for hazards and terrain anyway) but you definitely shouldn't mix different collision functions together if you can avoid it.

Or, they could finally fix collisions.

 

[Leandro Saccoletto]

From what I tested so far , any project that uses place_meeting()/instance_place() only it is safe for now.
If you need somehow use bbox_right or bbox_bottom as values somewhere, you need use "bbox_right -1" and "bbox_bottom - 1" .
And if you use instance_position()/position_meeting() and need use a position that has bbox_left or bbox_top , ..... I'm not sure. My first guess would be using bbox_left + 1 and bbox_top +1, but feels wrong. But at same time the error look better than doing no changes.
About collision_line() , collision_rectangle(), ... I didn't test it.

EDIT 1 :
--> collision_point() and collision_line() have the same problem of instance_position().
--> collision_rectangle() works wrong if use "collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,oSolidPar,false,true)"
, but gives the right value if "collision_rectangle(bbox_left,bbox_top,bbox_right-1,bbox_bottom-1,oSolidPar,false,true)".

I think that I'm done in debugging collision checking functions . It giving me some anxiety feelings to have it fixed. I'll wait for a proper update and work in something that doesn't need it right now (like a combo system to an enemy or finish a final boss in another project).

 

[SoulPixel]

That's Beta 4 rolling out now - IDE v23.1.1.451 Runtime v23.1.1.427

Fixes the caching/"corruption" bug mentioned above, along with a good few others. (As you can see in just this thread alone, there were multiple ways you could have achieved this, but they all involved your cache not being cleaned properly before starting a new build, so I only added one line to the release notes and a mention your steps may have varied.)

Note that this version also introduces new functions so you can toggle an fx layer in-game to only apply to a specific layer or not by doing the following

myEffect = fx_create("_filter_pixelate");
fx_set_single_layer(myEffect, true);
layer_set_fx("Effect_1", myEffect);

And it does also have a big change to collision in order to fix a stack of long-time collision bugs in the one release. Please do check your games well, but hopefully you will find they behave much better now.


Release Notes
Runtime Release Notes

I tried to use the new fx_set_single_layer() function.
But the selected Layer just turns invisible.
Without the function the filter is applied correctly.
Is this a bug or am I doing something wrong?

 

[Slyddar]

Beta 7 (IDE v23.1.1.457 Runtime v23.1.1.434) is rolling out now. Pretty small bug-fix release this time, tbh,

• Note that there is also quite a substantial change to collisions, as bounding box values are now floats rather than ints - this increases accuracy and fixes a number of long-standing bugs, but you should test your games carefully, as you may need to make changes to your code in response to this fix.

I have a few tile based commercial projects that rely on bbox values being integers for the collisions to work. It's been like that for the life of GMS2. Most of my code seems ok, but there are definitely issues that will now need debugging and solving. Just simple things like ensuring 2 instances are standing on the same tile by comparing bbox_bottom values, is now broken, and needs re-writing. Instances that are moved directly onto the top of a tile are now placed 1 pixel lower then they were before, meaning they spawn inside the tile.

I also have over 5000 students who I've taught a tile collision method which will now have issues once this is released as stable. They've completed the course, so they will not know why it's broken, just that it now doesn't work anymore.

Can I ask what happened to make this change necessary, as it's not a "small bug-fix" for people who rely on it to work the way it always has?

 

[Jman]

Are secure web sockets supposed to function the same as web sockets where I create a server socket with network_create_server()
and connect to it with network_connect()? When using the windows export, calling network_create_server() with the network_socket_wss constant
gives me an error saying "Error: WSS not yet implemented".

I'm not sure if I am just misunderstanding them, but should the windows export be able to create a secure web socket with network_create_server()?

 

[ikki95]

There is a few issues inside the debugger with this beta

• Bad animation when the debug windows is opened or closed (193158). Already present in 2.3.7
• the debug pane is not shown anymore (usually on the left side) when we start a debug session. New in 2.3.8 (193239) Bad usage of my side...
• adding or removing breakpoint in the debug view is a pain (click issue). New in 2.3.8 (193239)

 

[Dan]

A new Beta is rolling out now - 2022.1.0.464 (with runtime 2022.1.0.436).

That's right, a shiny new version numbering format and this version also introduces an early look at our powerful and expansive new "intellisense" system, which is currently codenamed Feather in the IDE. More information on these two can be found on https://forum.yoyogames.com/index.php?threads/gamemaker-studio-2-version-2022-1.92567. Any general feedback and suggestions on Feather, feel free to join the discussion on that thread; any bugs, continue to file a helpdesk ticket bug report, please.

There is also a fix for Mac IDE users who like to work offline, but found 2.3.7 and older releases did not always like this - if you were affected by this in 2.3.7, please do let us know if all is well (or not) now.

As ever, for more info see:
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html


"Feather" known issues (you don't need to report these, but thanks):

• Projects containing Timelines might not load in this Beta IDE unless you disable Feather first
• It's quite easy at the moment to cause the parser to fail to catch up with recent changes for a little while and so tooltips might stop appearing over your code (this might require reloading the project before it will work again).
• It doesn't support DND that much yet (other than an Execute Code node)
• It's only in English at the moment (no localisation has been done)
• It assumes the Dark skin is being used
• its Preferences panel for toggling rules does not order these rules correctly (they will change order every launch of the IDE right now)

 

[drandula]

• adding or removing breakpoint in the debug view is a pain (click issue). New in 2.3.8 (193239)

I think the clickable area is not what it should be, but only top-left quarter of it.

 

[Ricardo]

"Feather" known issues (you don't need to report these, but thanks):

• Projects containing Timelines might not load in this Beta IDE unless you disable Feather first

Is there any other known issue beside projects with Timelines? The current project I'm working on (quite big) has no Timelines but it doesn't load unless I disable Feather.
I tried to look into ui.log but couldn't find anything useful in there.

 

[Alice]

One issue I noticed with Feather: when I:
1. Create a script "definitely_function"
2. Create an object "obj_DefinitelyFunctionTest"
3. Add script_execute(definitely_function); in the object's Create event

...then I get a GM1013 error: "Reference to variable 'definitely_function' which has not been previously declared in 'obj_DefinitelyFunctionTest : Create'"

Despite Feather signalling the error, the function 'definitely_function' is executed just fine.

I plan to make a ticket for that later, once I gather other Feather oddities in a single test project, but I need to leave for a while so I decided to post this here so that others know this specific kind of error was already found.

 

[Mehdi]

I wonder what's happened to my auto-completion? It seems with "Feather" on, GMS stops to suggest auto-completion options. Am I mistaken or ... what?

Edit: It works for assets names. but not working for variable names which has been correctly initialized.

 

[gnysek]

I've got problem with loading bigger projects.
From ui.log it seems that it already loaded:

[20:01:04:208(1fb7)] Setting ProjectNameMacro to 'XXX'
[20:01:04:240(1fb7)] Loading project layout from: C:\Users\gnysek\AppData\Roaming/GameMakerStudio2-Beta\gnysek_56\Layouts\XXX\XXX\XXX.xml
[20:01:05:350(1fb7)] Loading project 'C:\Users\gnysek\Documents\GameMakerStudio2\XXX\XXX.yyp'
[20:01:05:379(1fb7)] Load project took 00:00:00.0275847

But in IDE:

So seems it crashes on something that is executed just after project files are loaded, but they are still processed by IDE to be displayed. No timelines used.


Edit: are there any new JSDoc params in this version? there's no info about it, and seems that beta doesn't download any new manual.

 

[Alice]

According to the roadmap, Find References is in beta alongside Intellisense Improvements, but I don't see this functionality yet. I tried right-clicking some constructor function names as well as the assets in asset browser, and also I checked the Edit and Tools menu in the top. Is Find References not available yet?

 

[gnysek]

Is Find References not available yet?

There's even shortcut for it (Shift+F3), but it doesn't seem to work (maybe because Shift+F3 is to find previous search result in code editor).

 

[Alice]

Alright, reported three issues I've found so far with Feather:

1. script_execute(definitely_function) in Create Event - with definitely_function being a normally named function in scr_DefinitelyFunction - will show an error:
"Reference to variable 'definitely_function' which has not been previously declared in 'obj_DefinitelyFunctionTest : Create'."
(ticket #193310)

2. Undefined can mess with type recognition in interesting ways. In particular, if a variable starts as Undefined, then its type will be the type of the last assigned variable. So e.g.

undefined_num = undefined;
undefined_num = "zzz";
undefined_num = 0;

Will appear as Real, rather than something like Mixed.
Also, variables with Enum values assigned are treated as Undefined.
(ticket #193312)

3. Arguments in static constructor functions aren't recognised as their type or something, which leads to some problematic errors:

function SoundFader() constructor {
    /// @function fader_fade_sound(_sfx)
    /// @param {Id.Sound} _sfx
    static fader_fade_sound = function(_sfx) {
        audio_sound_gain(_sfx, 0, 1000); // E GM1046 Reference to non-existent 'Resource': '_sfx'.
    }

    static fader_argid_fade_sound = function(_sfx) {
        audio_sound_gain(_sfx, 0, 1000); // E GM1046 Reference to non-existent 'Resource': '_sfx'.
    }
}

Even though SFX in the first function is shown as Id.Sound, and in the other function as ArgumentIdentity, they're still valid arguments for audio_sound_gain (unlike e.g. trying to pass a string as an audio_sound_gain argument).
(ticket #193313)

All these roughnesses aside, Feather looks awesome, with all its kinds of type hints and such. It's about as much of a breakthrough as going from JavaScript to TypeScript, and I don't even need to install NPM package with TypeScript compilers.