Defold 1.2.130 has been released

Release notes
#1

Defold 1.2.130

This release adds Lua module timer to scripts. This allows you to set a delay and a callback to be called when the timer completes. We also added functions sprite.play_flipbook, sound.play, sound.stop and sound.set_gain besides posting messages for these functions.

Engine

  • DEF-1183 - Added: Timer API, timer.delay and timer.cancel.
  • DEF-3315 - Added: New sprite and sound message wrappers.
  • DEF-3313 - Fixed: Facebook Gameroom is now dynamically loaded by our extension.
  • DEF-3311 - Fixed: Updated OpenAL to latest built version for Win32.

Editor

On the editor side, we’ve added the ability to edit game-specific text files using the code editor. JSON files support syntax highlighting, but you can edit any text file. We’ve also added the ability to toggle between local- and world-space manipulators in the Scene View.

  • DEFEDIT-887 - Added: Scene view manipulators can be toggled between local- and world-space.
  • DEFEDIT-1235 - Added: Non-spine JSON files can now be edited using the code editor.
  • DEFEDIT-1319 - Added: Unrecognized text files can now be edited using the code editor.
  • DEFEDIT-1407 - Fixed: Sometimes the NE build cache was invalidated between editor sessions.

Docs

Added new RPG map sample. It’s available from the editor welcome screen (New Project -> From Sample) and on Github: https://github.com/defold/sample-rpgmap.

28 Likes
#2
#3

Someone obviously didn’t watch the soccermatch but worked instead!
Thanks for an awesome release.

10 Likes
#4

Where can I find out the document of the new Timer API?

#5

We forgot to add the new namespace timer.* to the docs. This will be fixed today. Until that happens here’s the docs for timer.create() and timer.cancel():

/*# Create a timer
 * Adds a timer and returns a unique handle
 *
 * You may create more timers from inside a timer callback.
 *
 * Using a delay of 0 will result in a timer that triggers at the next frame just before
 * script update functions.
 *
 * If you want a timer that triggers on each frame, set delay to 0.0f and repeat to true.
 * 
 * Timers created within a script will automatically die when the script is deleted.
 *
 * @name timer.delay
 * @param delay time interval in seconds
 * @param repeat true = repeat timer until cancel, false = one-shot timer
 * @param callback [type:function(self, handle, time_elapsed)] timer callback function
 *
 * `self`
 * : [type:object] The current object
 *
 * `handle`
 * : [type:number] The handle of the timer
 *
 * `time_elapsed`
 * : [type:number] The elapsed time - on first trigger it is time since timer.delay call, otherwise time since last trigger
 *
 * @return handle identifier for the create timer, returns timer.INVALID_TIMER_HANDLE if the timer can not be created
 */

/*# Cancel a timer
 *
 * You may cancel a timer from inside a timer callback.
 * Cancelling a timer that is already executed or cancelled is safe.
 * 
 * @param handle the timer handle returned by timer.delay()
 * @return true if the timer was active, false if the timer is already cancelled / complete
 */
1 Like
#6

Thanks for the update!

#7

Oh, not sure if it’s timer.create() or timer.delay(). Hold on.

#8

It’s timer.delay() not timer.create().

#9

How does this timer compare to your own timer, @britzl? Is it the same (in terms of performance etc, or even the same code) or do you recommend using this new one over the previous one?

#10

The new one has a better design I think.

It’s unlikely that there is any measurable difference in performance.

Nope, new code.

Yes, use the new one!

3 Likes
#11

An important difference that @Mathias_Westerdahl pointed out: The timer update is inherited from the collection in the new one, meaning that it will respect the update frequency of the collection. If you pause or speed up the collection (using set_time_step) it will also affect the new timer.

The old timer (the one I wrote as an extension) is a global timer based on the system clock time. It is not in any way affected by the time step or anything like that in the engine.

7 Likes
#12

Possible to add timer.pause and timer.resume?

Editor 2 still needs to support autocomplete for timer.

3 Likes
#13

I agree with you, would be great to have this feature - it will help to fully replace update() timers.

1 Like
#14

Considering this, I think both have different use cases.

Timer that respects collection update frequency for something gameplay-sensitive, like “shield lasts 5 seconds”.

Timer that respects system time for maybe something gui-wise, “remind player about x with a popup 1 minute later”.

Granted, you’d probably not often need the system time accuracy but hey, there’ll always be edge cases out there pushing the limit!

And yes, pause/resume would be nice :slight_smile:

1 Like
#15
#16

It’s on the site now!

4 Likes
#17

I’m a little confused that this:

local function timer_callback(self, handle, time_elapsed)
    print('handle: '..handle)
    print('time_elapsed: '..time_elapsed)
end

local timer_id = timer.delay(2, false, timer_callback)
timer.cancel(timer_id)

Results in the following console output after 2 seconds:

DEBUG:SCRIPT: handle: 0
DEBUG:SCRIPT: time_elapsed: 2.0166654586792

Is the callback called even if a timer is cancelled?

Also, in the absence of pause/resume it would be really nice to have the same callback function(self, handle, time_elapsed) with timer.cancel() as with timer.delay(). It would then be possible to cancel (pause) an existing timer and resume (create a new one) based on how much time was left.

Thanks

#18

I can’t reproduce this. Are you sure that you have only one timer with that callback?

#19

Thanks for the quick update!

It appears the new timer functionality isn’t happy about having britzl’s native timer module included in the project. I’d been using this previously and hadn’t removed it.

Removing the dependency resolves the issue.

4 Likes
#20

Aha, yes that explains the weird behavior. :slight_smile:

1 Like