Ah, perfect. Thanks for this!!!
alex
Hey madmulti,
The issue should be fixed in 2014.2221. Can you please confirm?
Thanks,
alex
Edit: actually the .cancel call has some issues. I just ran more tests based on your code, and something is not ok. Looking deeper.
alex
Ah, i did some more digging and got a complete answer to this. If you define your tween as a variable instead of a object property, it works ok…
local tween
local function cleanTween()
transition.cancel(tween)
end
local rotOcto = function()
tween = transition.to( octo, { time = 40, rotation = math.random()*360, onComplete = cleanTween } )
end
If you use your approach, with the tween being part of the object table, the cancel call cancels transitions it should not.
So please use this solution as a workaround, and i’ll fix the behavior for tweens that are defined inside a LUA table.
Thanks,
alex
Any news on this? I’m sorry I’m pressing this but I have two updates and one release waiting in line. I can’t go to older version because there are other issues. G1 would be an option but I have already converted to G2 and don’t wish to go back.
Should I open a new bug case for this?
Polygonblog: use my workaround and you’llbe ok. It’s described earlier.
Do you mean defining the transition as a variable instead of an object property? I tried it, but it doesn’t make any difference. Crashes anyway.
polygonblog: well… you had to umplement it in wrong way. We have hundreds of transitions and removing this workaround makes our games crash all the time because of onComplete firing twice.
local t local function onCompleteFnc(target) if t then transition.cancel(t) t = nil end -- do something end t = transition.to(obj, {x = whatever, onComplete = onCompleteFnc} )
Tested hundreds of times every day - works like a charm.
It would be great if you showed me how to fix my test case with the workaround. It’s a simple code, you can try it yourself.
I guess they want you to use local variable instead of table variable to hold the transitions:
local function CreateBubble() local t1 local t2 local function FloatRight(\_object) local function FloatLeft() t1 = transition.to(\_object, {time=4000, delta=true, x=\_object.contentWidth\*(-1), onComplete=FloatRight}) end t1 = transition.to(\_object, {time=4000, delta=true, x=\_object.contentWidth, onComplete=FloatLeft}) end local function FloatUp (\_object) local function RemoveMe() if t1 ~= nil then transition.cancel(t1) t1 = nil end if t2 ~= nil then transition.cancel(t2) t2 = nil end display.remove(\_object) \_object = nil end t2 = transition.to(\_object, {time = math.random(2500,5000), y = -100, onComplete = RemoveMe}) end local bubble = display.newCircle(math.random(1,1024),810,math.random(4,40)) FloatRight(bubble) FloatUp(bubble) end timer.performWithDelay(11,CreateBubble,0)
However, please note, after testing the code above, it still crashes.
Therefore, your problem is not just about “onComplete firing twice” (or the workaround above is not totally correct, any one can help?)
The problem is still possibly lying in the race condition I told you in another thread.
Is this still unsolved? I’m seeing some erratic behaviour related to transition.to and onComplete. Probably related to this thread. I haven’t been able to produce a test case that would trigger a crash consistently, but there is definitely something wrong, since the exact same code never crashed in G1. I’ll try to dig deeper and test the workaround suggested by Alex, but I would like to know whether or not the problem discussed in this thread has been solved?
@polygonblog: It should be solved. We pushed that a while ago into daily builds. If you come up with a reproducible case let me know.
Thanks,
alex
@alexf: I managed to produce a reproducible test case. I have now encountered the same issue with two of my older apps that worked just fine in G1. So I cannot update my apps at the moment. Let it run for a while and you’ll see an error. Tested with Build 2014.2282.
local function FloatRight(\_object) local function FloatLeft() \_object.transition1 = transition.to(\_object, {time=4000, delta=true, x=\_object.contentWidth\*(-1), onComplete=FloatRight}) end \_object.transition1 = transition.to(\_object, {time=4000, delta=true, x=\_object.contentWidth, onComplete=FloatLeft}) end local function FloatUp (\_object) local function RemoveMe() if \_object.transition1 ~= nil then transition.cancel(\_object.transition1) end if \_object.transition2 ~= nil then transition.cancel(\_object.transition2) end display.remove(\_object) \_object = nil end \_object.transition2 = transition.to(\_object, {time = math.random(2500,5000), y = -100, onComplete = RemoveMe}) end local function CreateBubble() local bubble = display.newCircle(math.random(1,1024),810,math.random(4,40)) FloatRight(bubble) FloatUp(bubble) end timer.performWithDelay(11,CreateBubble,0)I’m having problems with crashing (on device only–both simulators are fine) when my onComplete calls a function that uses timer.xxxDelay() to spawn a new transition. The full description is here…does this seem related to the same issues??
Can someone provide me with a bug number for this please?
Dewey, I don’t know if this is related or not.
Since I don’t have any piece of code other then my games, that can simulate this behaviour, I cannot create a case and attach a proper bug report to them.
could you please create a case for this with your samples?
just saw this in my logs…dont know if its related or not but I’m definitely getting a memory leak:
Jun 3 21:57:48 dgiphone aggregated[70] <Warning>: notify name “com.apple.powerlog.BasebandHasCDRXCapability” has been registered 12580 times - this may be a leak
To summarize the workaround described in this thread, I believe the recommendation is to transition.cancel(theTween) from within the onComplete listener. Do I have that correct?
I have implemented this suggestion and my app still crashes on the device, but runs fine in the Apple iOS simulator.
I guess that means the problem I’m having is different from the one described in this thread…Alex or Rob, have either of you guys got any advice for other things I might try??
Thx
Dewey
dgaedcke: A test case would be great. I tried something with the code you posted on the detail thread and it does not replicate.
Thanks,
alex