OFFICIAL 2.3.7 Betas Thread

Status
Not open for further replies.

Dan

YoYo Games Staff
YYG Staff
Beta 5 is rolling out now (IDE v23.1.1.428 Runtime v23.1.1.407).

This one has an important change in that the GMS in-built "true" and "false" values are actually now of type Boolean, rather than Number as they have been in all previous releases. You may need to edit your projects to compensate.

There is also a fix for iOS builds being unable to find the package once it has been built (only an issue if you are not using the suppressed Preference) and we have now added a helper warning dialog if you try to build a project containing old-format Spine sprites you need to re-export now.

See the release notes threads for specifics.
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html


(And before anyone says it, I have no idea what happened here, but it's my fault and I will fix it for the next Beta ;) )
1636647997196.png
 

drandula

Member
Oh that boolean change came fast, just yesterday I heard about it in Discord :D
Btw, IDE release notes seems to still show tuesdays notes ^^"
 
Last edited:

Mehdi

Member
Beta 5 is rolling out now (IDE v23.1.1.428 Runtime v23.1.1.407).

This one has an important change in that the GMS in-built "true" and "false" values are actually now of type Boolean, rather than Number as they have been in all previous releases. You may need to edit your projects to compensate.

There is also a fix for iOS builds being unable to find the package once it has been built (only an issue if you are not using the suppressed Preference) and we have now added a helper warning dialog if you try to build a project containing old-format Spine sprites you need to re-export now.

See the release notes threads for specifics.
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html


(And before anyone says it, I have no idea what happened here, but it's my fault and I will fix it for the next Beta ;) )
View attachment 44239
Thanks @Dan.
 

gnysek

Member
GMS in-built "true" and "false" values are actually now of type Boolean
But true is still for values >= 0.5, false is < 0.5 and nothing changed here?
But true is still for values > 0.5, false is <= 0.5 and nothing changed here?
 
Last edited:

FoxyOfJungle

Kazan Games
Interesting! 🙂

Function calls can now be made with missing arguments, these are then passed as undefined and either optional arguments or the called function can handle that.

I.e. you can now write MyFunctionCall(1,2,,,5) and get the same result as if you had written MyFunctionCall(1, 2, undefined, undefined, 5)
In-Game: [HTML5] layer_script_begin/end receive incorrect event_type and event_number values
I'm happy about it, I'll test it later to see if it works in my project. Thanks.
 
Are there any plans to offer an option to stay on an older spine runtime? Our project has hundreds of spine files and I am worried that the updated spine version might not function exactly the same. We take advantage of a lot of spine features and specifics of how the GMS engine was handling them. Converting over all those files will take a very long time. Additionally to verify that they all work as expected will take a long time.
 

gnysek

Member
I always tought that true > 0, and false <= 0
That's right, as it seems that on boolean comparisons numbers are rounded to integers in GML (using built-in round()). However, since GMS uses bankers rounding instead of nearest integer rounding, so it rounds 0.5 to closest even number, to being exactly perfect, seems that true is everything greater than 0.5, not greather and equal (as zero is even number). I've fixed my initial post.


*shudders*
Yeah, in most of programming languages false is 0, and true is != 0. However changing it in GML would kill many projects :p I think that if that could be even changed, it should be at point where = and == inside "if" also would be updated (so = would assign value to variable and return true only if that value is !=0, and only == would compare values). Both of those changes would be the most breaking change in GML ever.
 
Last edited:

Xennroth

Member
it should be at point where = and == inside "if" also would be updated (so = would assign value to variable and return true only if that value is !=0, and only == would compare values). Both of those changes would be the most breaking change in GML ever.
those would definitely break some projects :D but on the other hand, that kind of change would bring gml syntax closer to mainstream syntax (c++, c# etc.) (which i think would be a good change)

another one that is worth noting is ; at end of every function, at the moment gml does not need it unless you use more than 1 function on 1 line (c languages need it always to let the compiler know the function has ended)
gml:
Code:
// ok
foobar = 1
do_stuff()

// not ok
foobar = 1 do_stuff()

// ok
foobar=1; do_stuff();

but good info about the 0.5, i did not know that about gml 😊 👍
 

Samuel Venable

Time Killer
Just noticed this, under fixed bugs, literally first on the list:
  • armv7 and aarch64 extension library suffix name clash
Thank you very much guys!! :D
 
Last edited:
I'm having issues with compiling using the Ubuntu IDE. I have both the latest beta runtime and IDE, but when I try to build it throw a NullReferenceException from `YoYoStudio.Resources.ProjectManager+<>c__DisplayClass16_1,Void <SaveProject>b__3(). I've uploaded the whole log to https://pastebin.com/rRP3CD8g. When running GameMaker Studio 2 Beta with the sudo command it gives the same result.
 

rwkay

YoYo Games Staff
YYG Staff
I'm having issues with compiling using the Ubuntu IDE. I have both the latest beta runtime and IDE, but when I try to build it throw a NullReferenceException from `YoYoStudio.Resources.ProjectManager+<>c__DisplayClass16_1,Void <SaveProject>b__3(). I've uploaded the whole log to https://pastebin.com/rRP3CD8g. When running GameMaker Studio 2 Beta with the sudo command it gives the same result.
Please file a bug report (Help -> Report a bug) these forums are not monitored for bug reports

Russell
 

Ricardo

Member
@rwkay is there a known bug or is it normal that the Mac IDE takes a lot longer to run a project when compared to Windows?
I have a project that once built (so using cache) takes around 10 seconds to start on my Windows dev machine (Ryzen 5800x). That same project takes around 01:15 to run using the latest Beta on a brand new Macbook Pro (the 10 core variant) which is really frustrating. It gets stuck at "STRG" most of the time;
 
Last edited:

Dan

YoYo Games Staff
YYG Staff
It's not normal, no, but coincidentally one of my team did file a very similar thing last week, where a certain very large project would build fine on Windows IDE but on Mac IDE it would get stuck on the SPRT stage cos it basically clogged up the Mac in some way... I would suspect your project is large enough to see the issue, but not quite large enough to get completely stuck like the one we used to confirm the issue.
 

Dan

YoYo Games Staff
YYG Staff
Beta 6 is rolling out now (IDE v23.1.1.429 Runtime v23.1.1.408).

This one is quite a nice stability release, as it fixes a small stack of IDE crashes/hangs, including some "random" ones users had reported tickets for, and resolves an SSO licensing issue which might have been causing you to be logged-out far too frequently.

Added a new setting into the Font Editor options window to say if you want to use the kerning info in the font or not. Added a compression stage into Opera GX packaging, so now your uploads will take a little longer to build, but results in smaller uploads for you / downloads for your players.

As ever, full notes at:
https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html
 

gnysek

Member
Runtime v23.1.1.408 still have issue with forcing 9-slice offset to be 0,0, for draw_sprite_stretched/draw_sprite_stretched_ext .
 

Ricardo

Member
It's not normal, no, but coincidentally one of my team did file a very similar thing last week, where a certain very large project would build fine on Windows IDE but on Mac IDE it would get stuck on the SPRT stage cos it basically clogged up the Mac in some way... I would suspect your project is large enough to see the issue, but not quite large enough to get completely stuck like the one we used to confirm the issue.
Yeah, it's a big one. For me it gets stuck at STRG. I can't spot any other step holding the building for long enough to feel suspicious. Btw, I just re-checked this using Beta 6.
 

Dan

YoYo Games Staff
YYG Staff
Runtime v23.1.1.408 still have issue with forcing 9-slice offset to be 0,0, for draw_sprite_stretched/draw_sprite_stretched_ext .
I just went and investigated this one after seeing your reply. I can see your recent bug report was initially confirmed and added to the db, but actually it came back as not a bug and that this was a deliberate recent fix to make the function work with nine slice sprites the same way that it does with other sprite types - the manual page for draw_sprite_stretched() has always said the origin values on a sprite will be ignored if you use either of these functions.

Apologies you did not get that feedback via your ticket, but this isn't one we will change now, as it now all works as documented.

However, I can see we didn't copy/paste that same line to the page for draw_stretched_ext(), so I will bug that for the Docs team to fix ;)
 

Dan

YoYo Games Staff
YYG Staff
Yeah, it's a big one. For me it gets stuck at STRG. I can't spot any other step holding the building for long enough to feel suspicious. Btw, I just re-checked this using Beta 6.
I have added your info here onto the existing bug report now, but it might be worth you sending us that project via a ticket anyway and the dev can confirm it here.
 
Are there any plans to offer an option to stay on an older spine runtime? Our project has hundreds of spine files and I am worried that the updated spine version might not function exactly the same. We take advantage of a lot of spine features and specifics of how the GMS engine was handling them. Converting over all those files will take a very long time. Additionally to verify that they all work as expected will take a long time.
Sorry to be a pest. We'll be version locked if this isn't otherwise addressed. Any feedback would be appreciated!
 

gnysek

Member
Are there any plans to offer an option to stay on an older spine runtime?
From release notes it seems there will be no option like this:
Beta IDE 423
Spine 4.0
- With this update to use Spine 4.0 existing projects using older Spine files will no longer run
- You will need to get Spine 4.0 and re-export any Spine assets for your projects
 

rwkay

YoYo Games Staff
YYG Staff
From release notes it seems there will be no option like this:
I am afraid that Spine runtime itself does not allow for multiple versions AND Esoteric are quire resistant to any idea that they should be. (we have complained to them multiple times about this)

Russell
 

Samuel Venable

Time Killer
I am afraid that Spine runtime itself does not allow for multiple versions AND Esoteric are quire resistant to any idea that they should be. (we have complained to them multiple times about this)

Russell
Imagine needing to provide duplicate runners for every spine runtime on every platform lol
 

gnysek

Member
Has no info on latest beta 408
Sometimes pressing Ctrl+R is required on release note page :) (you should see "Changes Since Beta Runtime 407" beta).

Going back to Spine, from what I remember it have preference to run older versions (or just allows to run separate versions side by side?), however there's so many not backward-compatible changes every few versions, that supporting more at once for sure would be problematic (it would be even hard to choose which ones to support):
1637102181837.png
 
Last edited:

Mert

Member
1637102569040.png


The Filter Layers are absolutely beautiful, loved it <3
However, it cannot detect soft-body particles draw functions (physics_particle_draw)
Edit : Found the issue, also found how to do some cool tricks with it. My mistake, sorry.

(A side note, I tried to file a bug about it but couldn't somehow. In the last step, it asks something like we may ask you for sample etc. Pressed the green Yes button didn't do anything.)
 
Last edited:

gnysek

Member
I've reported bug with new nullish operator, seems that it crashes on ds_maps and ds_list accessors (however works OK when their values are accessed by functions):

GML:
// OK
show_debug_message(ds_list_find_value(list, 1) ?? "not found");
show_debug_message(ds_map_find_value(map, "test") ?? "not found");

// crash: trying to index a variable which is not an array
show_debug_message(list[| 1] ?? "not found");
// crash: unable to convert string "test" to int64
show_debug_message(map[? "test"] ?? "not found");
(complete example attached to report)
 
I am afraid that Spine runtime itself does not allow for multiple versions AND Esoteric are quire resistant to any idea that they should be. (we have complained to them multiple times about this)

Russell
Thanks for getting back to me Russell! Ideally, I'd like to be able to select an older runtime as opposed to running multiple in parallel.
 

rwkay

YoYo Games Staff
YYG Staff
Thanks for getting back to me Russell! Ideally, I'd like to be able to select an older runtime as opposed to running multiple in parallel.
That is not possible we can only support a single Esoteric runtime at a time.

Russell
 

Ricardo

Member
I have added your info here onto the existing bug report now, but it might be worth you sending us that project via a ticket anyway and the dev can confirm it here.
Hey @Dan, I've managed to isolate the issue but it is not feasible to fill a bug. Please allow me to elaborate:
This doesn't seem to be an issue with my specific project, but with the cache and a huge number of included files.

Steps to reproduce:
(Using Mac IDE in Beta 6 )
- Add a huge number of included files (around 1 GB or so. In my project we have hundreds of images and audio files) to a project;
- Clear Cache;
- Run it (VM) and notice the amount of time it'll take to build;
- Close the game;
- Run it again;
- Notice it'll take a lot of time to run (almost the same as the first time) and it'll get stuck at "STRG" (to me this seems like the Mac IDE is not properly using the cache and copying all the included files again)

- Repeat the same steps in Windows IDE;
- Notice the second run takes a fraction of the first run, proving that the cache is working as expected.
 

rwkay

YoYo Games Staff
YYG Staff
Hey @Dan, I've managed to isolate the issue but it is not feasible to fill a bug. Please allow me to elaborate:
This doesn't seem to be an issue with my specific project, but with the cache and a huge number of included files.

Steps to reproduce:
(Using Mac IDE in Beta 6 )
- Add a huge number of included files (around 1 GB or so. In my project we have hundreds of images and audio files) to a project;
- Clear Cache;
- Run it (VM) and notice the amount of time it'll take to build;
- Close the game;
- Run it again;
- Notice it'll take a lot of time to run (almost the same as the first time) and it'll get stuck at "STRG" (to me this seems like the Mac IDE is not properly using the cache and copying all the included files again)

- Repeat the same steps in Windows IDE;
- Notice the second run takes a fraction of the first run, proving that the cache is working as expected.
Can you please check on your mac machine that you have the GMS TEMP,Asset cache and IDE cache path pointing at a valid location (see Preferences -> General Settings -> Paths ) as I have just checked here an the asset caching is working for me, and that is the only thing I can think of that would through it off.

Russell
 

Ricardo

Member
Can you please check on your mac machine that you have the GMS TEMP,Asset cache and IDE cache path pointing at a valid location (see Preferences -> General Settings -> Paths ) as I have just checked here an the asset caching is working for me, and that is the only thing I can think of that would through it off.

Russell
Hey Russell, thanks for looking into it. Yes, the all the paths in there are valid (are default, I never touched them). I can use Finder to navigate there, no problem. I went ahead and flushed all the content there to make other tests and still no luck.
I can notice that the cache indeed works (in projects with little or no included files). The issue I'm reporting seems to be related to projects with huge numbers of included files as detailed in my previous post so maybe I made a wrong assumption thinking it has anything to do with the "cache".
 

rwkay

YoYo Games Staff
YYG Staff
Hey Russell, thanks for looking into it. Yes, the all the paths in there are valid (are default, I never touched them). I can use Finder to navigate there, no problem. I went ahead and flushed all the content there to make other tests and still no luck.
I can notice that the cache indeed works (in projects with little or no included files). The issue I'm reporting seems to be related to projects with huge numbers of included files as detailed in my previous post so maybe I made a wrong assumption thinking it has anything to do with the "cache".
Is suspect it is not cache related then as the included files will be copied each time - it may just be an inefficiency in how we are copying the files on the Mac and it is somehow taking a long time, please file a bug with a project so we can invesitgate.

Thanks

Russell
 

Ricardo

Member
Is suspect it is not cache related then as the included files will be copied each time - it may just be an inefficiency in how we are copying the files on the Mac and it is somehow taking a long time, please file a bug with a project so we can invesitgate.

Thanks

Russell
I've created a sample project that demonstrates the issue (ticket 191110). Thanks.
 

Mehdi

Member
Is it bug or I missed something? Why object marked as invisible in sequence still draw itself and GUI in game?
The Eye icon in there does not mean invisibility in room. It just makes the asset invisible in editing time for the dev to easier work with other channels and etc.
 

gnysek

Member
The Eye icon in there does not mean invisibility in room.
it means, as per manual:
If you disable the visibility of the track, then it will not be shown when the sequence is run in a room, nor will it be shown in the sequence canvas while testing, and toggling the visibility of an asset track will also toggle the visibility of its parameter tracks.
Link to manual:
I've checked it before reporting as a bug to be sure.
 

ScottD

New Member
YYG Staff
Beta 7 is currently going live. IDE v23.1.1.431 Runtime v23.1.1.409

We have optimised project loading, specifically with regards to generating the AssetBrowser images. So you should see a significant improvement in IDE project load times. If you see any project loading issues do please report a bug and be sure to include your project.

Please see the release notes for the full list of changes.

https://gms.yoyogames.com/ReleaseNotes-NuBeta.html
https://gms.yoyogames.com/release-notes-runtime-NuBeta.html
 
That is not possible we can only support a single Esoteric runtime at a time.

Russell
For a game that's been in development for sometime under the 3.7 runtime, we will be stuck and unable to move forward. We can't build the game until every sprite is converted over. We have thousands of sprites that we have been using, which are complex. We have no guaranteed that the new runtime will function exactly the same way and we can't test a single sprite, instead we have to reimport all of them. The amount of time that is required on engineering to do this task is large. Additionally the QA requirement to test every sprite is also large.

Support can't be added to have the option to choose which Esoteric runtime to use?
I'm afraid this is going to leave us stuck on the current runtime moving forward.
 

rwkay

YoYo Games Staff
YYG Staff
For a game that's been in development for sometime under the 3.7 runtime, we will be stuck and unable to move forward. We can't build the game until every sprite is converted over. We have thousands of sprites that we have been using, which are complex. We have no guaranteed that the new runtime will function exactly the same way and we can't test a single sprite, instead we have to reimport all of them. The amount of time that is required on engineering to do this task is large. Additionally the QA requirement to test every sprite is also large.

Support can't be added to have the option to choose which Esoteric runtime to use?
I'm afraid this is going to leave us stuck on the current runtime moving forward.
Complain to Esoteric - we have multiple times

Russell
 

Ricardo

Member
very nice 👍

Is this compression in windows exports too?
Sure thing. Just add gml_pragma ("PNGCrush") to any part of your project (It is processed on compiling time, so it doesn't matter where you put it).
Afterward, just clear the cache and build. You'll be able to see PNGCrush status in the compiler log.
Take into consideration that this could significantly increase building time depending on the number of sprites. Also, unfortunately, the compression savings are usually quite lame most of the time.
 
Hi,
i'm having issues with true/false when sometimes is recognized as 0 or 1 also if is declared as false at the beginning.

Create event
global.myVar = false;

Now set the global.myVar = true; from another object. The debugger recognize it as 1 not TRUE

Step Event
If (global.myVar==true) //here is not working it doesn't enter the if because myVar is 1 and not TRUE

EDIT:
This happened because in another object the variable is set to 1, so the type seems to be changed. Is it normal ?
 
Last edited:

Dan

YoYo Games Staff
YYG Staff
This happened because in another object the variable is set to 1, so the type seems to be changed. Is it normal ?
This is one of the release notes changes we called out for these Betas and right now I cannot reproduce any bug here. If you do think there is a bug happening, then please file a ticket with a small sample showing just your relevant global.myVar stuff, as the following all works fine for me (you will get true, true, 1, 1):

Object1 Create:
GML:
global.myGlob = false;
myVar = false;

alarm[0] = game_get_speed(gamespeed_fps);
Object1 Alarm0
GML:
with (Object2)
{
    global.myGlob = true;
    other.myVar = true;
}
Object1 Draw GUI
GML:
if (global.myGlob == true) { draw_text(20, 20, "global.myGlob equals true"); }
else { draw_text(20, 20, "global.myGlob equals false"); }

if (myVar == true) { draw_text(20, 40, "myVar equals true"); }
else { draw_text(20, 40, "myVar equals false"); }


var testTrue = is_bool(true);
var testFalse = is_bool(false);
draw_text(20, 80, "testTrue equals " + string(testTrue) + ", testFalse equals " + string(testFalse));


(Object2 has no content - it's just an empty object added to the room along with Object 1.)

I also checked without the with() and I get the same results.
 
Status
Not open for further replies.
Top