OFFICIAL 2.3.8 Betas Thread

[RetroBatter]

I submitted a bug report for this bug fixed in the beta runtime 434:

• In-Game: [HTML5] Creating a static array inside a constructor causes error due to unexpected extra comma in source code

But, a comma seems to still occur in the example project I submitted. Should I submit the bug report again?

 

[Stra]

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.

Did you wait for it to load completely? It seems there are very long processing times (several minutes) for large projects.

 

[gnysek]

Did you wait for it to load completely?

Yeah, when I gave 20 minutes it finally loaded. Seems that issue is caused by... extension, which have lot of code (GMLive to be precise). So games with more code for sure hangs now, but as this is beta and things would be optimized, I see no sense in reporting it, as I think that ever without that they still would work on optimizing it and it's a first public preview rather than "last chance to report bugs before going stable"

 

[Stra]

It would almost seem that as the amount of code linearly rises the processing time grows exponentially. Which is not a problem up to a minute or so, but then it begins to climb sharply.

 

[Alice]

It would almost seem that as the amount of code linearly rises the processing time grows exponentially. Which is not a problem up to a minute or so, but then it begins to climb sharply.

Maybe not outright exponentially, but I can imagine some sort of quadratic relation, possibly involving some kind of variables/assets/functions graphs and such. Hopefully the process will be optimised sometime later, or at least it'll be turned into non-blocking one.

 

[gnysek]

variables/assets/functions graphs and such

Yeah, I believe this is caused by enormous number of variables and temp vars, as references to them might be checked for every other resource. I also believe this will be optimised, that's why it's clearly said that this feature won't be included in 2022.1 but in some "future" version. Still, I believe that in 1-2 weeks it should become optimized enough to start using it in normal projects (keeping in mind that things may break and keeping backup/using git), as no matter how many wrong results it displays, it's still better than current intellisense

 

[drandula]

Just to mention here too (mentioned in Discord), that logging into Beta-version doesn't currently work, and gives this error:

Stable version works just fine, so GameMaking doesn't stop

 

[Leandro Saccoletto]

look nice the new feature , but it is crashing when I load big projects (maybe because the big qunatiy of warnings .....)
And collision issues wasn't fixed yet.

 

[Stra]

look nice the new feature , but it is crashing when I load big projects (maybe because the big qunatiy of warnings .....)
And collision issues wasn't fixed yet.

You need to wait 10+ minutes. Eventually it finishes loading.

 

[Dan]

Evening, all - that's the latest beta rolling out just now: IDE v2022.1.0.465 Runtime v2022.1.0.437

Some of you will likely be pleased to learn that this version introduces a new collisions compatibility mode toggle into Game Options > Main, so if you have an existing project which still has collision issues in this Beta, you can now enable this mode and your collisions will go back to being calculated as they were in 2.3.7.

There are also important fixes for a couple of "Apple" build targets which were not working in the last Beta.

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

And also, I missed adding information about the new Inspector mode for room layers so you can enable/configure single-layer effects which actually released in Beta IDE 464, so I have fixed that version's release notes now.

 

[Leandro Saccoletto]

"In-Game: Tile collision problems with tilemap_get_at_pixel() or bbox_* values in Jan22 Betas"

This bug wasn't solved yet. bbox_right and bbox_bottom are still 1 pixel more. And all the collision bugs that persist. But the "Collision Compatibility Mode" is working well.

"Note that we would recommend going forward that you use the newer float bounding box calculations system and generate your sprites and code accordingly, rather than always ticking this option in new projects"

I can't "going forward" if these bugs aren't my fault or I'm abusing an unexpected exploit. It doesn't make sense due the fact that I'm using integer (x,y) values, that I'm using subpixel motion (that dealt with integer part of speeds).

We need more transparency of what going on with collision logic.

 

[rwkay]

"In-Game: Tile collision problems with tilemap_get_at_pixel() or bbox_* values in Jan22 Betas"

This bug wasn't solved yet. bbox_right and bbox_bottom are still 1 pixel more. And all the collision bugs that persist. But the "Collision Compatibility Mode" is working well.

"Note that we would recommend going forward that you use the newer float bounding box calculations system and generate your sprites and code accordingly, rather than always ticking this option in new projects"

