Defold 1.3.2 has been released

Release notes


NEW: Use Android 12 (API 31) as target API (#5541)
Android target API updated to API level 31 (Android 12). Minimum version of Defold for Android build is 1.2.185.

AndroidManifest.xml has changed. Make sure you copy these changes into your custom manifest if you use one!

NEW: Add ability to bundle Android in both formats apk and aab at the same time (#6506)
Added new ability to create both AAB and APK bundle at the same time. It makes it simpler to prepare bundle for release (AAB) and final tests (APK) without running bundle process twice. To create both an APK and an AAB specify both bundle formats in a comma separated list:

java -jar bob-jar --bundle-format=apk,aab

FIX: Fixed issue with mesh vertex buffers not updating properly (#6505)
Under certain circumstances meshes did not update correctly even though the buffers changed. This fix ensures that a mesh is updated when the buffer content changes.

FIX: Moved in-place encrypt and decrypt to dmsdk (#6520)
The Defold SDK has two new functions for performing in-place encrypt and decrypt of a buffer using a key and encryption algorithm:

Result Encrypt(Algorithm algo, uint8_t* data, uint32_t datalen, const uint8_t* key, uint32_t keylen)
Result Decrypt(Algorithm algo, uint8_t* data, uint32_t datalen, const uint8_t* key, uint32_t keylen)

FIX: Fix possible ANR when OS closes app (#6513)
This fix takes care of the last know source of a category of ANRs related to unloading native code (

FIX: Component types are deleted before the collections (#6521)
Due to a recent refactor of component code and context ownership there’s a risk of a crash during shutdown when using a GUI component.

FIX: Make sure to copy asset folders as well when creating the Android bundle (#6487)
Some Android dependencies ship additional folders in the assets directory. In the case of Helpshift (com.helpshift:helpshift-sdkx:10.1.0) there is an assets/helpshift/ folder containing additional files. The build pipeline incorrectly assumed that everything in assets was files. This fix checks each entry in assets and in the case of a folder it copies the folder and everything in it to the bundle.

FIX: Support require calls from the global Lua table (#6438)
Lua stores all global functions and variables in the global table identified as _G. This table contains all of the global Lua language functions as well as Defold API functions and any user defined global values. The require() function is among the global Lua functions and can be used to require Lua modules:

-- these are calling the same function
local foo = _G.require("foo")
local foo = require("foo")

When building a Defold game the build tools scan for calls to require() and will include any required Lua module in the build. The build tools did not detect _G.require() calls which results in run-time errors when Lua modules were not included in the build. This change adds detection of _G.require() calls to the build tools.

FIX: Fix timer triggered in init (#6536)[]
The timer did not trigger at the correct time if set from the init() lifecycle function of a script. This was caused by recent changes in the engine when improved handling of variable refresh rates and decoupling of physics was introduced.

FIX: Getting flipbook animation for a box node may return an empty hash (#6551)[]
Fix issue when gui.get_flipbook() returns empty string for a box node created in the editor.


In my game I use gui.set_texture() to use different “skins” for gui components. The bitmaps have different sizes. Using gui.play_flipbook() resizes the node so it can be used without looking stretched. This technique worked prior to the 1.3.1 build, but in 1.3.1 and 1.3.2 the gui.set_texture() causes gui.get_flipbook() to return an empty hash.

The issue seems to be gui.set_texture() not retaining animation names. If this is the case I’ll open a new github issue.

Example code:

local node = gui.get_node("box")
gui.set_texture(node, "test2") -- This line makes the get_flipbook() call return an empty hash

local animation = gui.get_flipbook(node)
print("animation", animation) -- DEBUG:SCRIPT: animation	hash: []
gui.play_flipbook(node, animation) -- ERROR:GUI: PlayNodeFlipbookAnim called with invalid anim name.

Minimal example project: (20.6 KB)

Yes, that is the purpose of the fix in 1.3.2.

Sorry, I accidentally typed 1.3.1 instead of 1.3.2 above. I’ve edited the post. To clarify: The behaviour detailed above happens in Defold 1.3.2.

1 Like

Are you sure?
Because I see this 7 y.o. test that check that flipbook animation is 0 after we change texture:

1 Like

I may be missing something, but this is what I’m seeing in Defold 1.3.2 using the minimal project above:

Do you get a different result?

What I’m saying is
this example has been working like that last 7 years.

This is not an issue. this is by design behaviour according to the 7 years old test.

If you have an issue with stretch (I’m not sure I got it) could you please create an example with the issue you have.

If so, that’s really quite strange! The set_texture() + get_flipbook() combo was working six months ago, when this project was paused, but not in the more recent 1.3.1 and 1.3.2 versions for some reason.

The issue is quite obvious if only set_texture() is used, and gui.play_flipbook() is commented out in the example :

The image is stretched because the bitmaps in each texture atlas have different dimensions. When the texture is changed, the node size is not updated. When gui.play_flipbook() is used, the node size is updated to the correct bitmap dimensions.

The documentation (gui.set_texture) suggests that if you set a texture for a node and that texture is an atlas, you will also need to call the play_flipbook function to set the animation for the node.

gui.set_texture(node, "test2") -- This line makes the get_flipbook() call return an empty hash
gui.play_flipbook(node, "bg")

So I think what you expect will happen.

Yeah, the only issue that I see is that the set_texture() call makes a subsequent get_flipbook() call return an empty hash. I don’t think this is by design, but maybe it is and I’m missing something.

I mentioned it in the first place because I noticed that this has stopped working in the last couple of Defold versions, so might be worth fixing, but it’s not a biggie to be honest.

Defold version 1.2.189:

I think I finally get why this issue appeared in your project and when it changed in Defold.

This ticket fixed in 1.2.189:

Before the fix, changing of texture triggers play_flipbook internally. But if flipbook animation with the same a name doesn’t exist we got:

ERROR:GAMESYS: Unable to play animation ‘i_log’ from texture ‘/main/generated/atlases/items_containers1.texturec’ since it could not be found.

This fix is checking if there is animation with the same name in the new texture then if calls play_flipbook internally, if not, then ignore this call. Your case should be perfectly covered (because names of your sprites are identical in both atlases), but for some reason it’s not.

Could you please open a ticket on GitHub, I’ll take a look why it’s happening.

A fast workaround in your code would be calling get_flipbook before set_texture call (but I would like to take a look this issue anyways if you create a ticket, thank you).


Thanks for testing this. I think in the end this is partly a red herring which I’ll explain below.

When I was tinkering with this I also realised that that is how I had it set up initially.

It must have stopped working with the release of Defold 1.3.1. Looking back at my commits, at this point I refactored my code with a comment saying this is being fixed in 1.3.2, as per a Github note I found. What I ALSO did, and this the cause of all my confusion, is move the gui.get_flipbook(node) AFTER gui.set_texture(), because the code is clearer that way - the animation id is not used by set_texture(), so why have the call before it? It’s likely the call was first because I had figured out it had to be, but I had no memory of that (and should have commented!).

When the 1.3.2 with fix was released I posted the above, and the rest is history. Mystery solved. Apologies for any time wasted. :cold_sweat:


1 Like

No worries. It is strange behaviour anyway (in case when both atlases contain sprite with the same name) and I’ll take a look what’s going on there.

1 Like