sharktank

Yes but once I realized (and smacked my forehead) that -3 couldn't really be an absolute value you would normally use, I changed in my file here and started testing as per the last posts. It's great that even though -3 shouldn't work, it does. In a 20 frame timeline, i realize now 17 is a logical destination for -3. However, until I did the following, entering a positive 3 still had the absolute backwards easing to 17 in reverse. Almost as if flash had -3 burned in it's brain for that variable. I did find one thing that has helped my main file become stable. I was declaring myTween:TweenLite up in all my variable declarations, but then my backwards tween was a tweenMax where I injected all the args. The forwards was a tweenLite and it always worked fine. The small file I sent to you was all tweenMax's and it has become stable by changing them to tweenLites. Positive 3 now rolls to frame 3 as it should. I assume it didn't throw an error in the discrepancy because tweenMax extends tweenLite so my initial declaration of a tweenLite would support future tweenmax's as long as the files were present in the com. folder. Will have another go at why I was having issues once I get this done. Cheers

I would expect that when the playhead is at 9 and I use 3 in the absolute backwards function the playhead should go to three, not reversing to 17 which is what we see here. We did get the relative to work using negative values in this file, but still no working reverse of any kind in our larger file. I can't explain it. Going to have to build my own for the reverse. Once I'm finished I"ll pare it down and send our large file's guts so you can see what we've been seeing.

Ok here's a half a duh for you. Of course you can't put -3 in the absolute variable. The fact that it goes to 17 is both right and beautiful. (the problem with idiot proofing something is that those idiots are so damn clever!) Was just bashing in stuff hoping that it was going to do the trick. Brain not turned on yet. So ignore that. But the relative (with a minus 3 injected) is still barreling right past 0 to 17 as well. Going to go back with gray cells now working and see if I can spot anything else.

By the way I am letting each tween come to a full stop before bashing another button.

