Defold 1.2.179 has been released

[Mathias_Westerdahl]

Our iOS entitlements support was improved with a better way of merging the entitlements.

We’ve added a new error code to the return value of gui.new_texture().

We’ve updated/fixed some issues with regards to callstack output. This should help us pinpoint issues faster in the future.

We now publish the download link to the reference documentation for each release on http://d.defold.com.

For native extensions and iOS, we added signing to the ./Frameworks folder (if there is one).
We also copy any swift libraries found in the frameworks folder to the ./SwiftSupport folder. These changes were made to support the latest Facebook sdk.

When bundling for Windows, bob.jar now only bundles one architecture at a time (32 or 64 bit).

Bob got an argument --exclude-build-folder which is a comma separated string of folders that should not be included in the build.

Engine

• Issue-5017 - Fixed: Handle iOS entitlements overrides with and without an Entitlements dict
• Issue-5412 - Fixed: Download symbols in vanilla builds if --with-symbols is used
• Issue-5415 - Fixed: Fix for to avoid debug.traceback being accidentally overwritten
• Issue-5432 - Fixed: Crash fix for number of tilegrid renderobjects required for a frame
• Issue-5437 - Fixed: Make the domain name of editor updates configurable
• Issue-5438 - Fixed: NE: Added documentation for DM_DEBUG, DM_RELEASE and DM_HEADLESS
• Issue-5439 - Fixed: Win32 callstack fix for asserts (better output in console)
• Issue-5441 - Fixed: Append Lua callstack to crash dumps (better output in console)
• Issue-5452 - Fixed: Update value of initial memory for HTML5
• Issue-5455 - Fixed: Update dmloader.js to support IE11
• Issue-5458 - Fixed: Relax dmHttpClient assertions for nocontent responses
• Issue-5461 - Fixed: Add ref-doc.zip to download page
• Issue-5464 - Fixed: Discard lingering sound instances with few frames left - fixes #5270
• Issue-5465 - Fixed: Sign iOS frameworks
• Issue-5469 - Fixed: Script callback destroy fix
• Issue-5473 - Fixed: Mesh component now uses the correct textures
• Issue-5482 - Fixed: Copy swift libraries to SwiftSupport folder
• Issue-5483 - Fixed: Added initial focus to the macOS app when using Vulkan backend
• Issue-5486 - Fixed: Return an additional result code from gui.new_texture()
• Issue-5488 - Fixed: Set architecture as well when bundling for windows
• Issue-5489 - Fixed: Always use an architecture matching the platform on Windows
• Issue-5492 - Fixed: Fix for resizing the descriptor allocator (Vulkan)
• Issue-5496 - Fixed: Added exclude-build-folder option to bob.jar
• Issue-5499 - Fixed: LiveUpdate: dmSys::LoadResource can load from both the android assets and also regular files
• Issue-5500 - Added: Added dmHttpClient::ParseHeader to dmSDK
• Issue-5511 - Fixed: Made sure gamepad axis pressed/released trigger more like a regular button

Editor

• Issue-5141 - Fixed: Editor preferences now support utf8 strings

[dapetcu21]

Wohoo! So many closed issues in this release! Awesome! Congrats!

[Pkeod]

We now publish the download link to the reference documentation for each release on http://d.defold.com

Possibility of Editor integrated API search like Dash/Zeal?

[SkaterDad]

Fixed : Append Lua callstack to crash dumps (better output in console)

Will this extra detail also show up in Google Play crash reports?

[Alex_8BitSkull]

• Issue-5511 - Fixed: Made sure gamepad axis pressed/released trigger more like a regular button

Could someone please explain a bit what this fix means / what it changes in relation to gamepad sticks? (I’m assuming it refers to moving the stick in a direction, not clicking it.)

This change has affected my game and so I’d like to understand how it works so I can attempt a fix. I handle input a bit unusually so it might be on me, but my scripts definitely worked before this update.

[Mathias_Westerdahl]

