Topics

1

NGUI 3 Support / UIAnchor on other widgets - limitations due to using local position only

« on: September 17, 2012, 05:30:06 AM »

I love that UIAnchor lets you anchor on other widgets now. But, one limitation that is holding me back from using it is that the child UIAnchor has to be a sibling of the widget you are anchoring to, since UIAnchor on a widget only looks at the local position of the widget. A lot of my UI windows are not setup with this type of hierarchy so it breaks.

Any plan to also take into account the global position so you could anchor on widgets anywhere in the transform hierarchy?

FWIW, I made a new class, TUIAnchorOnSprite, that is a copy of UIAnchor (not inherited), and added this functionality. I've been using it for about a month and it seems to work fine for me (it would probably break a lot of people's setups though). I tried switching back over to using the new widget anchoring functionality of UIAnchor but because of this limitation I couldn't.
http://pastebin.com/uyhAjnSC

It still does all the calculations using local position, but then when it sets the position of the widget it first converts the local position to global:

1. Vector3 worldPosition = m_anchorWidget.transform.parent.TransformPoint(v);

And assigns that to the .position property and not .localPosition.

I also added a scale feature so you can tie the scale of the child widget to the scale of the parent. This isn't useful for making "pixel perfect" UIs but it is very useful for making your UIs look the same in a bunch of different resolutions so it works the best with 9-sliced sprites.

2

NGUI 3 Support / tweening entire panels that have anchors inside of them?

« on: July 18, 2012, 12:17:05 PM »

Hello,

I have been fiddling with this for the past few hours and it doesn't seem doable without some nasty hacks so I'm assuming there is a better way to do what I'm trying to do. I also looked through all the tutorial / demo scenes and none of them seem to do this.

I have my normal game UI and then I have additional dialogs that pop up due to some user action. Those dialogs are full screen and have anchors inside of them so I can align the widgets and have the dialog still look right and be fullscreen on ipad / iphone / various resolutions.

But because those dialogs have anchors in them, I can't figure out how to properly tween them on & off the screen. I could just tween the alpha but I would rather translate / rotate / scale them. Is there a better way to do what I'm trying to do?

One hacky way I thought of would be to disable all the anchor scripts on the panel right before I do the tween, then re-enable them afterwards. This seems like it would work, but again, I have a feeling there is a more "NGUI" way to do it.

Another way I thought of would be to individually tween each anchor's relative offset property or the child of the anchor but that would lead to a ton of tweens and it would be much easier if I could just tween the root dialog. This would also mean I would be limited to translation in my tween since the various dialog components would not all rotate or scale together as one unit.

So, any ideas?

3

NGUI 3 Support / [Bug] creating new tweens on the same object will not reset eventReceiver

« on: July 16, 2012, 11:32:34 AM »

I believe this is a bug.
If you create a tween on an object using TweenColor (or any of the other tweening methods), and then later on make a new tween after that first tween has finished, the new tween will have the same eventReceiver and callWhenFinished properties even if you did not set them on the new tween. This is not expected behavior and the easy fix is to just null them both out, but I believe it should be done in the UITweener class and not in our game code.

Example how to reproduce the bug:

1.                 Color c = m_label.color;
2.                 TweenColor tc = TweenColor.Begin(m_label.gameObject, .5f, c);
3.                 tc.eventReceiver = this.gameObject;
4.                 tc.callWhenFinished = "MessageDone";
5.  

then in your MessageDone function just tween the m_label object again.

1.                         Color c = m_label.color;
2.                         TweenColor tc = TweenColor.Begin(m_label.gameObject, .3f, c);
3.  

That will call the MessageDone method even though we didn't set it, since it reuses the existing tween component.
The fix is to always null out the eventReceiver and callWhenFinished properties on your tweens, but I believe that should be done in UITweener.cs line 255:

1.         static public T Begin<T> (GameObject go, float duration) where T : UITweener
2.         {
3.                 T comp = go.GetComponent<T>();
4. #if UNITY_FLASH
5.                 if ((object)comp == null) comp = (T)go.AddComponent<T>();
6. #else
7.                 if (comp == null) comp = go.AddComponent<T>();
8. #endif
9.                 comp.duration = duration;
10.                 comp.mFactor = 0f;
11.                 comp.style = Style.Once;
12.                 comp.enabled = true;
13.                
14. // reset the eventReceiver and callWhenFinished properties
15.                 comp.eventReceiver = null;
16.                 comp.callWhenFinished = null;
17.                
18.                 return comp;
19.         }
20.  

Thoughts? I am using the tweening class incorrectly?