Leaderboard

What works for me is to hound forums and look at what issues people are having and try to answer them. You don't have to post an answer or it doesn't even matter if it has been answered by someone else if all you want is a challenge. Just look at the problem, try and solve it. If someone else answers it, you can always check their reply and compare your approach with theirs. I recently replied to a question here that really fits the bill - It made me feel really proud of the solution I came up with and felt I learnt something as well. It also spawned another idea I would like to try in the future (maybe will never see the light of the day given my current ideas-wish-list but, hey, it's there). Another thing I would recommend is to read the docs. Do it a dozen times. I didn't get any of it to begin with but the more you read, the more it makes sense. A lot of the cool things a lot of people do is nothing more than an exploration of some basic functionality in a novel way.

Hi @pattysheppard Here's a couple variations using a liveSnap function to limit rotation. The first one has one drawback which you may or may not want. If you rotate counter-clockwise, like say 3 times, you'll have to rotate clockwise 3 times before it starts rotating again. The second one keeps track of the change in rotation to eliminate that drawback.

Hm, from what I can tell, this [probably] isn't a bug. The issue is that you're calling exportRoot() literally 100,000 times and each time, it basically wraps all the animations on the root timeline into a TimelineLite. So you've got things nested 100,000 levels deep. The browser is assuming this is a recursion error simply because there are so many calls to one function. For example, the first time you call exportRoot(), it wraps everything. The next time, the only thing on the root timeline is that previously exported stuff in a TimelineLite, thus it wraps THAT TimelineLite inside a TimelineLite and returns that. Same with the next time you call exportRoot(), and so on. Therefore, when the root timeline's render() method gets called, it loops through its children and calls their render() methods accordingly, and those do the same to their children, and so on. That's exactly how it's designed to work. But notice that the TimelineLite.prototype.render() method is getting called a ton of times in a row. One way to avoid this is to add some logic to avoid excessive nesting. Maybe dump them all out of your exported root before you call exportRoot() again, like: //De-nest things from the "allTweens" exported root... if (allTweens) { var animations = allTweens.getChildren(), startTime = allTweens.startTime(), root = allTweens.timeline, l = animations.length, i; for (i = 0; i < l; i++) { root.add(animations[i], animations[i].startTime() + startTime); } allTweens.kill(); } allTweens = TimelineLite.exportRoot(); ... Does that help?

Great solution by @mikel, which sparked and idea to use a jQuery forEach loop

Hi and welcome to the GreenSock forums, The problem with the repeating tween is that it makes the timeline's duration virtually infinite. When you add tweens to that same timeline in stopAnimation() function you are adding them at a time after when the previous tweens were added BUT the timeline has been continually playing past that point. In other words you are adding new tweens at a time that has already past which is why everything disappears immediately. Those new tweens you added complete as soon as they get added. I'm just making up numbers but lets say the startAnimation timeline has 6 seconds worth of tweens in it and an infinitely repeating tween. If you call the stopAnimation function at a time of 10 seconds (the repeating tweens cause it to play beyond 6 seconds) the new tweens will get added around a time of 6 seconds (in the past). In this case I would not add new tweens to the same timeline. I'd create two separate timelines in each function as shown below: This will work fine if you only need to start once and stop once.

Hello @thatkookooguy and welcome to the GreenSock Forum! My example below only shows your character facing backwards when scrolled up but not left to right, since i didn't have time to do the reverse backwards for side to side. Looks like you would need to add a class that places the CSS background-position-y at the value of 40px. So this way it displays the sprite image in a backwards state. If it was me i would add a new CSS rule like this that just handles the character to face up when scrolling up (so his back is facing you as he walks up): #char1.backwards, #char3.backwards, #char5.backwards{ background-position-y: 40px !important; } Notice i added !important declaration, that makes sure the background-position-y is always 40px for your image sprite to dispaly back of character. This way you would add the .backwards class when your character is getting scrolled up and is supposed to be walking up the page. So you would add that class when he walks up, then remove when he is walking from left or right. And add back again when he is moving up with the scroll-bar. Then binding an event to the mouse scroll wheel, detect if the scroll bar is going up or down. Then add the class .backwards to those 3 elements (#char1.backwards, #char3.backwards, #char5.backwards). But checking the scroll direction should probably be done with ScrollMagic enter event and check the event.scrollDirection for reverse (scroll up) or forward (scroll down). Since mousewhell can be buggy. Then you just need to detect two things on whether you add the .backwards class detect when scroll-bar is scrolling up and if your character is supposed to be walking facing up (you can mimic what i did for facing up for when you nee to face the character left or right) So this can be done with a simple add and remove of a CSS class and event binding for mousewheel or using ScrollMagic enter or update event to detect scrolling up and down. But others might have a better way of adding and removing the class either in the tweens and timeline or via scrolMagic event. Happy Tweening!

Now it will work in other browsers.

Hi @gareth, This could be a way ... Happy tweening Mikel

attached is a zip of the AS3 docs. I don't suspect they will ever change: AS3Docs.zip

In short, scope is the object that "this" refers to in a function. By default, the scope of a callback in a tween/timeline is the tween/timeline itself. With jQuery, most methods have the scope set to the element, which is what "this" refers to in the function. $("button").click(function() { TweenLite.to(this, 1, { color: "red" }); }); See if you can make sense of the scope here.

I did notice that the goToSlide function does use "this" inside it. TweenLite.to($slidesContainer, 1, { scrollTo: { y: pageHeight * $currentSlide.index() }, onComplete: onSlideChangeEnd, onCompleteScope: this // <= this??? }); But that's probably redundant because the function it's calling, onSlideChangeEnd, doesn't use "this".

No problem: Transforms are relative to the element itself (50% = 100px above), and top/left are relative to the element's container (50% = 300px above). Does that clear things up?

Yep, I generally prefer x/y (transforms) but there are some cases when you really need some of the benefits of top/left. You mentioned that your goal was to make things responsive, and an important thing to keep in mind is that transform-related percentages are based on something COMPLETELY different - the element itself rather than its container. So top/left percentages refer to the parent element's width/height but x/y refer to the element itself's width/height, making it very difficult to achieve certain things. For example, when I built GSDevTools, I had to use a percentage-based "left" value for the scrubber and other positioning so that things lined up perfectly when the user resized the browser. I suppose you could do calculations on every resize to set the proper x/y but there are down sides to that too.

Yep. That's what I'm talking about. It looks like the straight line animation is overshooting where the arcs start a tad. Your animation is a little different, but I usually set whatever I'm animating to the start position of a motion path to prevent it from jumping. var values = MorphSVGPlugin.pathDataToBezier("#somePath"); TweenLite.set(myElement, { x: values[0].x, y: values[0].y }); Left and top may appear to do the same thing as x and y, but they are totally different. The net movement from this tween will be 200. TweenLite.to(myElement, 1, { left: 100, x: 100 }); left and top will move an element to a new position, causing the browser to recalculate the layout. x and y are transforms, and just translate the pixels to a new position. Transforms do not affect anything and are usually hardware accelerated for better performance. Here's a good article that goes into detail about that. https://www.html5rocks.com/en/tutorials/speed/high-performance-animations/ Check out the difference in movement in this video. And here's a good article about doing percentage based translation with GSAP using the xPercent/yPercent properties. https://greensock.com/gsap-1-13-1

I'm guessing the error is happening around here: currentLoader = swfs.getChildAt(loaderIndex); As the stack overflow post states you are probably trying to access an index beyond what it is in the array returned by getChildAt(). It looks like you commented out important code that prevents the loaderIndex from getting too high if (loaderIndex == swfs.numChildren) { //reset back to 0 if the last swf has already played //loaderIndex = 0; //can't show stuff that was unloaded so lets stop mySO.clear(); loaderIndex = -1 swfs.load(); trace("all done everyone gone"); removeEventListener(Event.ENTER_FRAME, trackSWFPlayback); } since you are only incrementing loaderIndex using loaderIndex++ and never reseting it, my only assumption is that it gets too high. Hopefully this helps. Unfortunately we just don't have the resources to be digging into custom code in AS3 projects. We stopped supporting the AS3 stuff awhile ago.

Excellent. I just added a note to the docs about this to help others who may run into the same thing.

Hi @OSUblake, Thanks for the hint and the lessons. For mousewheel, button and key it is now ok. Kind regards Mikel

Hello @helleholmsen and welcome to the GreenSock Forum! I tested on Windows 10 on latest Firefox and Chrome. But could not replicate the light grey border you describe. What is the OS and OS version you see this on? Also what is the browser and browser version you are seeing this on? Any additional info can help us see what your seeing, Thanks

FAIL! I didn't check the second demo in other browsers... brb.

Makes perfect sense. If I'd thought about it a little longer, I probably would have had it. I'm liking GSAP more and more; it makes everything so stupidly easy. Thank you!

Hey, im a complete beginner but im still going to try and help you. Maybe you could try this: Create a function like this: function function1here() { var tl = new TimelineLite(); // add the rest here return tl; // put this at the end. } function function2here() { var pw = new TimelineLite(); // add the rest here return tl; // put this at the end. } function createMasterTimeline() { timeline = new TimelineLite(); .add(function1here()) .add(function2here()) timeline.timeScale(1)//used to control the speed of the timeline } // now call the mastertimeline function createMasterTimeline() now you should be able to do what you want and you can create the individual timelines

The only reason I can think of that'd cause a plugin to remain in _gsQueue is if _gsScope._gsDefine isn't defined which basically means that the core TweenLite hasn't loaded (and TweenLite is inside TweenMax, so as long as that's loaded, you should be fine too). I'm not very familiar with how a lot of these transpilers/bundlers do things under the hood but it sure sounds like an issue related to that since we know that importing the way you just suggested works well in virtually all the transpilers/bundlers.

Hi @mikel You only need to worry about scope if the function uses "this" inside it. What you want is to pass a parameter to the function like this. TweenMax.to(action,1,{scale:0.2, onComplete:goToSlide, onCompleteParams: [$currentSlide.next()] })

I did notice a slight jump at the very beginning. Not sure what's causing it. Your other animations would be smoother if you used x and y instead of left and top. Not sure about ignoring lines of code, but it's a good idea to make sure your images are loaded before trying to animate them as the layout might change. It's also a good idea to put all your scripts and code at the bottom of your page instead of the top. Just right before the closing </body> tag.

Hi @Kevin Abatan Your syntax looks fine, so I don't know what the issue is. Can you send me what you have so I can take a look? You can send me a PM if you don't want to post it publicly.

@PointC also shared a solution in similar thread:

@Carl shared this demo a while back:

What makes this community special is that folks around here (especially moderators) aren't just smart - they're thoughtful and kind. The more I visit other forums, the more I see how rare that is. Craig, you (and this thread) prove this point. Side note: Merry Christmas to all!

Great stuff, Craig. Very thankful for you and everyone that contributes to the community here. I continue to learn more and more each day and am often amazed by what I see. Thanks for being such a big part in making this community what it is. Carl

Well, it’s been 6 months since I wrote the post that started this thread and it appears to have been read quite a few times. Thank you to all who commented. I’m glad my story has inspired others to get involved in the GreenSock community. Congratulations to Jack and Carl on the continued development of GSAP. The new CustomEase is absolutely astounding! I’m looking forward to all the new goodies that will come in 2017. Also – a BIG thank you for the honor of producing the explainer videos for GSAP and Club GreenSock. It was such an exciting experience and you two were so much fun to work with. Cheers to my fellow moderators - Blake, Jonathan, Diaco, Dipscom and Rodrigo. You guys are so clever and talented. I keep learning more every day by reading your answers and tearing apart your CodePens. I’m truly honored to be included in such a tremendous group. A shout out to the GreenSock community members. Keep learning, asking questions, experimenting and creating. My original advice still stands. If you’ve never asked or answered a question here, please jump in and participate. We’d love to hear from you. I hope everyone takes some time for fun and relaxation over the holidays. See you all around the forum. - Craig

Hi, I modified the demo to show that each timeline (including the master / parent timeline) can have its progress illustrated by its own progress bar. Basically each timeline uses an onUpdate callback to achieve this. Each timeline passes 2 parameters to the setProgress function on each update 1: a reference to itself (the timeline being updated) via "{self}" keyword 2: a reference to the progress bar that should be updated based on the progress of "{self}" var progressBars = $(".progress") // lookup and cache all .proggres elements //create 3 timelines //note each timeline calls onUpdate which is a function that needs 2 parameters: // a reference to the timeline "{self}" // a reference to the progress bar // note progressBars[1] is the second element in the jQuery collection $(".progress") var box1Timeline = new TimelineLite({ onUpdate:setProgress, onUpdateParams:["{self}", progressBars[1]] }); box1Timeline.to("#box1", 1, {rotation:360}) .to("#box1", 1, {opacity:0}) //same approach for 2nd and third timeline var box2Timeline = new TimelineLite({onUpdate:setProgress, onUpdateParams:["{self}", progressBars[2]]}); box2Timeline.to("#box2", 1, {top:100}) .to("#box2", 1, {opacity:0}) var box3Timeline = new TimelineLite({onUpdate:setProgress, onUpdateParams:["{self}", progressBars[3]]}); box3Timeline.to("#box3", 1, {rotation:-360}) .to("#box3", 1, {opacity:0}) //note the master timeline also uses onUpdate to control the red progress bar var masterTimeline = new TimelineMax({ repeat:20, repeatDelay:1, onUpdate:setProgress, onUpdateParams:["{self}", progressBars[0]] }); //master timeline resets all progressBars to scaleX:0 masterTimeline.set(progressBars, {scaleX:0, transformOrigin:"left"}) .add(box1Timeline) .add(box2Timeline) .add(box3Timeline) // setProgress() takes parameters that tell it // which timeline it's dealing with // which progressBar it needs to adjust function setProgress (timeline, progressBar){ TweenLite.set(progressBar, {scaleX:timeline.progress()}) } http://codepen.io/GreenSock/pen/soJai

This is much trickier than you might expect. Let me explain: Most tweening engines use a "fast and dirty" technique for repeating which involves waiting for the tween to finish, and then just restarting it at that point. However, this technique is plagued with timing issues related to the fact that frame rates are rarely perfect and there can be small delays that cause the final render to be tardy. Imagine a 0.5 second tween that actually finishes in 0.6 seconds because the browser was busy handling a lot of rendering tasks. That means the next iteration of the tween is 0.1 seconds late. Then if that next iteration has the same thing happen, the whole sequence of iterations is now 0.2 seconds off, and so on. It can quickly add up. GSAP is specifically built to allow everything to be perfectly synchronized, so these "little" inaccuracies are intolerable. What if you built an animation that required a tween to repeat 10 times and then another tween of a different object starts at exactly the moment the 10th repeat finishes, all sequenced nicely inside a TimelineLite? With the "quick and dirty" repeat technique, things would no longer by synchronized and it'd be REALLY annoying. Plus, try jumping to a specific time in the iterative sequence, like if you have a 0.5-second tween that repeats 100 times (thus 50 seconds long) and you want to jump to exactly the 15.34 second spot? With TweenMax, that's simple. tween.totalTime(15.34). With other engines, it's pretty much impossible unless you figure out the math yourself and reset the number of repeats thereafter, etc. The code in TweenMax and TimelineMax that handles the repeat and yoyo functionality is much more precise, but consequently it also costs more kb. That's not acceptable to add into TweenLite's core because one of the top goals in TweenLite is to keep file size down and only have the essential features. Since you can technically accomplish repeating and yoyo-ing already in TweenLite by using an onComplete that either calls the tween's restart() or reverse() method, we can't justify the extra cost or the slight performance hit for the extra logic. If you want extremely precise repeats/yoyos that integrate perfectly into sequencing behaviors in the timeline classes, you should use TweenMax. However, if you need to minimize file size, you can crack open the TweenMax file and gut it of any extra classes that you don't need (like TimelineMax, BezierPlugin, EasePack, etc.). I think you'll find that they're pretty well commented in terms of where they're located in the source.