johnatm / itween

Automatically exported from code.google.com/p/itween
1 stars 2 forks source link

ConflictCheck() destroys valid instances #81

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
0. (do this all in the same function, i.e. in the same frame)
1. add a tween to an object
2. call iTween.Stop(gameObject);
3. add the same tween again to the object

What is the expected output? What do you see instead?
The second iTween should "survive" and continue/finish regularly.
Instead, after Stop() disposes the first iTween, the new iTween is immediately 
discarded in ConflictCheck(), since it is identical to the old, dead one (which 
is still attached to the object).

What version of the product are you using? On what operating system?
2.0.44, Windows7

Please provide any additional information below.
Proposed fix: In ConflictCheck(), you need to ignore comparisons against dead 
iTweens, i.e. iTweens no longer in the global "tweens" array.
Line 7075: change from:
            }else if(item.isRunning && item.type==type){
to:
            }else if(item.isRunning && item.type==type && tweens.Contains(item)){ // ignore tweens that are no longer alive!

Original issue reported on code.google.com by wkre...@googlemail.com on 28 Jul 2011 at 4:47

GoogleCodeExporter commented 8 years ago
Ah, for the proposed fix I forgot you need to rename the local "tweens" 
variable, too, since it overwrites the visibility of the global "tweens" 
array...
And with "same" I mean "an iTween with the same settings", not the same 
instance, of course.

Original comment by wkre...@googlemail.com on 28 Jul 2011 at 4:51

GoogleCodeExporter commented 8 years ago
...and in case you were wondering: This isn't as useless a testcase as it looks 
like. For low frame rates, this situation could for example happen for a toggle 
button that is toggled on-off within the same frame. And in our situation, we 
rely on function calls after the tween has finished, using "oncomplete" - 
however, these calls never happen, if both the stopped and the newly created 
tween are disposed.

Original comment by wkre...@googlemail.com on 28 Jul 2011 at 5:04

GoogleCodeExporter commented 8 years ago
I have a restart method that does iTween.Stop() to cancel out old tweens and 
then does iTween.MoveFrom. Calling this method before the tween finished 
resulted in the bug mentioned above. The patch you suggested did prevent the 
new tween from being killed, but I noticed that the old tween still existed as 
a component on the GameObject and continued to play (with no effect). 

My patch to this was in ConflictCheck() Step 3 to replace Dispose() with 
item.Dispose. Hopefully this isn't too bad of a hack, but it also got the job 
done.

Original comment by FrankThe...@gmail.com on 7 Apr 2012 at 12:27

GoogleCodeExporter commented 8 years ago
I also run into this problem.  I have code that resets objects to their default 
state (stopping all tweens), and then may or may not apply new tweens to the 
object.  Doing this in the same tick removes the new tween during 
ConflictCheck() as mentioned.

The proposed fix doesn't work, b/c iTween.tweens contains Hashtables, not 
Tweens.  The fix I'm using is:
- add "isRunning=false" everywhere before Destroy(this) is called (mainly 
inside Dispose())
- in LateUpdate(), check isRunning before the tweenArguments check.  
Intermittently the latter was null; not sure if this was related or a different 
issue.

Original comment by entropic...@gmail.com on 24 Feb 2015 at 5:12

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
They moved to using Hashtables in 2.0.46. The modified fix is:
}else if(item.isRunning && item.type==type && 
tweens.Contains(item.tweenArguments)){ // ignore tweens that are no longer 
alive!
(not really sure, though, somebody who really knows the iTween code should 
verify this)

Original comment by wkre...@googlemail.com on 24 Feb 2015 at 5:22