Previously, for a stick, it registered the “pressed” as soon as the value was above 0. This made it really difficult to use the “pressed” as a button. Especially when moving right, the up and down axis would spam “pressed” and “released” events.
Now, the the stick registers the “pressed” at a much higher value, making it useful as a button.
E.g one use case is to make the game playable with both the left pad and the left stick (for games designed for the left pad)

This change has affected my game and so I’d like to understand how it works so I can attempt a fix.

We’re very sorry to hear that. We did not anticipate this.
Please let us know if you find a way around this or not (and we’ll figure something out)

[Alex_8BitSkull]

Thanks!

It’s actually the other side (“released”) that is causing me problems.

The unusual way I handle input is that I have a central input script, instead of using on_input() only when relevant. Here is my old set up, and this worked as intended:

if action_id == PAD_LSTICK_LEFT then
        pad_lstick.x = -action.value
  elseif action_id == PAD_LSTICK_RIGHT then
        pad_lstick.x = action.value
end

if (action_id == PAD_LSTICK_LEFT or action_id == PAD_LSTICK_RIGHT) and action.released then
        print("released", action.value)
    end

With the recent change, the value does not always return to 0 when the stick is released. Here is an example output (I print pad_lstick.x in update() (not shown in code above), and I print “released” in on_input when the released event fires):

DEBUG:SCRIPT: -1 (<- repeated output, stick held to one side)
DEBUG:SCRIPT: released -0.5512016415596
DEBUG:SCRIPT: -0.5512016415596 (<- repeated output, stick not held at all anymore)

I also sometimes get this output (sign change after release, stick bounces to other side briefly and stays there?):
DEBUG:SCRIPT: -1
DEBUG:SCRIPT: released -0.63121998310089
DEBUG:SCRIPT: 0.23854434490204

And this (seems to go to zero and then bounce back partly to the old direction):
DEBUG:SCRIPT: -0.94433510303497
DEBUG:SCRIPT: released 0
DEBUG:SCRIPT: -0.20677500963211

The first type is most common, second and third are more rare.

At first I thought it was my controller (old Xbox 360) playing up, but then it was happening on my Switch too. I tested an old build on Steam and it doesn’t happen there, so I narrowed it down to this update.

[Alex_8BitSkull]

gamepad_stick_test.zip (905.6 KB)

Here’s a minimal example. It is set up to print the last detected value for the left stick’s x-axis.

The test is to push the stick to one direction, then let it go. In 1.2.178, the last value is always 0 (which is what I want, in my current setup at least). In 1.2.179, it more often than not is something else (as described in my post).

Do you guys get the same result?

[roccosaienz]

Same problem for me. I had to rewrite the stick input implementation.

While this new input simplified my implementation of “stick as left-up-right-down buttons”, it ruined my code for free movement. In a very rough solution (at least for me) I force the value to 0 when I get released. But also with this I see some strange drift sometimes.

In my humble opinion, I think that a game using the gamepad stick to free move something needs the most unfiltered values from the input. So maybe also the raw values should be passed to the input; I don’t know how…

Ciao!

[Alex_8BitSkull]

While this new input simplified my implementation of “stick as left-up-right-down buttons”, it ruined my code for free movement. In a very rough solution (at least for me) I force the value to 0 when I get released. But also with this I see some strange drift sometimes.

I tried this too, but I noticed I get values even after released, so didn’t work.

Glad it’s not just me!

[britzl]

We’re very sorry to hear that. We did not anticipate this.

As Mathias said this was not something we anticipated. We had a pretty lengthy discussion regarding the change.

The way it worked before was definitely wrong since there should only ever be one pressed and one released event and the pressed and released event should trigger when above a certain threshold (close to its maximum) to allow an analog stick to also be used where you require an input scheme similar to a digital d-pad.

With the recent change, the value does not always return to 0 when the stick is released

Note that with the change “pressed” and “released” is not an indicator if the analog stick is moved outside of the stick deadzone but if it is moved above the threshold I mentioned. To detect if the stick is moved outside the deadzone all you only need to care about the action_id (and the amount the stick is moved is indicated by action.value).

