GaryD

Good to know thanks for these tips! One more question related to my original example. It appears that removing the short 0.001 second do-nothing tweens prevents the call tweens from triggering when the progress is reset to 0. Is this the expected behavior, and is there a way to change this? I'd like to have the call tweens triggered when the progress is reset to 0 (as it is with the do-nothing tweens), but including even tiny do-nothing delays is making it possible for me to seek (with a gui slider) to these positions between the call tween and the following animation... which is a bit unsightly in my app.

Thanks PointC, this is what I was trying to accomplish here. And thanks OSUblake, that fixes my problem. "Pause" probably wasn't the best choice of word for me to use here... I just meant adding a short amount of time to the timeline in which nothing is actually animating. On a related note, I'm not very experienced with codepen, and seem to make several of these kinds of small errors. For my bigger project, I'm using TypeScript which helps my editor detect and highlight this kind of error. And I'm also using chrome which displays a good amount of debug information after something has gone wrong. Do you have any tips for getting this kind of information while working in codepen? Thanks again for your help!

Hello, I am exploring whether organizing my animation into multiple separate timelines might be helpful. I'm running into some differences that I wasn't able to find an explanation for in the docs... This codepen includes simple examples organized into methods named working() and notWorking(). The working() example is similar to how my app is currently building a single timeline, in that it adds a callback and short pause after each chunk of animation... and then updates the progress on that timeline to 1 (the end) to trigger that callback before adding more animations. After the entire animation has been built, these callbacks are called one more time before they are played (as a result of returning the progress to 0). The notWorking example is my attempt to accomplish a similar thing, but with multiple timelines that are all grouped together into a single master timeline. I suspect there may be multiple problems with this implementation... I could probably work around them, but hope that resolving this confusion might help me better understand how to best organize my animations.

Will do. Thanks for this feedback.

Thanks for this suggestion Zach. Over the weekend, I spent a bit of time trying to put together a simple version of what I am describing... but even these simple examples became quite complicated. This is leading me to believe that the need for this kind of "pattern" is probably not as common as I had originally thought. In all of the simpler examples that I was able to come up with, simply hiding objects to simulate their being destroyed or not yet created was sufficient. Or maybe there is some complexity in my own problem that is preventing me from seeing that it could also be solved in this simpler way (?). Sorry I was not able to describe this situation more clearly, or come up with a truly simple example to share. I'll stick with my current solution to what no longer seems like a pattern that others are likely to have differently organized solutions for solving.

This is my first post in these forums, so I'd like to start off by saying thanks. I've been using GreenSock for a month now, and have been impressed with the API and documentation. It's really been a pleasure to work with. My question is about whether there are any recommendations or best practices around creating, removing, or rearranging elements in the DOM... during animations. For simple animations, I suspect it is easiest to make such changes before or after the animation is done, and to just hide them in some way while animating. Maybe my situation is not very common, but my animations are being driven programmatically and the types and numbers of such changes is variable and seems quite cumbersome to manage. So I am wondering whether others are dealing with this kind of problem, and how. The technique that I have stumbled onto involves using timeline.call() to set callbacks that toggle these changes to be made or un-made every time they are triggered/called. These callbacks also also keep track of the objects being created or destroyed, to allow them to persist along with any animations applied them. This allows the user to see the correct thing when they restart or scrub backwards through the timeline. I have some utility methods to help create these callbacks with a few variations whenever they are needed (and also to make other undoable changes to the rest of my application's state). Does this sound like what others are doing? Or are there other ways that people are tackling this kind of problem? Or maybe it's just not a very common problem(?).