Defold 1.2.189 has been released

Release notes
#25

Hello, since i have downloaded the last update 1.2.189 , the editor crashes whatever i do (for example, opening a file make it crash).
The crash is : the editor is closed, and there is a log file saying that the crashes happened outside JVM, in the native code. I can provide the full log of course, but it’s too long to be put here.

I’m running the linux version, on a full updated archlinux.

Can i help you to help me to solve this ? :slight_smile:

Thank you.

EDIT: i’ve tried and downloaded Defold zip from the website, but it still crashes. I was hoping it would be a previous version. May be i can downgrade my version, for testing, to 1.2.188 ? But where can i find it ?

EDIT 2 : i’ve found an older installation of Defold 1.2.187 which was working like a charm one month ago. But now, it hangs too, like the 1.2.189. So it must be related to my configuration. How can i find what is wrong ? It seems to hang from outside Java VM, what could it be if it’s not a problem with my java packages ?

#26

Yes, of course, @Mathias_Westerdahl
bug.zip (986.8 KB)
you can comment any of this lines and it will become OK :slight_smile:

изображение
изображение709×175 4.79 KB

2 Likes
#27

Thanks! Are you seeing improvements in the Google Play Console for Apple Spider?

#28

Please share the log here (as an attached file) or open a ticket on GH.

You can download previous versions from GitHub: https://github.com/defold/defold/releases

The log will definitely give us clues. And any other output from a terminal.

1 Like
#29

Hello, it’s an Archlinux related issue.

@Potota on discord gave me the answer.

I had the same issue on Arch, the fix is to install an older version of libffi like AUR (en) - libffi7 and use it by setting LD_PRELOAD to the .so path, e.g. LD_PRELOAD=/usr/lib/libffi.so.7 ./Defold

So i did and now it works well as before.

Current libffi is so.8 since 16th october on archlinux.

I join the crash log, as it could happen everywhere when all distributions have upgraded the libffi to v8.
crashlog.zip (30.7 KB)

1 Like
#30

It’s only been 4 days so far, so time will tell. Google Play claims ~1.4k install/update events. A few thousand more existing users still need to update.

As of this moment, I see only 1 crash and 0 ANRs for the new version. Pretty good!

The real test will be upgrading my Instant version. That one is way more unstable due to whatever magic Google wraps around it. Hopefully I will have time to release that this holiday weekend (Thanksgiving here in the USA).

2 Likes
#31

Yay, Happy Thanksgiving!

1 Like
#32

(about the libffi-3.4 bug which hangs defold)

It seems that few distributions have migrated to libffi-3.4.

So this bug might only touch archlinux users for the moment.

https://bugs.gentoo.org/801109

1 Like
#33

try this:

apt install libffi7

create launch script:

#!/bin/bash
_pwd=dirname $(readlink -e "$0")
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libffi.so.7 $_pwd/Defold

and launch it .

or launch it using:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libffi.so.7 ./Defold

(solution by @sashikknox )

2 Likes
#34

Random idea: Maybe a Flatpak release would solve this kind of issues creeping up in the future?

#35

Yes, maybe. I don’t know enough about it I’m afraid. We have it as a feature request here: https://github.com/defold/defold/issues/4825

On this note: We’d love to find one or two people from the Linux community to help out with things like this. The Defold Foundation would to some extent be able to compensate for the time spent.

1 Like
#36

Thanks for the repro case!
A fix is coming in the next release! (Or in the alpha build after the fix has been reviewed)

1 Like
#37

gui.get_font_resource takes font name as an argument, not a node. The example code for gui should be:

local font_name = gui.get_font(node)
local font = gui.get_font_resource(font_name)
local metrics = resource.get_text_metrics(font, "The quick brown fox\n jumps over the lazy dog")
3 Likes
#38

Hello!
Is the collision objects also affected by the changes with uniform arrays?
After update to 1.2.189 version I get an error on this line:
go.get(#dynco", “linear_velocity”, velocity)

ERROR:SCRIPT: /billiard_objects/cue_ball.script:76: bad argument #3 to ‘get’ (table expected, got userdata)

#39

I think you have a typo. go.get only takes two arguments.

#40

Looks like I’ve found a mistake in my code through this new messages, because this line is really incorrect, but there wasn’t an error message on this line prior to 1.2.189 version. And in fact it isn’t needed (or maybe “go.set” could have been previously there):grinning:
Thanks!

2 Likes
#41

We have changed go.get() so that it takes a third optional argument of type table.

1 Like
#42

Remind me, what’s the third argument?

The docs don’t seem to have been updated yet:

1 Like
#43

Not sure how we missed the documentation tbh, but as it says in the release notes, it needs to be a table, with an index (if it is an array).
This is currently only supported by material properties.

-- set the first vector4 in the array: example[0] = v
go.set(url, "example", vmath.vector4(1,1,1,1), {index=1})

-- set the last vector4 in the array: example[15] = v
go.set(url, "example", vmath.vector4(2,2,2,2), {index=16})

-- set an element of a vector4 in the array: example[0].x = 7
go.set(url, "example.x", 7, {index=1})
4 Likes
Add the ability to update an uniform array in the constants buffer
#44

There is no way to update uniform array in a constants buffer created by render.constant_buffer(). Would like to do this by this way:

self.constants = render.constant_buffer()
self.constants.light_colors[3] = vmath.vector4(1)

Added a feature request #6526.

3 Likes