Jump to content
Search Community

Small debugging feature request

gdstudios test
Moderator Tag

Recommended Posts

I've found that there are a lot of sites that I've built have a whole lot of tweening going on at once, particularly on page/section transitions. During the development process, I've had bugs that have shown up where something would break somewhere due to the timing of everything basically running over itself and not making an important function call in time, or a variable/textfield/whatever ending up with a null value because the variable was supposed to be set by then, etc...

 

You see the broken issue after it happens, but you can't pinpoint exactly when and what's happening because all 16 of your tweens are set to complete in less than a second. It's just too fast to see the sequence of events, even after running it several times.

 

I hope I'm not the only one that has had this problem before, and I honestly don't know how completely foolproof my edit is with every single class in the greensock library or every implementation, but I do know that I haven't had any issues with TweenNano, TweenLite, or TweenMax, which are the only gs classes I really use in every single project.

 

That being said, I broke the cardinal sin of not extending TweenCore.as, and instead editing it directly, to avoid editing all of the class paths of extended classes in the greensock library. I put a new public static variable in called 'timewarp':

 

public class TweenCore {

//GDS EDIT
	/** @public duration multipier to tweak global tween duration for debugging purposes*/
	public static var timewarp:Number = 1;
//END GDS EDIT

	/** @private **/
	public static const version:Num.....

 

and then in the constructor:

 

public function TweenCore(duration:Number=0, vars:Object=null) {
		this.vars = vars || {};
//GDS EDIT
		this.cachedDuration = this.cachedTotalDuration = duration * timewarp  || 0;			
		_delay = this.vars.delay * timewarp || 0;
//END GDS EDIT

		this.cachedTimeScale = this.vars.tim...

 

 

So basically, all I have to do now to globally slow everything WAY down temporarily is add this code to my document class:

package  {
import com.greensock.core.TweenCore;
public class TimewarpTest {

	public function TimewarpTest() {
		TweenCore.timewarp = 5;
	}
}	
}

 

By setting it to 5, every tween in the whole scop, no matter how deep or hidden will be 5 times longer than it would normally be. Your delayed calls will be affected as well, so basically it should run as if you edited every single tween duration manually. By default, it's set to 1, so if you don't want to edit, or you want to set it back to default, simply delete the "TweenCore.timewarp = whatever" line, and all is well.

 

I don't know if there is an easier way to do this across the whole site with TimelineMax, or if there is even an easier way to achieve what I did, but it works for me.

 

I've also found that if you are building a site that you have to test frequently, and you are tired of waiting for some animation to finish before it gets to the part that you are working on, it also works backwards - if you set it to 0.2, it will run all tweens in 1/5 of the tween's duration.

 

Just thought I'd share if it would help anyone, or if Jack would like to include something similar in the future.

Link to comment
Share on other sites

Doesn't your edit simply alter the delay, not the duration of the tweens? [EDIT]

 

Anyway, you're kinda duplicating some existing functionality. Have you seen the TweenMax.globalTimeScale setter? It pretty much does exactly what you described. Or you could put your tweens into a TimelineLite or TimelineMax and set its timeScale to whatever you want. It makes things very simple to control as a whole. Speed it up, slow it down, or whatever. The problem with your implementation is that it's very static - you cannot slow things down and then speed them up dynamically. If you haven't watched it already, check out the basics video at http://www.greensock.com/timeline-basics/.

Link to comment
Share on other sites

By editing cachedDuration, it effects the tweens as well.

 

I have this in place just as a debugging tool, where if the problem exists in any TweenMax, TweenLite, etc, and it isn't necessarily in the same scope or sequence of tweens. I did this so long ago, that I honestly don't remember why I was having a problem with globalTimeScale, but for some reason it didn't work for what I needed it to do. Could it be because TweenLite doesn't pay attention? I honestly don't remember.

 

I needed this way after I already finished most of the existing functionality, which at the time I don't think the TimelineMax/Lite classes were even available. I just figured that it might help someone.

Link to comment
Share on other sites

No worries. And yeah, when glancing at your code I missed the edit you made to the cachedDuration (I'm pretty sleep-deprived).

 

Altering the TweenMax.globalTimeScale does indeed affect all tweens/timelines including TweenLite instances. If you run into any trouble with it in the future, just let me know and I'll happily take a peek. As far as I know, it works like a charm.

 

Thanks for sharing. Didn't mean to sound like your sharing was unwelcome - I just typically discourage people from editing the class files because it can cause all sorts of problems and makes maintenance more difficult on them (every time they update to the latest version for new features or bug fixes, they need to re-apply their custom edits).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...