I can't "going forward" if these bugs aren't my fault or I'm abusing an unexpected exploit. It doesn't make sense due the fact that I'm using integer (x,y) values, that I'm using subpixel motion (that dealt with integer part of speeds).

We need more transparency of what going on with collision logic.

Have you selected the new option in Main to use the compatibility Collision???

Doh! just read your message properly... will edit more in a minute

The main change in the collision is that the bbox_right and bbox_bottom are now outside the box. The problem with having everything being inclusive is that as soon as scaling and rotation are applied then pixels down the right and bottom of the collision are lost as they are accumulatively lost - it works for non-scaled non-rotated collisions but does not work as things move around and it all gets more complicated.

We have changed it going forward so that if you subtract bbox_right - bbox_left = width (of the bound box) and bbox_bottom - bbox_top = height (of the bounding box).

Russell

 

[Mehdi]

new Inspector mode for room layers

Hey, the idea for layer inspector was great. Thanks. This is what I waited for.

 

[rIKmAN]

Have you selected the new option in Main to use the compatibility Collision???

Doh! just read your message properly... will edit more in a minute

The main change in the collision is that the bbox_right and bbox_bottom are now outside the box. The problem with having everything being inclusive is that as soon as scaling and rotation are applied then pixels down the right and bottom of the collision are lost as they are accumulatively lost - it works for non-scaled non-rotated collisions but does not work as things move around and it all gets more complicated.

We have changed it going forward so that if you subtract bbox_right - bbox_left = width (of the bound box) and bbox_bottom - bbox_top = height (of the bounding box).

Russell

Previously in this thread someone said they had this "off-by-1" issue accepted as a bug, but it sounds like this is now intended behaviour and the toggle has been added to switch between old/new style collisions.

Can you clarify whether that report is actually a bug or whether it's just how the new collisions will be working going forward like you've explained?
I'd assume if it was how things would now work it wouldn't have been accepted as a bug - but we know what assuming does!

Basically there's conflicting information and I've been waiting for that "fix" myself so it would be great to be able to know for sure so I (and others) can stop waiting for a fix that might never actually be happening and get some refactoring done without the worry of it changing again in the future.

 

[Mehdi]

Evening, all - that's the latest beta rolling out just now: IDE v2022.1.0.465 Runtime v2022.1.0.437

Some of you will likely be pleased to learn that this version introduces a new collisions compatibility mode toggle into Game Options > Main, so if you have an existing project which still has collision issues in this Beta, you can now enable this mode and your collisions will go back to being calculated as they were in 2.3.7.

There are also important fixes for a couple of "Apple" build targets which were not working in the last Beta.

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

And also, I missed adding information about the new Inspector mode for room layers so you can enable/configure single-layer effects which actually released in Beta IDE 464, so I have fixed that version's release notes now.

BTW, were we supposed to have new filters/effects per release?

 

[rwkay]

BTW, were we supposed to have new filters/effects per release?

No new filters and effects this release (do not expect them every release) but you did get new Single Layer Filter feature.

Russell

 

[rwkay]

Previously in this thread someone said they had this "off-by-1" issue accepted as a bug, but it sounds like this is now intended behaviour and the toggle has been added to switch between old/new style collisions.

Can you clarify whether that report is actually a bug or whether it's just how the new collisions will be working going forward like you've explained?
I'd assume if it was how things would now work it wouldn't have been accepted as a bug - but we know what assuming does!

Basically there's conflicting information and I've been waiting for that "fix" myself so it would be great to be able to know for sure so I (and others) can stop waiting for a fix that might never actually be happening and get some refactoring done without the worry of it changing again in the future.

OK so to clarify going forward collisions will be as I have explained - we will be releasing more information in the future (and we will update documentation too) we are going to change the wording of the responses on bugs as what happens is that you submit bugs that then goes to our frontline CS team and they assess if this something that they can deal with or it needs to be passed onto QA (who then work out if the CoreTech team need to look at it) so the response you are getting is not that it is a bug, but that it has been passed on. Now this process changed in the last 3 months to improve response time, but I don't think the macro for responding was updated - we will address this going forward.

