Jump to content
Search Community

reverse() and onUpdate

Redhawk test
Moderator Tag

Recommended Posts

When I reverse a tween, one of the variables is onUpdate and it's no longer calling my function associated with it. I'm assuming this is done by default. I want to keep onUpdate active while the tween is in reverse() mode. Is there an easy way of doing this?

Link to comment
Share on other sites

Yes, onUpdate gets called every time the tween renders regardless of which direction (forward or reverse). If you're not seeing the correct behavior, please post a very simple FLA that demonstrates the problem so that we can publish on our end and see what's going on. And you are using the latest version of the GreenSock files, right?

Link to comment
Share on other sites

Yes, onUpdate gets called every time the tween renders regardless of which direction (forward or reverse). If you're not seeing the correct behavior, please post a very simple FLA that demonstrates the problem so that we can publish on our end and see what's going on. And you are using the latest version of the GreenSock files, right?

 

My bad, sorry, it's working as it should.

 

I'm using LinePath2D to build a mobile line-drawing game. Once I draw the line, my unit will follow along that line, and if I click on the unit, I have it reversing along the same line. That being said, when the tween reverses completely, it sometimes resets the unit to the end of the line instead of the front of the line. I've hacked a solution anyway. All is good. I'm not using the latest version as I constantly update myTween.timeScale frequently and sometimes need it to be 0 (which I saw on the new version as not possible). I tried using the latest version but the timeScale variable is done differently and too many changes required. The version I have is stable for what I need it to do. Thanks!

Link to comment
Share on other sites

Glad you figured out a good solution. I'd be curious, though, to see a simple example of where reversing ends up leading to the object rendering at the end instead of the beginning. Please post a basic FLA if you don't mind so that we can check it out and publish on our end.

 

Oh, and I'm also curious about what you meant by "I constantly update myTween.timeScale frequently and sometimes need it to be 0 (which I saw on the new version as not possible)" - what do you mean it's not possible in the new version? What gave you that impression? The only chance in v12 is a syntax one:

 

//old
myTween.timeScale = 0.5;

//new
myTween.timeScale(0.5);

Link to comment
Share on other sites

Glad you figured out a good solution. I'd be curious, though, to see a simple example of where reversing ends up leading to the object rendering at the end instead of the beginning. Please post a basic FLA if you don't mind so that we can check it out and publish on our end.

 

Oh, and I'm also curious about what you meant by "I constantly update myTween.timeScale frequently and sometimes need it to be 0 (which I saw on the new version as not possible)" - what do you mean it's not possible in the new version? What gave you that impression? The only chance in v12 is a syntax one:

 

//old
myTween.timeScale = 0.5;

//new
myTween.timeScale(0.5);

 

Unfortunately, it's very hard to replicate the example simply in an fla as I'm manipulating the timeScale of multiple units simultaneously, while also updating the globalTimeScale. From your documentation, I see this:

 

globalTimeScale property

globalTimeScale:Number [read-write]

Multiplier describing the speed of the root timelines where 1 is normal speed, 0.5 is half-speed, 2 is double speed, etc. The lowest globalTimeScale possible is 0.0001.

 

Players have the option to speed up or slow down the entire game, hence the need to update the globalTimeScale. But sometimes I need the globalTimeScale to stop altogether, without any calculations happening onUpdate. I was afraid that 0.0001 would still do calculations, so I haven't upgraded to the latest version. I'm currently using version 11.698.

 

The mobile game is called FireJumpers, it's available for Android and iOS. I would not have been able to build this game without your Greensock classes. It's a line-path drawing, wildfire fighting simulation game where you control a team of elite wildfire fighting units from helicopters to ground units to waterbombers as you try to contain epic wildfires on real maps from locations around the world. It's a top-down view of a map and the mechanics are similar to Flight Control.

 

These maps can contain up to 55,000+ terrain blits that burns differently based on its type (grass, bushes, trees, buildings, etc) and also effects the speed of the unit's linePath tween while moving over them. For example, a "Cut Team" moving along the assigned linePath can move over grass at say, timeScale = 1, while moving through dense trees at say, timeScale: 0.25. This way the unit's linePath tween can speed up or slow down based on the terrain it's on. That's done using the onUpdate variable in the tween. As a very quick example, it would look like this:

 

var unitTween:TweenMax;
var speed:Number = 0.2; // Different for each type of unit, smaller the number, faster the unit.

