Defold 1.2.123 has been released

[Johan_Beck-Noren]

Defold 1.2.123

This sprint we’ve updated the iPhoneOS and MacOSX versions to the latest stable versions.

NOTE: The most notable thing here is that the iPhoneOS doesn’t support the system() call anymore.
It has been deprecated for a very long time, and now it has finally been removed altogether from the sdk.
This also affects the os_execute() function in Lua that is now disabled on both iPhoneOS and HTML5.

We’ve also given some good attention to the old Euler Z rotation bug, which has now been fixed.

And the documentation has been updated with several typos and clarifications

Engine

• DEF-3139 - Updated: Added support for iPhoneOS11.2 and MacOSX10.13
• DEF-1311 - Fixed: Compound script properties couldn’t be decomposed or animated
• DEF-1636 - Fixed: Fix for euler-z errors
• DEF-3153 - Fixed: Crash fix for models without any color. They now default to white
• DEF-3154 - Fixed: Fixed error related to callback of spine animation with one frame
• DEF-3158 - Fixed: NE builds now only builds one of 32-bit or 64-bit Win32 at a time

Documentation:

• Added ray cast section in physics manual.
• Updated sound manual for editor 2 and made easier for new users.
• Installation manuals updated to editor 2.
• iOS manual updated to editor 2. New section on how to use free Apple Xcode app signing for development.
• Android and dev app manuals updated to editor 2.
• Added a few detail clarifications to runner tutorial.

[AGulev]

DEF-3158 - Fixed: NE builds now only builds one of 32-bit or 64-bit Win32 at a time

Does it mean faster NE builds for windows? (It was slowest build)

[Mathias_Westerdahl]

well, yes, it should now only take half the time, since it will only build either of the two platforms

[88.josh]

I have a quick question: does this include Britzl’s work on letting apps built in defold interpret android USB-OTG keyboards?

[Erik_Angelin]

That will land in the next stable release in two weeks.

[joshua.winters]

DEF-3139 - Updated: Added support for iPhoneOS11.2 and MacOSX10.13

With the new version macOS X 10.13 sdk, my native extension cannot get compiled with following message:

error: nullability specifier '_Nullable' cannot be applied to non-pointer type 'uuid_t' (aka 'unsigned char [16]')

My extension does NOT use these two functions, so I assume it is caused by the toolchain changes.

[Mathias_Westerdahl]

Yes, we’re looking into this right now.

[joshua.winters]

Thanks @Mathias_Westerdahl, you can get Reachability.h /.m from https://github.com/tonymillion/Reachability

[Dragosha]

My brain is broken.
Please, look at screnshoot with back side of cards (board draft moment):
Defold version 1.2.122:

After update to 1.2.123 there are no backs, just front sprite of cards:
1.2.123

Perhaps it depends with DEF-1636 - Fixed: Fix for euler-z errors. But I use euler-y rotation in my game. And for back sprite I use the self material with predicate that rendering after standart sprite-material.

Card in editor:

Card rotation code:

go.set_rotation(vmath.quat_rotation_y(-math.pi), id)
   ....
go.animate(id,"euler.y",go.PLAYBACK_ONCE_FORWARD,0,go.EASING_INOUTQUAD, FLIPTIME, 0 ,function()... end)

any ideas?

[Ragnar_Svensson]

It’s most likely a consequence of the euler-fix, sorry about that. We have still not been able to reproduce the problem. While we are trying to understand what is causing this, you could try some things to help us narrow down the problem:

• Set rotation to positive math.pi: vmath.quat_rotation_y(math.pi) (should result in cards rotating other way)
• Set rotation by go.set(id, “euler.y”, -180) instead of go.set_rotation
• print(go.get_rotation(id)) for one of the cards while it’s rotating and post the results here
• Offset the position on the “back” sprite (like x: 50) and set the Y-rotation to 0. Should result in the front and back being visible simultaneously.

[Dragosha]

Set rotation to positive math.pi: vmath.quat_rotation_y(math.pi) (should result in cards rotating other way)

It’s work! Thanks!

[Ragnar_Svensson]

I’m not really happy that that worked, but happy you can see the backsides! We will investigate more on our end, definitely looks like an engine bug.

[unkstar]

Maybe this is related to the problem we encounter: euler.z rotate x axis!

This is what should looks like while object is rotated along x and z by 45 degree:

And this is what we’ve got in Defold: (euler.x is -45 because of chirality is different between Defold and Unity)

As you can see, the tile is not rotated along the X-axis anymore, but along the ROTATED X-axis:

I guess maybe you guys is doing rotation along z and x/y in two steps, and something mess up between them?

[Ragnar_Svensson]

UPDATE: It does look correct. I didn’t see the difference in shading on the box, and thought it was only rotated along z. If you rotate it (45,-45,0), does it end up the way you expect? (Hard for me to tell since I don’t know how your mesh is oriented by default.) @sicher has performed an extensive test where he both tried to replicate @Dragosha’s issue as well as testing all kinds of rotations in the editor and comparing them with rotating in scripts, without finding anything incorrect. There is still something that goes wrong in @Dragosha’s case obviously, but we are not yet sure it’s an error in the rotation or further down the line in rendering.

I’m not sure we use the same rotation order as Unity (we use YZX), but it still looks incorrect in the screenshot from Defold, at least when I do the rotation in my brain. We are currently investigating the issue though, will post here when we know what is wrong.

[sicher]

Would you mind posting your render script and some more details about the material you use to render the back side? This might be a rendering issue.

[Ragnar_Svensson]

Also, would you mind setting the rotation back to -180 and trying out this:

• Offset the position on the “back” sprite (like x: 50). Do they show next to the front-sprites?
• Keep the offset x: 50 and set the Y-rotation to 0. Should result in the front and back being visible simultaneously.

I want to make sure they are rendered at all.

[unkstar]

My bad, I forgot to check rotation order first, Unity uses YXZ rotation order.
when I use a parent node to contain xy rotation, it work the same way as Unity does.

[Dragosha]

I forgot to drop a note that card.script has a hook to switch back/front sprites. This is rotation checking in update. I don’t remember why code switch the card state when rotation <90. I guess it was experemental conditions. So, after engine updates this condition changed and switch begining state of the sprite from vmath.quat_rotation_y(-math.pi) to vmath.quat_rotation_y(math.pi) fix it.

local function flip(self)
    msg.post("#back","disable") --- <<< Disable sprite, so it's invisible
    msg.post("#front","enable")
    msg.post("#label", "enable")
    self.flip=true
end

function update(self, dt)
    if not self.flip then
     if go.get(".","euler.y")<90 then
         flip(self)
     end
    end
    if self.backflip then
     if go.get(".","euler.y")<-90 then
         self.backflip=false
         msg.post("#label", "disable")
         msg.post("#front","disable")
         msg.post("#bosslight","disable")
         msg.post("#back","enable")
         msg.post("#special", "disable")
     end
    end
end

@Ragnar_Svensson, @sicher drop me your emails and I’ll invite you to project in dashboard. It’s old version, but this part of code old too.

[sicher]

Got the project and see the bug. I’ll try to locate what causes it.