DEBUG:SCRIPT: -1 (<- repeated output, stick held to one side)
DEBUG:SCRIPT: released -0.5512016415596
DEBUG:SCRIPT: -0.5512016415596 (<- repeated output, stick not held at all anymore)

This sounds like a bug (unless your controller is old and worn in which case it might actually generate events outside the default deadzone).

[Alex_8BitSkull]

Note that with the change “pressed” and “released” is not an indicator if the analog stick is moved outside of the stick deadzone but if it is moved above the threshold I mentioned. To detect if the stick is moved outside the deadzone all you only need to care about the action_id (and the amount the stick is moved is indicated by action.value).

That’s fair and that’s how I was detecting it before the change. I only mentioned ‘released’ for context really.

This sounds like a bug (unless your controller is old and worn in which case it might actually generate events outside the default deadzone).

Note that “repeated output” here means the last detected output. I’m not saying that I keep getting 0.551 in on_input(), but what I am saying is that in 1.2.178 I would have seen 0.551 followed by 0, and in 1.2.179 I am getting only 0.551 and never the 0.

The test project I posted above should illustrate this if you open it using the two versions in question.

[britzl]

Note that “repeated output” here means the last detected output . I’m not saying that I keep getting 0.551 in on_input(), but what I am saying is that in 1.2.178 I would have seen 0.551 followed by 0, and in 1.2.179 I am getting only 0.551 and never the 0.

Ah, I see. That is definitely a problem. It sounds like a bug.

[britzl]

It sounds like a bug.

Added https://github.com/defold/defold/issues/5564

[Mathias_Westerdahl]

Note that “repeated output” here means the last detected output . I’m not saying that I keep getting 0.551 in on_input(), but what I am saying is that in 1.2.178 I would have seen 0.551 followed by 0, and in 1.2.179 I am getting only 0.551 and never the 0.

I agree, that sounds like a bug. To me, it should occur at the same time as the “released” event.

[Mathias_Westerdahl]

I think that a game using the gamepad stick to free move something needs the most unfiltered values from the input. So maybe also the raw values should be passed to the input; I don’t know how…

@roccosaienz We apply a deadzone to the input, since each hardware controller is slightly different. The deadzone is (currently) circular, which means if the length of the (x,y) vector is above the deadzone, neither of the (x,y) values are clamped.

If you don’t want any deadzone applied at all, make a new copy of the builtins/input/default.gamepads and change the deadzone for all the controller types to 0.

[roccosaienz]

Thanks!

I am a bit confused by

Now, the the stick registers the “pressed” at a much higher value, making it useful as a button.

But probably it is just a misunderstanding from my side. May I receive values that are lower than this “higher value” but above the deadzone? Probably I am missing something here since I was thinking that action.pressed is the start of ANY input from a gamepad stick.

[britzl]

May I receive values that are lower than this “higher value” but above the deadzone? Probably I am missing something here since I was thinking that action.pressed is the start of ANY input from a gamepad stick.

You will receive events from the analog stick as soon as it is above the deadzone. This behavior has not been changed.

What we have changed is when you get “pressed” and “released” events. You will now get one pressed event when you cross the new high threshold value (basically maximum possible push on the analog stick) and one released event when you go below. This allows you to use the analog stick in the same way as a digital D-PAD. This is extremely useful when implementing menu navigation for instance, which previously was very tricky since the pressed and released events didn’t behave really as a digital press and release.

I was thinking that action.pressed is the start of ANY input from a gamepad stick

To me it makes more sense to consider an analog stick more like mouse input. When the mouse is moved you get a mouse event with new position and delta. When the analog stick is moved you get an analog stick event with information about how far the stick was pushed. This kind of movement has very little to do with pressed and released events, don’t you agree?

[roccosaienz]

@britzl Thanks!

Everything is clear now! I was confusing the two types of input!

Indeed, as I said above, the new behavior simplified the use of the stick for menu navigation! Before, as you mentioned, I needed to filter somehow the pressed/released events; now it is way simpler!

But I was missing the stick input similar to mouse movement as you described! So I am totally with you and I consider this an improvement!