Freaking infinite loops.

[dnunes]

. . I did a small isometric game and it uses TweenMax to all its easings (players moving, x/y-transitions, fades and even as timer/updater).

 

. . I am mostly using direct calls to TweenMax.to calls when I just need to move something that don't need a lot of control and sometimes I'm creating the "new TweenMax" to use .play and .reverse (and onReverseComplete, most of the time). Everything works as expect (although I didn't quite get the logic when using the reverse()--does the totalProgress and currentTime change as well? They go backwards? a "currentTime = 0" when reversing will go to the original end or the beginning?). My biggest problem right now is that after some time using the game (players getting in and out, a lot of transitions and movements ocurring--but mostly only some 30 or 40 at at time) just hangs in an infinite loop inside "SimpleTimeline.as". I tried to debug it, but the biggest problem is that I couldn't spot a way to reproduce it non-randomly, so I'm clueless here. I'm tracing a lot of information but they are not helping a lot.

. . Do you have any ideas of how can I debug the following error:

 

Error: Error #1502: A script has executed for longer than the default timeout period of 15 seconds.

at com.greensock.core::SimpleTimeline/renderTime()[D]

at com.greensock::TweenLite$/updateAll()[D]

 

 

. . The line 70 is a "while (tween)" (this loop goes "next = tween.nextNode;" and then "tween = next" at the end, so it's basically a "while (tween=tween.nextNode)". I couldn't really find a way to debug, since I don't understand the properties very deeply. Any help would be very appreciated.

 

. . C'ya.

[GreenSock]

What version are you using? Please update to the latest version and let me know if it still happens for you. I believe what you're seeing is a bug from an earlier release.

 

And as far as the reverse() logic and how it affects currentTime/currentProgress, etc., check out the video at http://blog.greensock.com/timeline-basics/. Think of a TimelineLite/Max like a MovieClip timeline. If you reverse, it goes back towards the starting point, so the currentTime would go back that way as well.

[dnunes]

What version are you using? Please update to the latest version and let me know if it still happens for you. I believe what you're seeing is a bug from an earlier release.

. . I think it's the lastest one: TweenMax 11.131 (12/18/2009). I downloaded again and the available for download seems to be the same. I replaced nonetheless and will recheck.

. . Anyway, can you give any insights on that piece of code inside the "while"? What does that do? Debugging a little it seems to loop over every tween that exists every frame, right? Could that be that somehow dead tweens are still being ran (or tried to)? Sometimes I get way over 150 iterations on the loop, untill the point that my Flash Player cannot cope with the speed and hang completely.

 

 

And as far as the reverse() logic and how it affects currentTime/currentProgress, etc., check out the video at http://blog.greensock.com/timeline-basics/. Think of a TimelineLite/Max like a MovieClip timeline. If you reverse, it goes back towards the starting point, so the currentTime would go back that way as well.

. . Got that part, but what about changing the property value? Imagine that I have an object and some property will be tweened from "1" to "50". If I do ".play", then ".reverse", then ".pause", then ".currentProgress = 0", will it be on "1" or "50"?

 

. . Amplexos.

[dnunes]

. . Just checked and I was really using an older version. Anyway, the problem is still ocurring (even more frequently, as I added a little more tweens to the game).

 

. . I'm using a lot of "TweenMax.killTweensOf()". Does this function remove the tween from the "main list" (iterated in the 77th line of core/SimpleTimeline.as) or it just "stops" it, setting it to disabled? Because if I'm only "stopping" an unnamed tween I will never be able to really "kill" (remove from the existing tweens master list) and they will just add to the point of hanging to Flash Player, right? Maybe this is the problem? How can I really remove the tween so it will act as never existed? I can change the code to save a reference and then use it, if needed, but I need to really clean the tweens out so that they won't keep adding to the pile.

[GreenSock]

Did you update ALL your classes? One of the key updates was in com/greensock/core/SimpleTimeline.

[dnunes]

Did you update ALL your classes? One of the key updates was in com/greensock/core/SimpleTimeline.

. . They are all updated. I replaced the whole "greensock" folder I had. SimpleTimeline.as have "Date: 1/15/2010" (you should really change to ISO dates, btw).

 

. . Any chances of the tweens are not being removed, just stopped/paused and that's causing the problem? I'm tracing a lot of things to check it out right now, but any help would be great.

[GreenSock]

I'm using a lot of "TweenMax.killTweensOf()". Does this function remove the tween from the "main list" (iterated in the 77th line of core/SimpleTimeline.as) or it just "stops" it, setting it to disabled? Because if I'm only "stopping" an unnamed tween I will never be able to really "kill" (remove from the existing tweens master list) and they will just add to the point of hanging to Flash Player, right? Maybe this is the problem? How can I really remove the tween so it will act as never existed? I can change the code to save a reference and then use it, if needed, but I need to really clean the tweens out so that they won't keep adding to the pile.

 

TweenMax.killTweensOf() will completely kill the tween - you don't need to worry about it hanging around for a long time.

 

And yes, if you pause() or stop() a tween, it doesn't kill it, so it will technically hang around so that you can resume() or play() it again later.

 

It would be SUPER helpful if you posted a sample FLA that demonstrates the problem (please make it as simple as possible - no need to post your whole app). I'm not able to look at anything today (Sunday) but I'll dig into it ASAP if you post a sample.

[dnunes]

. . Ok, just found the reason.

 

. . Debugging a little more into the code, it seems that the root of the problem is the tweens linked list. It seems that at some point, when removing a tween, it points the "next" of a tween to another instance that is "before" the "current", so it will loop through that range indefinitely (like, the "next" on the _6_ is pointing to the _2_, so it will go: "2, 3, 4, 5, 6, 2, 3, 4, 5, 6, 2, 3, 4, 5, 6" over and over again).

. . The biggest of the problems: I have no clue whatsoever of what may be causing it, and it happens very randomly during the gameplay. Sometimes I'm just walking, sometimes I'm chatting, sometimes I'm in the middle of a multiplayer game... For now I'm probably switching to another tween library until I find a way to efficiently debug the code.

. . Any tips? Keep in mind that it happens very randomly and right now the only debugging technique I can use is to write a *HUGE* log and then analyze the contents after the crash. I tried breakpoints, but since it happens with no pattern, I can only detect the moment after it happened and I'm not able to go back on time and check the values and what happened before.

[GreenSock]

No chance of you posting a sample, huh? Darn. I'd sure like to see this because if there's a bug in the code, there's nothing I want more than to squash it. If you see any problems in the logic of the linked list code, please let me know. Otherwise, I'll recheck it again but if there are any samples you can send with broken behavior, that would be amazingly helpful. It's always tough to troubleshoot blind.

[dnunes]

No chance of you posting a sample, huh?

. . The problem is that even I don't know exactly when this happen. To check the bug I am opening a lot of instances of the applications in a "automatic pilot mode" and waiting. Sometimes it happens after some 4 or 5 minutes, sometimes it happens only half hour later =/ I checked the linked list logic and it seems to be ok. The thing is that there are so many tweens going on being created/removed that somehow it is not behaving as expected. The sample would be the whole application code and you would have to patiently wait for the problem to happen. This is probably the worst situation I've ever had to debug.

 

. . I am right now trying to "reuse" an instance of TweenMax to make sure that for every player I am going to have only one instance of the class (I removed the "autoRemoveChildren" so that it will only be disabled rather than removed from the timeline at the end of the tween) for the lifetime of his presence on the game world (to avoid that many creations/destroys), but I am having a terribly hard time figuring out exaclty what to do. It goes like this:

package {
 class player {
   private var tween:TweenMax;
   private var tweenedObject:Object = new Object();

   public function player():void {
     this.tween = new TweenMax(this.tweenedObject, 1000, {
       'ease': Linear.easeNone, 'onUpdate': this.moving, 'onComplete': this.stopped
     });
   }

   //callback. the server calls it when another player moves.
   public function playerHasMoved(newPosition:Object):void {
     this.tween.setDestination('x', newPosition.x, true);
     this.tween.setDestination('y', newPosition.y, true);
     this.tween.totalProgress = 0; this.tween.invalidate();
     this.tween.restart(); this.tween.play();
   }

   private function moving():void {
     //position checks and all the kinky stuff
     this.avatar.x = this.tweenedObject.x;
     this.avatar.y = this.tweenedObject.y;
   }
 }
}

 

. . The idea is to tween the "x" and "y" properties of the "tweenedObject" (this.tweenedObject). it is doing this way because there is a lot of game login involved in "moving", so in the "onupdate" (that calls the "moving" method) I update the player position based on the properties of this dumb object.

. . The idea is to avoid the "remove" and "addChild" calls into the SimpleTimeline, but it is just not working (the "x" and "y" properties are returning "NaN"). Not sure if I am doing something terribly wrong.

 

--------------

 

UPDATE:

. . Now the idea of using only one tween is working. I just had to call the "invalidate" BEFORE the setDestination. I will keep trying to debug the other [monster] error.

[GreenSock]

. . The problem is that even I don't know exactly when this happen. To check the bug I am opening a lot of instances of the applications in a "automatic pilot mode" and waiting. Sometimes it happens after some 4 or 5 minutes, sometimes it happens only half hour later =/ I checked the linked list logic and it seems to be ok.

 

It's okay that you don't know exactly when it happens - as long as you send me a file that will eventually throw the error, I can add trace() statements, poke around, etc. Otherwise, I'm working completely blind because I cannot seem to reproduce any such problem on my end.

 

Also, you're adding a lot of unnecessary code. Since you're restarting the tween anyway, this could be simplified:

 

//BEFORE:
this.tween.setDestination('x', newPosition.x, true);
this.tween.setDestination('y', newPosition.y, true);
this.tween.totalProgress = 0; 
this.tween.invalidate();
this.tween.restart(); 
this.tween.play();

//AFTER:
this.tween.vars.x = newPosition.x;
this.tween.vars.y = newPosition.y;
this.tween.invalidate();
this.tween.restart();

 

setting totalProgress to 0 is the same as restart() and you don't need to play() too (restart() automatically plays).

 

Feel free to send me an FLA via e-mail or PM if you don't want to post it here.

[GreenSock]

Okay, after spending a few hours analyzing things, I believe I found the issue. It would only occur if a tween/timeline is removed/killed/disabled more than once and only when the parent timeline is in a particular spot in the linked list while rendering (very rare). I posted an update that resolves the issue - would you mind downloading the new code, updating your classes, and letting me know if everything works well for you now? http://www.TweenLite.com. Sorry about the hassle.

[dnunes]

Okay, after spending a few hours analyzing things, I believe I found the issue. It would only occur if a tween/timeline is removed/killed/disabled more than once and only when the parent timeline is in a particular spot in the linked list while rendering (very rare). I posted an update that resolves the issue - would you mind downloading the new code, updating your classes, and letting me know if everything works well for you now? http://www.TweenLite.com. Sorry about the hassle.

. . Hey, Jack, since the code was already online (the guys sent the campaign online without telling me beforehand, he he =/) I worked around it disabling the autoRemoveChildren from TweenLite.as and doing the sorting/removing myself, reusing tweens everywhere I could. I ended making my code better, actually, but I don't have the old version with me right now. I'll give it a shot as soon as I can, anyway (probably tonight) and get back to you.

 

. . Thank you for the effort and I am glad the report have maybe helped to improve the library.

[bladewheels]

Any chance of posting a sample app that fails with the old TweenLite but passes with the new version?

 

I'm a Flex n00b & have been tasked with proving that we can re-introduce TweenLite, having removed it due to random freezing in our production code.

 

TIA

[GreenSock]

Any chance of posting a sample app that fails with the old TweenLite but passes with the new version?

 

I'm a Flex n00b & have been tasked with proving that we can re-introduce TweenLite, having removed it due to random freezing in our production code.

 

Wouldn't your production code be the example you're looking for? What version were you using at the time - do you know? I'm quite confident v11 performs better than ever and there's not a single known bug at this point. I'm very sorry to hear about the trouble you ran into previously and I really wish you would have contacted me as soon as you had any issues - I work VERY hard to promptly squash any bugs that pop up because I know huge quantities of companies are relying on the code in business-critical apps. I have found that more often than not, apparent "bugs" in TweenLite/Max actually end up having nothing to do with the tweening engine but were instead caused by end users' surrounding code. But like most software, there have been occasional bugs that needed squashing. One of the great things about having a huge user base is that any bugs typically bubble to the surface quickly and developers contact me if they run into anything odd, so bugs get identified and squashed quickly.

 

Anyway, if you have any code that wasn't working well with previous versions of TweenLite, I'd LOVE to see it. And I'd be willing to bet that if TweenLite was indeed to blame for the problem, your code will work flawlessly with the latest version of TweenLite. Give it a shot. http://www.tweenlite.com

[bladewheels]

Well, the prod. code *might* be an example but it's hardly small nor focused on demo'ing the behaviour *occasionally* seen; I might have trouble convincing the suits that this latest version will fix our (sporadic) problem without a demonstrable use case.

(So *occasional* that I've never seen it in QA nor Dev but customers have repeatedly reported it in Prod...)

 

Being new to AS, timelines, tweening et. al. I was hoping for a small app that would break/fail on pushing a button with the old lib but not the new.

 

I understand it's a lot to ask, but I thought it would be worth asking - never say never, right?

 

I believe the TweenLite version in use was v11.101 from 10/22/09, 11:50PM according to com/greensock/changelog.txt

I only started working at this firm a couple of weeks ago so I guess I am letting you know about this issue ASAP; apparently a displayable item *freezes* but, being so new to it all I can hardly describe the way TL is used here.

 

Thanks for your prompt response and the (apparent) wonderfulness of your contributions.