How to check if GUI animation is in progress?

Questions
#1

Is there a way to determine if a particular GUI node is in the process of being animated?

#2

You can set a flag when animation starts and clear it on finish.

2 Likes
#3

Yeah, this workaround exists. Perhaps there should be a gui.is_animating(node, property) and a go.is_animating(url, property)?

4 Likes
#4

hello all

i ran into this same problem … i have multiple animations starting and running at the same time and would need to know when the last animation finished so i can enable/disable user input while animations are running/finished.

simplest way would be to increase a variable value for every animation started and then in the animation complete_function function decrease that variable’s value and check if it is 0 to know if all animations are finished for example …

now i have 2 questions …
question1: how reliable is the complete_function … will it be called for example 2 times if 2 animations finish at the same frame?

question2: does the complete_function get called if the start and endpoints of the animation are the same? (hence no animation was needed and the animation is basically finished when it gets created)

thanks

edit:

found the solution myself, i hope it helps others …

i release_input_focus, create all animations, take the duration and delay time of each animation created and start a one shot timer with the sum of both max values as duration. in the timer callback function i acquire_input_focus again.

#5

Happy to hear that you found a solution. I’m going to answer the questions you had anyway though:

Yes it will be called twice. The complete_function will be called every time a gui.animate() finished. BUT if you gui.animate(node, gui.PROP_POSITION, …) twice for the same node it will only be called once. The second call to gui.animate() will if I’m not mistaken cancel the first.

Yes

#6

Yes, this would be perfect. I have tons of flags lying around that could do with a few quick checks :slight_smile:

#7

thanks!

#8

perhaps returning a list of all playing animations i.e gui.get_animating() could work out well? knowing if any animation is playing would be simply checking if the returned table has any entries, plus the running animations are right there too and can be manipulated … just a thought.

#9

Keeping track of running animations is a prime candidate for a Lua module and not necessarily something you need to include in the engine core:

-- animator.lua
local M = {}

local animations = {}

function M.animate(node, property, to, duration, delay, complete_function, playback)
	animations[node] = animations[node] or {}
	animations[node][property] = true
	gui.animate(node, property, to, duration, delay, function(self, node)
		animations[node][property] = false
		complete_function(self, node)
	end, playback)
end

function M.is_animating(node, property)
	if animations[node] then
		return animations[node][property]
	end
	return false
end

return M

Usage:

local animator = require("animator")

if not animator.is_animating(node, gui.PROP_POSITION) then
	animator.animate(node, gui.PROP_POSITION, vmath.vector3(0), gui.EASING_LINEAR, 2)
end
4 Likes
#10

While I agree that this is perfect for a simple module, I also like for that to be in the core engine api rather than the game one.

Is it safe to monkey patch the gui namespace?
I do it for some of the strings function and seems fine, but I’m not sure about the defold one.

#11

We have to remind ourselves not to put everything in the engine with respect to engine size and/or performance.
I think this is a good example where we don’t want to put functionality in the engine, which isn’t widely used by very many users, especially since the users can build this api themselves (as @britzl outline above)

As for adding functions to any global modules (vanilla Lua or Defold ones), you can do it if you want, I guess. But why add such functions to existing modules? When reading such code, it’s very unclear that it’s not an original function/variable. I would definitely recommend adding your own Lua module names.

1 Like
#12

This is a real challenge. It is very important for us to have a small engine and an API that is useful but also not limiting to developers. The size of the Defold engine is one of our true strengths. If we start adding too many of these nice-to-have APIs we will end up with a bloated engine.

1 Like
#13

I understand your reasoning and I completely agree on the size and scope of the core engine api.
Mine is just a personal preference really, hence the patching idea.

#14

you are the best :slight_smile: thank you.

i really love this engine, wish i had started using it earlier. what i like most is that it is bare bones, not bloated with all kinds of functions you don’t need to begin with and only end up compiling a 200 mega “hello world”.

i need to get more fit with lua so i can come up with modules like this all by myself.
i just have this confused state of mind, not used to using defold, not used to lua so everything is a bit “painful” …
if anybody has links to usefull lua resources please let me know

1 Like
#15

For Lua 5.0 but still largely relevant: http://www.lua.org/pil/contents.html

Compact “Learn Lua in Y minutes”: http://tylerneylon.com/a/learn-lua/

Found this video tutorial: https://www.youtube.com/watch?v=iMacxZQMPXs

2 Likes
#16

thanks again!

1 Like