271
DOTween & DOTween Pro / Re: Upgrading from 2012
« on: May 28, 2015, 01:43:32 PM »
Great! I'll be here and ready to answer 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
272
DOTween & DOTween Pro / Re: Upgrading from 2012
« on: May 27, 2015, 01:34:29 PM »
Yup, the logic is very similar, but the API is different (and much easier to use, if I may say so), so it's not just a search and replace. It should be easy if you were accustomed to HOTween, but if not it will take some work.
By the way, about your HOTween issue, consider that HOTween had an overwrite manager, so if a tween was started while another identical one (meaning same target and property) was running, the older one was canceled. DOTween, due to its lighter nature and architecture, doesn't have an overwrite manager, but you still can't run two tweens on the same property of the same target at the same time (unless you use Blendable tweens).
By the way, about your HOTween issue, consider that HOTween had an overwrite manager, so if a tween was started while another identical one (meaning same target and property) was running, the older one was canceled. DOTween, due to its lighter nature and architecture, doesn't have an overwrite manager, but you still can't run two tweens on the same property of the same target at the same time (unless you use Blendable tweens).
273
DOTween & DOTween Pro / Re: Upgrading from 2012
« on: May 27, 2015, 02:51:16 AM »
Hi,
I was just going to mention that blog post, but I see you found it already. TweenEvent can be easily be replaced with an anonymous function. For example, if you want to pass the tween to an OnUpdate callback, you can do:
By the way, what issue did you find in HOTween? I definitely recommend DOTween over that, since it's much more efficient and flexible, but you could also try to update to a more recent version of HOTween, in case that bug, whatever it was, was solved?
Cheers,
Daniele
I was just going to mention that blog post, but I see you found it already. TweenEvent can be easily be replaced with an anonymous function. For example, if you want to pass the tween to an OnUpdate callback, you can do:
Code: [Select]
myTween.OnUpdate(()=>MyFunction(myTween));By the way, what issue did you find in HOTween? I definitely recommend DOTween over that, since it's much more efficient and flexible, but you could also try to update to a more recent version of HOTween, in case that bug, whatever it was, was solved?
Cheers,
Daniele
274
DOTween & DOTween Pro / Re: DOTween Pro Path Local Movement unexpected results
« on: May 25, 2015, 01:46:45 PM »
Hi!
I am working on it just now, after scrapping a previous version that didn't work as I wanted. I have to say that now I'm not 100% sure I'll be able to implement this though, because the more I work on it, the more I realize that UGUI is really not made to work with paths (especially because the visual path needs to be drawn using 3D coordinates, while UGUI's anchoredPosition uses a "similar but different" set of coordinates).
I am working on it just now, after scrapping a previous version that didn't work as I wanted. I have to say that now I'm not 100% sure I'll be able to implement this though, because the more I work on it, the more I realize that UGUI is really not made to work with paths (especially because the visual path needs to be drawn using 3D coordinates, while UGUI's anchoredPosition uses a "similar but different" set of coordinates).
275
DOTween & DOTween Pro / Re: a gc issue about Tweener.ChangeEndValue.
« on: May 25, 2015, 01:19:14 PM »
Hello,
Those 20B of allocation happen because when using ChangeStart/End/Values the change value is boxed as an object rather than as its true value type. That is sadly a necessity, because generic types can't be converted with AOT (iOS). The only other solution would be for me to add a ChangeStart/End/Values overload for each value type, but that would make every Tweener instance much heavier, so I believe that 20B per call are much better.
Those 20B of allocation happen because when using ChangeStart/End/Values the change value is boxed as an object rather than as its true value type. That is sadly a necessity, because generic types can't be converted with AOT (iOS). The only other solution would be for me to add a ChangeStart/End/Values overload for each value type, but that would make every Tweener instance much heavier, so I believe that 20B per call are much better.
276
DOTween & DOTween Pro / Re: Inconsistent canvas anchor positions when running on android device
« on: May 23, 2015, 01:35:34 AM »
What are you using to play it again? I suppose you're using DOPlay, but that won't work because the tween has already played, so you'll need to use DORestart instead.
Also, I have a suggestion, considering that you practically have the same tween, just going in different directions. Instead of having two tweens, you could have only one. Then, when you want to play it "forward", you call DOPlayForward, and when you want to play it backwards you call DOPlayBackwards
Also, I have a suggestion, considering that you practically have the same tween, just going in different directions. Instead of having two tweens, you could have only one. Then, when you want to play it "forward", you call DOPlayForward, and when you want to play it backwards you call DOPlayBackwards
277
DOTween & DOTween Pro / Re: Inconsistent canvas anchor positions when running on android device
« on: May 22, 2015, 10:12:23 PM »
Hi!
Are you using a path to move your panel? If so, I apologize, because you're the second user doing that, and I'm currently working on it. I didn't think someone could use paths with UGUI, since it's actually not recommended (simply because Unity's UGUI is a very heavy thing, so paths should be used with sprites or regular non-UGUI objects). So paths use transform.position and not rectTransform.anchorPosition, which is a completely different thing.
While I work on allowing paths with UGUI (which might take a while because UGUI anchorPositions break the paths logic), you could simply use a DOTweenAnimation + DOMove instead. That will correctly use anchorPositions. Just be careful to grab the latest version of DOTween Pro.
Are you using a path to move your panel? If so, I apologize, because you're the second user doing that, and I'm currently working on it. I didn't think someone could use paths with UGUI, since it's actually not recommended (simply because Unity's UGUI is a very heavy thing, so paths should be used with sprites or regular non-UGUI objects). So paths use transform.position and not rectTransform.anchorPosition, which is a completely different thing.
While I work on allowing paths with UGUI (which might take a while because UGUI anchorPositions break the paths logic), you could simply use a DOTweenAnimation + DOMove instead. That will correctly use anchorPositions. Just be careful to grab the latest version of DOTween Pro.
278
DOTween & DOTween Pro / Re: DOJump Issues - Jumping to a Higher Platform
« on: May 20, 2015, 11:55:56 AM »
Great
279
DOTween & DOTween Pro / Re: DOJump Issues - Jumping to a Higher Platform
« on: May 20, 2015, 11:04:08 AM »
Here you go, see the new version attached. Now use
which will internally use rigidbody's MovePosition rather than changing the transform's position directly, which is how it should be done
About the attachment, probably you didn't run DOTween's Setup again (it needs to be run each time you update, from Tools > DOTween Utility Panel), which is necessary to activate all additional shortcuts (like the ones for texts).
Code: [Select]
myRigidbody.DOJumpinstead ofCode: [Select]
myTransform.DOJumpwhich will internally use rigidbody's MovePosition rather than changing the transform's position directly, which is how it should be done
About the attachment, probably you didn't run DOTween's Setup again (it needs to be run each time you update, from Tools > DOTween Utility Panel), which is necessary to activate all additional shortcuts (like the ones for texts).
280
DOTween & DOTween Pro / Re: DOJump Issues - Jumping to a Higher Platform
« on: May 20, 2015, 10:28:55 AM »
I just checked it out and it works perfectly here even with a very long jump duration. I have a feeling it might be because you're probably tweening a rigidbody, am I right? I'm gonna implement correct rigidbody DOJump shortcuts now, which will work much better than using a transform.
281
DOTween & DOTween Pro / Re: DOTween Pro Path Local Movement unexpected results
« on: May 20, 2015, 10:23:54 AM »
Ok, added to my todo list. Hope to have it done as soon as possible, but might take a while since it's kind of complicated (I will actually start working on it right now).
282
DOTween & DOTween Pro / Re: DOJump Issues - Jumping to a Higher Platform
« on: May 19, 2015, 08:40:04 PM »
Hey, get the attached version. Now the transform's DOJump shortcut (only that one, I will implement the others in the next days) actually takes the endValue fully, Y included, and adds a "jumpPower" parameter instead.
283
DOTween & DOTween Pro / Re: DOJump Issues - Jumping to a Higher Platform
« on: May 19, 2015, 07:55:22 PM »
Hi,
Indeed DOJump doesn't allow to change the final Y value, other than for the jump itself. I'm going to see if I can change this right now. Will be back in a short while.
Indeed DOJump doesn't allow to change the final Y value, other than for the jump itself. I'm going to see if I can change this right now. Will be back in a short while.
284
DOTween & DOTween Pro / Re: DOTween Pro Path Local Movement unexpected results
« on: May 19, 2015, 07:54:28 PM »
Hi,
I checked your package and now I see the issue. I didn't realize you were using a path with a UGUI object. Local paths don't work there because UGUI objects actually use anchorPositions instead of positions. Also, it's definitely not recommended to use paths with UGUI, since paths require to move a transform (contrary to simple Move tweens that use anchorPositions), and that is a very heavy operation for Unity (because each time you move a UGUI transform, Unity needs to reorganize tons of UGUI variables and data).
Do you think you could use a non-UGUI Sprite instead? Otherwise, I'll see if I can implement a path system that uses anchorPositions, but it might take a while.
I checked your package and now I see the issue. I didn't realize you were using a path with a UGUI object. Local paths don't work there because UGUI objects actually use anchorPositions instead of positions. Also, it's definitely not recommended to use paths with UGUI, since paths require to move a transform (contrary to simple Move tweens that use anchorPositions), and that is a very heavy operation for Unity (because each time you move a UGUI transform, Unity needs to reorganize tons of UGUI variables and data).
Do you think you could use a non-UGUI Sprite instead? Otherwise, I'll see if I can implement a path system that uses anchorPositions, but it might take a while.
285
DOTween & DOTween Pro / Re: Problem on iOS builds since 0.9.255
« on: May 18, 2015, 06:36:33 PM »
Great!