The "fix" for this is us adding the compatibility collision flag to Main Options as that will return behaviour to the old method (including the problems with scaling and rotation that are inherit to that).

We will need to get Shaun to update his collision code now....

Russell

 

[Mehdi]

but you did get new Single Layer Filter feature

And that's a lovely one!

 

[rIKmAN]

OK so to clarify going forward collisions will be as I have explained - we will be releasing more information in the future (and we will update documentation too) we are going to change the wording of the responses on bugs as what happens is that you submit bugs that then goes to our frontline CS team and they assess if this something that they can deal with or it needs to be passed onto QA (who then work out if the CoreTech team need to look at it) so the response you are getting is not that it is a bug, but that it has been passed on. Now this process changed in the last 3 months to improve response time, but I don't think the macro for responding was updated - we will address this going forward.

The "fix" for this is us adding the compatibility collision flag to Main Options as that will return behaviour to the old method (including the problems with scaling and rotation that are inherit to that).

Brilliant, thanks for clarifying that as the mixed information from different sources made it confusing as to what was actually the intended behaviour and what might actually a bug that was due to be fixed/rolled back. The new toggle is a good middle ground.

We will need to get Shaun to update his collision code now....

Yeah the server creaks daily as it is and if he doesn't it might just crash and catch fire from all the posts that are going to be made about peoples platformers not working properly!

 

[Amon]

@rwkay So, I heard the next official platformer tutorial will be an upgrade to shauns featuring working slope collisions.

Thanks!

 

[Leandro Saccoletto]

Have you selected the new option in Main to use the compatibility Collision???

Doh! just read your message properly... will edit more in a minute

The main change in the collision is that the bbox_right and bbox_bottom are now outside the box. The problem with having everything being inclusive is that as soon as scaling and rotation are applied then pixels down the right and bottom of the collision are lost as they are accumulatively lost - it works for non-scaled non-rotated collisions but does not work as things move around and it all gets more complicated.

We have changed it going forward so that if you subtract bbox_right - bbox_left = width (of the bound box) and bbox_bottom - bbox_top = height (of the bounding box).

Russell

First , thanks for your explanation. Despite this change can be "annoying" depending of how complex the project (luckly I use custom function , so I just need samller changes).

But still remains a problem that I'm not sure that is a "bug" or a "change".
When use position_meeting() , instance_position(), collision_point(), collision_line() (and other that uses a "position") , it can gives "false collision" if I use x = bbox_left or y = bbox_top.

So I'm thinking that using bbox_left/bbox_top of object1 (for example) interact with bbox_right/bbox_bottom of object2 (that is side-by-side with object 1).
So the solution is using bbox_left +1 and bbox_top + 1 for now on ? Or need more things ?

I'm getting confused .....

 

[gnysek]

Yeah, I've got at least 3 times answer from helpdesk that my report is a bug indeed, and then got answer few hours later here on forums, that it's not.

New docs for collisions are very welcome, as that change for bboxes seems to be a critical one. Of course there's a special checkbox to use "old" system (which is a good solution), but would be good to properly learn new system and use it in future, as it's not good habit to stay with old solutions forever. For now - I'm also confused with new system, as for position_ and place_ functions it returned different results for bbox_right and bbox_bottom (1px offset depending on which group of functions is used).

 

[Amon]

I got the same. I reported a bug with collisions, submitted an example, got a reply that it was reproducible and a confirmed bug, then a reply a few days later saying it was not a bug and to they couldn't reproduce it.

I'd just like to say that this is not the first time this has happened; it's happened with other bug reports I've submitted and it is really frustrating when you are told it's reproducible and bug then a few days later they contradict themselves and claim something different asking for more reproducible examples, which I provide and then the same thing happens.

Until this behaviour is eradicated I'm not submitting any more bug reports.

 

[Slyddar]

Some of you will likely be pleased to learn that this version introduces a new collisions compatibility mode toggle into Game Options > Main, so if you have an existing project which still has collision issues in this Beta, you can now enable this mode and your collisions will go back to being calculated as they were in 2.3.7.

This should be enabled by default when importing older projects, but show a prompt advising of the change. As I mentioned in my previous post on the issue, for users who don't know about it, their tile collisions may stop working as expected, and they will have no idea why.

 