public function onmouseupUnit(e:MouseEvent = null):void
{
   // calculate linePath code
   calculateLinePath();

   // Now tween unit along the linePath
   unitTween = TweenMax.to(unit.linePath, speed * unit.linePath.totalLength, {progress:1, onUpdate: updateUnit, onComplete: arrivedAtDestination});
}

public function updateUnit():void
{
   var terrain:Object = getTerrainAtLocation(unit.x, unit.y);

   if (terrain.type == "Grass") unitTween.timeScale = 1;
   else if (terrain.type == "Bush") unitTween.timeScale = 0.6;
   else if (terrain.type == "Tree") unitTween.timeScale = 0.25;
}

public function arrivedAtDestination():void
{
   if (unit.state == "SprayWater")
   {
       sprayWater();
   }
}

 

Now there's a lot more obviously to this, but that's the base of what's happening.

 

Here's my current issue which I can't seem to solve. I have a special unit called the "Hoser Team" that essential sprays water on nearby fires in a radius area around the unit. Sometimes it's necessary to reverse the unit's tween direction if it's getting too close to the fire. Sometimes I need to reverse all the way back, other times, I only need to reverse for 0.5 secs. So I have something like this:

 


public function onclickUnit(e:MouseEvent = null):void
{
   unitTween.reverse();
   unit.isBackingUp = true;

   if (_isContinuousBackingUp)
   {
       unitTweenReverse = TweenMax.to(unit, speed * unit.unitTween.totalLength * unit.unitTween.progress, {onUpdate:updateUnit, onComplete: doneBackingUp});
   }
   else
   {
       unitTweenReverse = TweenMax.to(unit, 0.5, {onUpdate:updateUnit, onComplete: doneBackingUp});
   }
}

public function doneBackingUp():void
{
   unit.isBackingUp = false;
   unitTween.timeScale = 0; // This way the unit can backup a little bit on the linePath and stop.

   // Now here, my trace shows that sometimes the unit ends up being at the start of the linePath, but occasionally it goes to the end of the linePath.


   // Do more code stuff
   arrivedAtDestination();
}

 

I'm also using TweenLite as a delayed function call to handle the spread of the fire, so I've had up to 1400+ simultaneous fire tweens running fairly smoothly on a phone.

 

Anyway, that's the long story.

 

You can check out the game on your phone or online at http://www.kongregat...wk/fire-jumpers

 

On the version online, it doesn't have the backup functionality yet.. I'm still working on that of course. But shows the game at a fairly stable state.

Link to comment
Share on other sites

Cool game - thanks for sharing the link.

 

Just to clarify, the timeScale has never been able to go to exactly 0 even in v11 because:

  1. It would cause errors in the math internally because dividing by zero gives an infinite result, and adding conditional logic to look for 0 in every case would impose a performance penalty that I wasn't comfortable with. As I'm sure you know, performance is a BIG priority in the platform.
  2. It's redundant functionality since pause() should be used to stop things completely, rather than timeScale(0).

We improved the docs in v12, so that's probably why you noticed the 0.000001 limitation there.

 

Have you considered pausing instead of using a timeScale of 0 to stop?

Link to comment
Share on other sites

Cool game - thanks for sharing the link.

 

Just to clarify, the timeScale has never been able to go to exactly 0 even in v11 because:

  1. It would cause errors in the math internally because dividing by zero gives an infinite result, and adding conditional logic to look for 0 in every case would impose a performance penalty that I wasn't comfortable with. As I'm sure you know, performance is a BIG priority in the platform.
     
  2. It's redundant functionality since pause() should be used to stop things completely, rather than timeScale(0).

We improved the docs in v12, so that's probably why you noticed the 0.000001 limitation there.

 

Have you considered pausing instead of using a timeScale of 0 to stop?

 

 

Yeah, that makes sense about the divide by 0 and why it can't be truly 0. As for using pause() option, I'd use it, however I use pauseAll() and resumeAll() all the time, for moving the map to moving units. The reason is that when there's 1400+ simultaneous fires + multiple unit linePaths + smoke particles + etc, I need to constantly pauseAll() so the phone can process the linePath drawn without also calculating everything else. It was the only way I could handle line-drawing the paths smoothly with so many other simultaneous calculations.

 

I guess my issue is that having my Hoser unit backing up isn't that tough, it's that at any point, the user may start a new linePath from anytime along the current linePath, so I need to keep tracking all the points up to the current unit's position, and add new points and create a new linePath as a combination of old points plus new points.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...