Hi @tntwickey,
It’s on our radar and we’ll investigate/fix as soon as we can. I appreciate your patience so far, sincerely.
Brent
folks…
just use the transitions management from code exchange.
You will have to modify it a bit, so that tnt manages execution of onComplete function, but at least it will work properly.
The reason why the object doesn’t animate is because you’re not moving it from where it is.
If you set y=50, the object animates again after the delay.
BTW:
After changing y=50, the code will work even if you change the delay to 200, thus canceling the initial transition.
(tested on G1.0 build 2013.1259 and G2.0 build 2013.2068)
Thanks. I was trying to find a piece of code that showed un-expected behavior and that isn’t it. My game is still broken but the transitions are a lot more complicated. I will ID a simple example ASAP.
This is the original sample in this post, and it is still broken. This doesn’t really apply to my code so looking for another example.
local d = display.newRect(50, 50, 50, 50) local t = transition.to(d, {time = 10000, x = 50, y = 50, delta = true, onComplete = function() print "whateva" end}) transition.cancel(t) d:removeSelf() d = nilYeah, there’s still some stuff that doesn’t work properly with canceling transitions and onComplete handlers.
I have a Bug Report case that’s still being investigated.
Do you have a specific example ingemar? I get weird behavior some places and others seems to work fine, so it’s difficult to pinpoint.
My issue is pretty much the same as the one @krystian6 has reported. It seems to be all about timing.
It took me forever to try to isolate this problem. Finally have a solution.
transition.cancel on nil values can occasionally cause new transitions to not occur, or stop transitions that are in progress. This is very hard to duplicate as the results vary from run to run.
Try the following:
local transitionArray={} local gearButton=nil local gearShowing=false local gearFunc=nil --create two moving items local sfxButton = display.newRect(0, 0, 50, 20) sfxButton.y=display.contentCenterY sfxButton.orgY=sfxButton.y local bgmButton = display.newRect(0, 0, 50, 20) bgmButton.x=sfxButton.x+sfxButton.width\*1.25 bgmButton.y=sfxButton.y bgmButton.orgY=bgmButton.y bgmButton:setFillColor(150, 255) gearFunc=function(self,event) if(event.phase=="ended")then local rotate=-90 if(gearShowing==false)then gearShowing=true else gearShowing=false rotate=90 end transitionArray.gearButton=transition.to(gearButton,{time=150,alpha=1.0,rotation=rotate}) if(rotate\<0)then transitionArray.sfxtrans=transition.to(sfxButton,{time=150,y=sfxButton.orgY-50}) transition.cancel(nil) transitionArray.bgmtrans=transition.to(bgmButton,{time=150,y=bgmButton.orgY-50}) else --hide them transition.cancel(nil) transitionArray.sfxtrans=transition.to(sfxButton,{time=150,y=sfxButton.orgY}) transitionArray.bgmtrans=transition.to(bgmButton,{time=150,y=bgmButton.orgY}) end end end --create the action button gearButton=display.newRect(0, 0, 50, 50) gearButton:setReferencePoint(display.CenterReferencePoint) gearButton.x=display.contentCenterX gearButton.y=display.contentHeight-50 gearButton.touch=gearFunc gearButton:addEventListener("touch", gearButton)
Now move the transition.cancel(nil) statements around. You will see various things don’t animate depending where you place them.
*Why would I ever cancel nil? tracking all animations with the old transitions required saving their handles in tables. Many time these entire tables got cancelled (like in scene change, or object deletion) and sometimes transitions were never set or cleared some other way. It’s just that I couldn’t get a could example to demo with a real value in transition.cancel but it definitely occurs.
=========SOLUTION------------------
add this to main.lua
local oldTransCancel=transition.cancel \_G.transition.cancel=function(id) if(id)then oldTransCancel(id) end endtntwickey: actually I think this is a bug in your code.
transition.cancel without any parameters should cancel all of the transitions.
This is a requirement in my opinion, not a bug.
It’s up to you to make sure thay you always pass a proper value to transition.cancel.
Krystian
That might be true. However, all this code worked perfectly using the old transition 1.0 library. So as far as compatibility goes, this makes my game work as before.
I will be using transition 2.0 differently as I no longer have to maintain transition tables. So this won’t apply in new projects. I’m sure there are a few others who also used transition 1.0 the way I did though. Hopefully this helps
I appreciate it alexf. Will the fix turn up in the next daily build?
Any update on this?
Hi @tntwickey,
It appears that this issue was resolved in Build #1243. Can you please download it and test your scenario?
Thanks,
Brent
Thanks Brent. I saw the changelog that mentioned transitions and tried it without luck.
I am on currently on 1247 and it’s still broken.
Anything? Should I file a bug report? How can we get this resolved?
Bug was submitted long time ago:
26812
Hey guys,
I really thought that got fixed through the last update.
Looking at it now.
alex
Hey alexf. Any progress?
Alexf and whomever is working on this:
Try this:
local trans1,trans2=nil,nil local d = display.newRect(50, 50, 100, 100) local d2 = display.newRect(150, 50, 50, 50) trans1 = transition.to(d, {time = 1000, x = 50, y = 150}) trans2 = transition.to(d2, {time = 1000, x = 50, y = 350}) timer.performWithDelay(2000, function() transition.cancel(trans1) transition.cancel(trans2) trans1 = transition.to(d, {time = 1000, x = 50, y = 150})--does not move trans2 = transition.to(d2, {time = 1000, x = 150, y = 50}) end, 1)
Line 12 does not animate. This is one of the issues I am seeing. Trying to isolate all of them.