Timeline repeat infinity and setting totalProgress ERROR

[YellowSock]

If you set a timeline to repeat for infinity (=-1)

and then set a relative start point via totalProgress (for distributed placement) an error occurs.

in TweenCore.as setTotalTime function line...

this.cachedStartTime = tlTime - (time / this.cachedTimeScale);

Results in a negative which errors

for instance one third 1/3 = 0.333333333333 starting point through an infinite timeline of...

999999999999 = 666666666666

The value time is never bigger, so a tlTime that's negative results, which is in error!? I think, or maybe it eventually starts moving forward after 1/3 of infinity?

I might try replacing onComplete with a call again to repeat = 1 but that's just an external patch.

[YellowSock]

No wait a minute totalProgress = 0 on a never played but freshly restarted timeline results in negatives there too...

-9.99999791639 E7

So I'm not sure way but they don't play and stay frozen at point zero.

 

Now I'm digging around debugging why the this.ratio in the renderTime function of TweenMax is not calculating.

Something to do with setRatio is false?

Maybe because time is equal to totalDur

because of this line maybe?....

var totalDur:Number = (this.cacheIsDirty) ? this.totalDuration : this.cachedTotalDuration, prevTime:Number = this.cachedTime, isComplete:Boolean, repeated:Boolean, setRatio:Boolean;

Seems it's forcing children to end in TimelineMax

