NEW : (#7264 ) Factory dynamic prototype
NEW : (#7029 ) Add timer.get_info() function
NEW : (#6902 ) Shader include support
Especially for these 3 items. This release will be impressive… Wow
That factory feature made my day!
No I’m afraid not. My ambition was that we would be able to ship a few of them, but unfortunately a lot of work got delayed. Is there any issues in particular that you think of?
Amazing! 
Thank you for adding documentation for this too! (even though it’s beta, but I hope it won’t confuse anyone in the upcoming two weeks 
)
Edit: The note there should point to 1.4.3, right?
Ah yes, that’s true, thanks!
https://github.com/defold/defold/issues/6789 has been active (i.e. todo in multiple releases) for a while
Will this enable the work to detect modern Android “back” swipe gestures?
Updated SDK unblocks this task (can’t be implemented without using the latest SDK).
So, yes we gonna implement the Android 13 Back gesture, but I can’t give you any time estimations.
These kinds of errors are tricky. I wasn’t able to reproduce it on any of my phones which makes it hard to fix.
I asked for some extra data from you, which might be helpful (pls take a look the ticket)
As you know we’ve spent quite a bit of time trying to solve the issue without success. I’ve kept adding it to each release project to not forget about it.
Hmm. Until now, we needed separate factory components for each object or collection. In what scenarios would it be advisable to use the dynamic setting over the static setting? I don’t really understand the tradeoffs.
I would say that using separate factory components will still be the most common usecase and the one recommended for almost every scenario.
If you have a lot of different game object or collection prototypes in your game (perhaps downloaded using Liveupdate) but you only ever need to spawn one of them then it might simplify your code and your resource management if you only have a single factory component and set which prototype it should spawn.
@britzl is it advisable to use once collection factory to spawn an object, then change the collection and spawn another? This would happen before the screen fades in.
I wouldn’t recommend such usage of the feature.
Our build system counts components in a world (the collection spawned using collection proxy).
If some component’s count is static - then this collection will allocate this exact amount of memory, if some components are dynamic, then count will be taken from game.project.
So, fo example:
Collection (world spawned with collection proxy)
-go
--sprite
--factory with `Dynamic Prototype` unchecked
----go
------label
will allocate 1 sprite and label->max_count labels, because labes componens is in factory and you can spawn many of them. The rest of component will not allocate anything (because we analyze your collection and see you can’t spawn them).
But if you use Dynamic Prototype then all the component will be dynamic and this collection will take counters for each component from game.project.
For our example:
Collection (world spawned with collection proxy)
-go
--sprite
--factory with `Dynamic Prototype` checked
----go
------label
this collection will allocate sprite->max_count of sprites label->max_countof labes and so on for all the components.
This feature isn’t a hack that makes Defold engine dynamic. I do not recommend to use it just because “I don’t wanna make a factory”.
This feature solves the one particular problem: an ability to spawn downloadable content in existent world (a collection which is loaded using collection proxy).
It’s important when you have your main game and a lot of customizable, seasonal content you don’t wanna deliver to all the users.
Let’s say you have a shooter with a season pass. For people who passed the season pass you give a unique character skin.
All the new users will not be able to get it, because they didn’t pass this particular season. So you wanna this content in your main game collection for some count of player who have it on their accounts, but not all of them. Then this feature is your choice!
I hope now it’s clear.
Very good explanation, thank you.
I’ve updated the beta with a fix for sprite trimming in atlases.
@sergey.lerg if you want to test it out.
That was quick! Thanks.
This fix is included in the 1.4.3 beta but it wasn’t mentioned in the original post (has been edited now):
FIX: (#7336) Use min x and y scale for particle effect scale in gui
The previous fix for particle effect scale only partially solved the problem of inconsistent particle effects scaling between gui and game objects. The original issue was that the x component of the scale was always used when scaling in the gui. The partial fix applied in #7163 used the smallest scale component of x, y and z, which made particle effect scaling in gui more consistent. The problem is that on window resize only the x and y component of the scale of a gui node is affected while the z component remains at its original value, which would produce an incorrect result for particle effects.
The correct solution, which is applied in this fix is to use the smallest of the x and y component when applying a scale to particle effects in gui. This is consistent with how other nodes are scaled and it is also consistent with how particle effects on game objects are scaled using smallest uniform scale value (using x, y, z in 3d/go and only x and y in 2d/gui).