[Zhanghua]

Where is the effect single layer setting??
And the function seems no effect in runtime.

fx_set_single_layer(layer_get_fx("Effect_1"),true);

 

[rwkay]

Where is the effect single layer setting??
And the function seems no effect in runtime.

fx_set_single_layer(layer_get_fx("Effect_1"),true);

View attachment 45492

First of all the single layer effect makes no sense to add it to a layer that is already an effect layer you should add it to one of the other layers like "Instances", you need to open the Inspector Window and when you select a layer you will see that in the Inspector each layer has a Filter section, use that to apply a filter to any layer.

Russell

 

[Leandro Saccoletto]

The Compatibility Collision Mode is "incomplete". Here I attached gifs , where you check the bettle's red outline (the bettle that you need see is the one that moves in the ceil).
The red outline is the collision box and should move with terrain/slopes. And the bettle sprite is just drawn , considering some factors (doesn't have collision).

--> at bettle423 , it uses runtime 423 , with the correct behaviour. The red outline moves with the slope.
--> at bettle437, it uses runtime 437 , with wrong behaviour (in both cases that I turn on or off "Compatibility Collision Mode"). The red outline moves in a straight line, ignoring the slope.

 

[Amon]

I have submitted a bug report regarding this. It only started happening with the introduction into GMS2 of the Feather feature. I have excluded the working directory i.e. projects directories and the install directory from the Antivirus which is just the antivirus and firewall that comes with Windows 11. Please understand that this did not happen on any version of GMS2 before the one that shipped with Feather.

 

[rwkay]

The Compatibility Collision Mode is "incomplete". Here I attached gifs , where you check the bettle's red outline (the bettle that you need see is the one that moves in the ceil).
The red outline is the collision box and should move with terrain/slopes. And the bettle sprite is just drawn , considering some factors (doesn't have collision).

--> at bettle423 , it uses runtime 423 , with the correct behaviour. The red outline moves with the slope.
--> at bettle437, it uses runtime 437 , with wrong behaviour (in both cases that I turn on or off "Compatibility Collision Mode"). The red outline moves in a straight line, ignoring the slope.

File a bug with an example project please.

Russell

 

[Mehdi]

I've encountered what seems a bug to me. (about Filters & Effects)

When you add an "Underwater" filter to the room, and slide the following parameters down to 0:
Distort 1 Speed,
Distort 2 Speed,
Distort 1 Scale 1,
Distort 1 Scale 2,
Distort 2 Scale 1,
Distort 2 Scale 2,
Chroma Spread
the animation of water stops (and those white ribbons also leave)

However when you do the exact thing in GML, although the animation stops, but the white wavy ribbons will not get removed.

Should I file a bug?

 

[Leandro Saccoletto]

The Compatibility Collision Mode is "incomplete". Here I attached gifs , where you check the bettle's red outline (the bettle that you need see is the one that moves in the ceil).
The red outline is the collision box and should move with terrain/slopes. And the bettle sprite is just drawn , considering some factors (doesn't have collision).

--> at bettle423 , it uses runtime 423 , with the correct behaviour. The red outline moves with the slope.
--> at bettle437, it uses runtime 437 , with wrong behaviour (in both cases that I turn on or off "Compatibility Collision Mode"). The red outline moves in a straight line, ignoring the slope.

Sadly I can't file a bug report.
1 - I try to do reproduce thebug in a minimal project.
2 - the main project has many stuff that I wasn't allowed to shared due copyright.

But I figured out. If I shifted 1 pixel of rotated rectangle (bbox mode "Rectangle with rotation") (that was rotated at room editor), the enemy move correctly over slope. And if I use a triangle slope (without rotation) it works too.
So my thoughts is that rotated rectangle can have different "collision shape" math changes after runtime 423 and wasn't considered at compatibility mode.

Does someone notice something different with collisions of rotated objects ?

 

[EmperorHouse]

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?)

Maybe you can answer a question on my mind since I can't find a good answer in the other threads.

I'm trying to understand how variable definitions, instance_change, the create event, and now this pre-create event all tie together. I've tried to use instance_change to become child objects, such as when their data would stay the same but they need the functionality of the new object. I ran into a problem when the variables I created, even inside the variable definitions editor, were overwritten with their default values when the instance_change function was called with the create/destroy event perform parameter set to true. When I was learning to use creation code, I was under the impression this shouldn't happen. This makes me think that the variable definitions occur at the same time as the create event. It could also be that the destroy call erased all existing values of the instance, but that sort of defeats the point of using instance change in the first place.

I also wonder when this pre-create event might execute in the instance lifecycle. Do you think it would occur before the instance creation code? Would the variable definitions be rewritten to execute prior to this event instead? There are values that I would like to retain that I thought could be done with the nullish operator ??= and ternaries x = a ? b : c for empty strings and the like. Then I would get any overridden method behaviors I want while retaining desired instance members. I've only been able to retain values when the destroy/creation parameter is left false, which hamstrings some convenience and forces me to make manual checks for nullish and nonexistent variables.

How will pre-create help in this regard? Is there any way that existing instance creation functionality can be used to fix this?

 

[Zhanghua]

#ticket 193561

https://yoyogames.zendesk.com/attachments/token/l0T4esVsbz1yFxFAnZ6qw8oVc/?name=extension+can%27t+change.mkv

In the latest beta, the project prompts up the "Save or Reload" frequently after altering the extension.

Following is the empty project and create a extension and create an generic holder...

After this, I can't saving the project...

 

[gnysek]

You can enable automatic reloading of files without prompt in options, sometimes it's useful (not for every case).

 

[Dan]

#ticket 193561
In the latest beta, the project prompts up the "Save or Reload" frequently after altering the extension.
After this, I can't saving the project...

Thanks, we'll look into this one asap.


EDIT: One of the other staff members found and filed it already, so we will fix this asap

 

[Dan]

That's IDE v2022.100.0.468 Runtime v2022.100.0.443 rolling out now.

Other than a tweak to the Beta version naming convention (to use a "release" of 100 each time), this one is all about a few stability and platform-building fixes in the runtime (which I pasted below for you all, as the IDE notes say no changes and to please see the runtime notes):

Changes Since Beta Runtime 437

• Building Projects: [Mac IDE] macOS builds fail with error 'Cannot find File "/tmp/GameMakerStudio2/GMS2TEMP/[some file name]"'
• Building Projects: [iOS YYC] Fails with "clang: error: unable to make temporary file"
• Building Projects: OperaGX build fail if the project is called specifically "game"
• Building Projects: Exception while building projects containing filter layers set to none in the Room Editor, "Could not find part of path '....\none.yyp'" [only possible in IDE 464 and 465]
• In-Game: Blocking connections to local TCP server fail in Jan22 Betas since websockets support was added

This should be the final Beta before Stable, so again a big thank-you from all of us to everyone who gave feedback and bug reports this month-and-a-bit.

 

[Alice]

Just to be sure, have there been some improvements/fixes to the Feather functionality not mentioned in the release notes?
I don't see anything about Feather in this and the previous beta release notes, but I vaguely recall mentions of Feather optimisations introduced in the previous beta, so I wonder if there were some Feather fixes in this beta as well.

 

[rwkay]

Just to be sure, have there been some improvements/fixes to the Feather functionality not mentioned in the release notes?
I don't see anything about Feather in this and the previous beta release notes, but I vaguely recall mentions of Feather optimisations introduced in the previous beta, so I wonder if there were some Feather fixes in this beta as well.

Feather has had a few fixes but the larger optimizations are underway but the fruit of that labour has not been delivered yet.

Russell

 

[Dan]

Yes, there were some - I have now dug deeper into exactly what they were, so here you go...


Beta 9
Feather: General scoping problems with methods/constructors/inheritance
Feather: No auto-complete suggestions are shown for named functions after their dot is typed
Feather: Overlapping tooltips can occur for autocomplete, JS doc content, and rules [there is an improvement for this one, but not the final fix]
Feather: Cannot call functions directly off a new expression (e.g. new CtorFunc().func())
Feather: Various fixes for pure functions and matrices - this one affected a LOT of functions, so I am not going to list them all here, but there are some specific ones which changed in a more visible manner:
camera_get_proj_mat(), camera_get_view_mat(), camera_set_proj_mat(), and camera_set_view_mat() all have a returnType now of "array"
vertex_submit() now also allows passing in a real for its texture
network_set_config() now expects a constant for a specific network configuration, rather than a generic string
network_set_timeout()'s "type" value now expects a Constant.ExternalArgumentType value
fx_set_parameter()'s "type" now expects a real or any array, rather than a string or an array
And we fixed the two in-built constants "dll_cdecl" and "dll_stdcall" so their class is given as "ExternalCallType" rather than "ExternalCall"



Beta 10
Code Editor: Calling an inherited constructor which has optional args will throw error if you try to call it via ,, to skip an arg [note that this is only fixed in this version if Feather is enabled - if Feather is disabled, then the fix for that bit is coming in the first Feb beta]
Feather: "Feather Messages" window reappears, but is empty when Feather is disabled but opened a project which previously had Feather enabled in
Feather: Weak reference struct's "ref" variable is not detected as a built-in variable
Feather: Allow for a rule's severity to be changed from right-click context menu in Feather Messages window
Feather: Images in the Feather Messages "Resource" column are low quality [also fixed a memory leak caused by how Feather was loading these images]
Feather: Dependency Walker debug text is still enabled in the Output panel
Feather: Error trying to call function stored in variable, even though it correctly infers the variable as a function
Feather: Unexpected errors GM1046 "Reference to non-existent 'Resource'" when checking arguments in static constructor functions
Feather: Calling functions by extra brackets on the return value of another gives unexpected error "GM1053 The left hand side cannot be called in this way." - e.g. "variable_struct_get(...)();"
Preferences: Incorrect heading for Feather's Room Naming Rules - currently just says "Room"
Preferences: [Feather] Changing colours on the highlighting panel does not take effect until project is reopened
Preferences: [Feather] "color" in Highlighting preferences should be in UK English to match rest of the IDE
Preferences: Feather's "Message Severity" settings are always shown in random order
Fixed structs not adding fields through [$ operator.
Fixed incorrect marking of 'return types differ'.
Fixed array types not marking their types correctly for subsequent assignments
path_start()'s "endaction" argument was expecting an incorrect type
effect_create_above()'s "kind" argument was expecting an incorrect type

 

[gnysek]

Wow, there's ton of updates for Feather! As I understand, they aren't mentioned in release notes because this feature doesn't comes in 2022.1 (and have no deadline for any version yet), so it's to not mislead anyone for pre-stable beta? Thanks for writing list of fixes here on forums then!

Also, as this was mentioned in topic about 2022.1, but in fact is available only in beta version and won't be yet on stable I will re-post post by Zach, which mentions few JS Docs params which might be helpful when testing above changes in 2022.200 beta :

/// @desc Description
/// @description Description
/// @param {type} name description
/// @paramter, @arg, @argument also work
/// @ignore
/// @deprecated
/// @context {FUNCTION_NAME or OBJECT_NAME or CTOR_FUNCTION_NAME}
/// @returns {type}

/**
* this is
* a multiline description
* @param {string} name
*   description on this line!
* ...
*/

Square brackets denote optional
Name as ... denotes infinite arguments afterwards
Default values specified with = sign in name e.g @param {string} [name="wow"] The name

 

[Stra]

Anyone clocked any feather speed improvements? My project remains at 3 mins loading time, no change detected.

 

[gnysek]

I've tried to use /// @ignore for biggest scripts, but it's either not working nor I know how to properly use it. I've also tried with // Feather disable once GM1021 which was some auto-generated comment when pressing Ctrl+Q, and there's no difference. 20-30 minutes of loading in my case.

 

[rwkay]

Anyone clocked any feather speed improvements? My project remains at 3 mins loading time, no change detected.

Some minor optimisations were made to Feather but the larger effort is underway now and we should start to see the fruits of that in the next Beta (which will be next Tuesday now, as Stable will be this Thursday)

Russell

 

[Mehdi]

Stable will be this Thursday

 

[Dan]

The Stable release thread is now available, so I will lock and move this thread now. If you do have a Feather bug to report in the short period before the next Beta thread is started next week, send us a ticket as usual - thanks.

As ever, a big thank-you from all of us to everyone who gave feedback and bug reports this extended Beta phase.