...
if (prevForward) {
     prevTime = forceChildrenToEnd(this.cachedDuration, suppressEvents);
...

which is the time of 8 seconds in this case? Still digging.

 

PrevForward is set by...

var prevForward:Boolean = Boolean(!this.yoyo || (prevCycles % 2 == 0));

It's not Yoyoing! yoyo=false & prevCycles is 0 so divided by 2 has no remander = true (I think)

Well I'm pretty much lost back tracking again?!

 

At least I'll add that this is a circle path so it's understandable I thought it never started but clearly it's ended.

I've tried my other Circle path method (the one that reveals linear ease actually sins=slows at the beginning and end for some reason?!) so it's not an issue with the CirclePath2D class. [Rant]

 

Next up the line is...

if (repeated && !isComplete && (this.cachedTime != prevTime || force)) {

true true true false

[YellowSock]

Well I've now tried repeats above -1

999999999999 is infinity and it fails the same as -1

99999999999 this works but the initial position from distributing 3 objects on a Cicle Path via totalProgress is off

9999999999 also equally whacked position results.

999999999 now it's at a trillion repeats and the starting position seems right and it's I suppose essentially infinite over an 8 second time.

[YellowSock]

Well since I've attempted to change this

//Instead of Infinity, we use 999999999999 so that we can accommodate reverses.
this.cachedTotalDuration = (_repeat == -1) ? 999999999999 : this.cachedDuration * (_repeat + 1) + (_repeatDelay * _repeat);

999999999999

to a 1 and add in where it tests if it's over something like...

if(time >= totalDur && _repeat == -1) {
   time = 0;
}
if (time >= totalDur) {

Seems the totalPosition was wrong/short and it stopped short to.

Maybe I'll try again to make it just "repeat" once (1) instead of trying to live with myself at a trillion repeats tomorrow.

[GreenSock]

If you set a timeline to repeat for infinity (=-1)

and then set a relative start point via totalProgress (for distributed placement) an error occurs.

I'm baffled as to why you'd expect a relative placement on an infinitely repeating TimelineMax could work. Why would you use totalProgress? It's like saying "place this item exactly 1/3rd into infinity". Again, I'm having a very hard time understanding exactly what you're trying to accomplish big-picture-wise, but wouldn't you use currentProgress, not totalProgress? Do you understand the difference?

 

Instead of posting a bunch of code hacks you've attempted in the class files and accusations about errors/bugs, it would be super helpful if you concisely explain the problem, post sample code that demonstrates how to reproduce the issue, and give us a chance to either confirm the problem or explain the flaw in your code.

 

As for the CirclePath2D, were you saying that you think it should accommodate various ways of rendering the objects with their registration points OFF the path? The concept behind the MotionPath stuff was to be able to attach followers precisely to a path so that their registration point remains on it. You could, of course, create a custom Follower class to which you feed information about how to adjust the target's position based on its width/height or whatever, but I don't think that sort of thing belongs in the core MotionPath set of classes. They should remain focused on properly rendering x/y coordinates on the path that they define. See what I mean?

[YellowSock]

Right sorry. Well again this relates to my only other previous post about getting to the distributed start point first, which was mainly a confusion of usage surrounding setter getter overrides of the property totalProgress as opposed to maybe what a more intuitive function version [totalProgress()] would have lead me to believe initially.

I suppose I also assumed timelines don't do anything until I actually play() them.

 

Let me quickly explain again since it's pretty simple.

I'm using my own code to distribute objects via totalProgress on a path (which happens to be a circle but the same code should work the same for all complex timelines [defined via dynamically loaded XML in my usage]).

 

so each one starts at a different point along said path/timeline but repeats infinitely or until I say otherwise, (without using starting degrees etc. since it works with the same code for all paths.)

 

I do think repeating (-1) should set to 1 not 999999... but restart when ending for this reason.

 

Thanks for all the great help, toleration, and understanding it's pretty frustrating, but I think I'm through with most of the issues soon... just speed and reverse or going to be on my mind next. I can live with the trillion repeats patch.

 

Again I'll suggest a function for inquiring where an item would be at said time without affecting it would be a useful call.

[GreenSock]

Right sorry. Well again this relates to my only other previous post about getting to the distributed start point first, which was mainly a confusion of usage surrounding setter getter overrides of the property totalProgress as opposed to maybe what a more intuitive function version [totalProgress()] would have lead me to believe initially.

 

There's a very important reason it's a getter/setter instead of a method like totalProgress() - it allows you to tween the property. So, for example, TweenLite.to(myTimeline, 1, {totalProgress:1}). The only time this sort of tween wouldn't make sense is on a TimelineMax that infinitely repeats because it will never get to a totalProgress of 1. But in all other cases, it can be extremely useful to be able to tween a timelines currentTIme or totalTime or currentProgress or totalProgress. It even allows you to apply easing to it and create some nifty effects.

 

I'm using my own code to distribute objects via totalProgress on a path (which happens to be a circle but the same code should work the same for all complex timelines [defined via dynamically loaded XML in my usage]).

 

I'm still a bit fuzzy on what you mean by "distributing objects via totalProgress" and why you'd use totalProgress instead of currentProgress.

 

I do think repeating (-1) should set to 1 not 999999... but restart when ending for this reason.

 

It should set what to 1 not 999999...?

 

Again I'll suggest a function for inquiring where an item would be at said time without affecting it would be a useful call.

 

How specifically do you envision the API for this? Keep in mind that tweens can affect virtually ANY property of any object. And how would it be any different internally than simply rendering at that time and then going back. For example, if you want to figure out where all a tween's values would be at exactly 1.25 seconds, you could do:

 

var prevTime:Number = myTween.currentTime;
myTween.currentTime = 1.25;
//capture whatever you want here...
myTween.currentTime = prevTime;

 

The MotionPath stuff already has a method for doing exactly what you're asking - renderObjectAt() to which you could pass a generic Point instance if you don't want it to affect your real object for whatever reason. But I realize you built your own path tool and probably aren't using my MotionPath stuff.

 

Anyway, glad to hear you made a bunch of progress. Good luck.

[YellowSock]

Okay I've realized thanks to your help that it was that I needed currentProgress over totalProgress to resolve these issues.

I think one can splice this code change at bottom into TimelineMax.as's renderTime() function to achieve true infinite looping but I'm not certain it's needed since using currentProgress causes less problems despite this....999999999999 limit

//Instead of Infinity, we use 999999999999 so that we can accommodate reverses.
this.cachedTotalDuration = (_repeat == -1) ? 999999999999 : this.cachedDuration * (_repeat + 1) + (_repeatDelay * _repeat);

But I'm not sure what it might do to reverse as the comment warns.

var totalDur:Number = (this.cacheIsDirty) ? this.totalDuration : this.cachedTotalDuration, prevTime:Number = this.cachedTime, prevStart:Number = this.cachedStartTime, prevTimeScale:Number = this.cachedTimeScale, tween:TweenCore, isComplete:Boolean, rendered:Boolean, repeated:Boolean, next:TweenCore, dur:Number, prevPaused:Boolean = this.cachedPaused;
//START INSERT
if(time >= totalDur && repeat == -1) {
currentProgress = 0;
}
//END INSERT
if (time >= totalDur) {

 

The idea of using a dummy for inquires is excellent (thank you Good thinking) but I'm currently storing and restoring the values before and after my inquiry, which I imagine is easiest (cycles wise). Since I'm still duplicating paths and haven't looked into subclassing "follow" objects to offset for centers.