This content has been marked as final. Show 10 replies
Actually I found a way to code around it by having the target maintain an array of function calls and arguments (a 'queue' ?) while it is in an indeterminate position and to then walk through the queue when it decides that it is ready... but I am interested to know if anyone has had to deal with a similar thing for animation work using this kit and if I'm missing something obvious with how to use it.
I would have to see the code.
Thanks for taking a look... and its perhaps easiest to illustrate with a trivial example.
e.g. using the simpleSetup prototype extensions:
target.tween (props:Object, endVals:Object, seconds:Number, ease:Object, delay:Number, callback:Object):String
If I call the tween method on the target myClip, with a delay of 4 seconds:
Now if I change the target's current position prior to that tween starting e.g
Then when the tween starts... it jumps back to start from the original _y position. That's the behaviour I want to avoid... I was hoping there was some way the engine would just take the target's current values (in this case _x and _y) when the delay period was finished.
is probably declared after the declaration of the tween. Is that necessary in your program?
Or use relative values:
endvalues as string values
Yes it is necessary (unless I make major changes to the way things work) and that was the point of my question - is there any way to have the start properties for the tween reflect whatever the values are at the time the tween starts (when its pre-tween delay is finished, not when it is declared). So if I need to change them after declaring the tween is there some way to do that.
That was just an example. In reality its not easy to predict if the target (myClip in the example) will change its _x or _y properties, because it is receiving text content (during the delay before the tween starts) and depending on the volume of text is expanding vertically (and possibly moving depending on an 'anchor' setting e.g. "BL" - bottom left makes it keep its bottom left corner fixed, which may mean it moves up by decreasing its _y property if the internal texfield autosizes vertically). Its too complicated (and too much code) to post that... in any case it just simplifies down to the first paragraph and the trivial example above.
As I said earlier I have managed to code around this... I was just wondering if there was some obvious (but not for me) way to avoid having to. Perhaps there isn't one. I wasn't keen to go hacking into the ZigoEngine code (after taking a look at it).
Then the relative values might work out for you?
Sorry I just saw your next post. I'm not sure if that would work (I haven't tested it) as it seems the problem is picking up the changed start values. Unless there is something fundamentally different about when the relative values are converted internally to absolute target values I don't think that would work.
In any case, I can't use that approach without making further changes. All my target values come from xml and go through an math expression parser which converts valid string math expressions (including evaluation of legitimate Math methods/functions themselves) to numeric values. Yes its all very complicated. lol.
The relative values tween the object from its current position so when I understand the problem correctly it should solve the problem. Must add here - Fuse itself gives far more control than the simpleSetup.
Yes I know the relative values work off the current position. But I just tested it. The same problem exists. It is relative to the position at the time the tween is declared, not when the tween starts after the delay.
I understand and wholeheartedly agree with your point about Fuse, but for lots of animation from a performance perspective its not recommended as the sequencing approach (Mosessupposes.com) so I was seeking to avoid it.
Thanks heaps for your comments. If I find a way to do this I'll post it here and at Mosessupposes forum.