I didn't think of that. I figured the "backwards" indicated that. So i've changed that and I'm still not having the results I would expect. With that same code I sent, I changed the backwards absolute and relative values both to minus 3 (-3) and changed the forward ones to 9. Run the forwards absolute first, as expected it rolls up to 9. By running either the backwards absolute or backwards relative buttons after that, it should tick back to 6 in one case and 3 in the other. We'll on mine it runs down past zero and ends up at 17 (which is -3 from the end coincidentally) for either of the choices. There is nothing else in the code or no other as files in play here - what you have is what I have. (here's the new .as file with changed values). I don't have any other plug ins in play (yours or anyone elses) - pretty straight up CS4 install Sorry about all this.

Whoops, the Greensock folder has to go in /com not com/smalltest. I was just checking it again and I changed the relative string value from 22 to 32 (the fact that it reversed 2 frames with a string of 22 had me wondering). Well it traveled back 7. So I can see no relationship between how many frames it's running and the string given.

Here you go. Everything works in this one except backwards relative. BackwardsRelative just clicks back 2 frames even though I've got told it 22. The difference seems to be that the timeline I want to run up and down, is being exported for AS and all .as files are external. Also I have both forward and backwards plugins loaded together (but then nonRelative works!) Should this matter or is there something that I'm doing wrong? Have I not initialized the plug in where it should be in the code? You will have to add in your GreenSock folder in the com.smalltest folder - didn't want to weigh down the upload. Thanks for looking into this. Cheers greenSockSend.zip

Having snooped I now see why I need the forward plug in too. Great way to save file weight. Don't see anything glaring in the forward class that would be causing this. Of course I haven't done the double negative brain crunch with the notLogicals.

Couple of clues for you: I am using both backwards and forwards in the same as file. (and yes I have tried only one at a time). While the backwards one works in reverse and to the wrong frame (in all cases now), it only does so when you have activated the forward plug in as well. If you only activate the backward plug in, the frameBackwards doesn't even work wrong. CS4/Player10.1/Mac/10.4.11/AS3 and all as files are external and not in the time line. greensock is not imported into the doc class, but in the class of the object it's being used on. That's the latest.

here's the code: inputString="600"; diskEaser=new TweenMax(this.spinningSlave,30,{frameBackward:inputString,ease:easeType,useFrames:true,onUpdate:frameUpdater,onComplete:easeEnd}); the plugin has been initialized (and changing inputString to a :Number proves it, as that works perfectly. Except that it goes to frame 600 instead of travelling 600 frames. But this exact code, running in a 720 frame timeline travels forward 75 frames. Just checked the ascii math and that's not it either. Have checked frameForward and it works properly in either case.

That's going to do it, but there's a little bug. FrameForward works perfect, however frameBackward , well it thinks it's a frameForward - sometimes. It seems that if you give frameBackward a value, it does what its' supposed to and goes to that frame in the time line, skipping over frame 1 on it's way and coming back in from the highest frame in the timeline. But if you give it a string or relative value: i'm not sure what it does but it doesnt do the latter and it doesn't travel in a backwards direction. It goes forward but only by less than 100 frames. I haven't done the ascii math but it might be travelling the value of the characters in the string I'm feeding it and not the converted value held by string. (I do miss the old val command)

There it is!. I figured with downloading the most recent build yesterday I must have the latest. Thanks

Hmmm, don't see that frameBackward or frameForwardas. file in the com/plugins folder. I have also checked inside the frame plug in script but since you have initialize these separately I assumed they would be a separate file. I also didn't see it in the list of plugs ins on the site (including ones marked as club plugins) but I did find it in the docs. So now I know how to work it but I don't know where to get it.

Actually the NAN is before any modulo is run on the values. that's whats got us frowning. Right out of the gate we can trace the value of the rotated object but can't get that value to play with. As for the frameForward plug in that's perfecto. Had been through all the docs looking for something like that but didn't notice it. Will let you know if that solves it. Cheers and thanks again.

That's always the first thought I have - I'm sure you've spent many more hours tweaking the library than I have perfecting this little app. Perhaps there's another way around the problem: What I'm trying to do is this: I have an imported frame-based animation that is 720 frames long - it's a perfect loop. I haven't found a way to use the tweenmax "frame" paramater, and relative values for the tween, to hit the end of that 720 frames and go back to 1 and continue tweening along. So my idea was to use the "relative" feature and the fact that you can tween past the end of 360 degrees on a rotation with a much larger value and the object that this was applied to would just loop back around and keep rotating to the end of the tween. I'd hijack the values of the rotation as it happened and apply those with a gotoAndStop() kind of thing on the timeline based animation. (more on the tweening of actual frames later) Of course, I have to use that 360 modulo trick to interpret the neg values that the actual spinning object returns when you ask for it's rotation values, but that's fairly easy. I must clarify I don't think this is a greensock issue, as the object is tweening just fine. I just can't get flash to hand over the value that quickly (it seems), so I was wondering if there was another way to get that value directly from the tween engine (without having to put a callBack on every "frame" of the tween timeline). Or better, if there was a "loopTo" beginning/end function in the frame parameter. (i've tried with timeline AS goto calls but the tween just ends) (you can stop reading here if there is an obvious solution to the above) The issue with the code posted is that first line of the onUpdate function, where I try and get the values of the tween to play with: myRotation = spinner.rotation;, usually returns a NAN from the following line's trace. But tracing spinner.rotation instead does return the correct value. I just can't do anything with a returned trace. ( I can run the same, non interactive code over and over and get values for myRotation that are sometimes real and NAN's other times) I agree there could easily be something else in the code, but with myRotation = spinner.rotation being the very first line inside the onUpdate function and the trace of myRotation being the second (and myRotation being only used once, here, in the code), one would think that I would actually get the value of the spinner object. At the moment of the tween, it's the only thing "running". Now: "actual frames and tweens". I am aware that the tweenMax won't generate the in-betweens of the physical frames I have, and that down near the end of a cubic.easeOut, the last, say, 10 positions of the tween may Math.round to the same frame, as others might along the way. And that's exactly why there are so many frames in the physical timeline. A large sample to pick from if you will. I did initially have this with 360 frames to keep the rotation math simple, but had to double it to get the resolution required for a smooth tween. The tweening of the frames works great -with the frame paramater - it's the looping back from the end and visa versa that are stopping me in my tracks. Cheers