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.

Messages - tayl0r

Pages: [1]
NGUI 3 Support / Re: Crash occurs in kitkat (under opengl 2.0)
« on: June 27, 2014, 10:35:37 AM »
The Unity 4.5 release notes say this:

* Fixed crash on Android 4.4.2 when running on certain Adreno GPUs.

And I'm assuming that is referring to this issue. Can anyone confirm? It seems fixed to me but a guy on the tk2d forums is saying its not.

NGUI 3 Documentation / Re: UIRect
« on: April 30, 2014, 04:10:25 PM »
I have a widget with it's anchor set to "Execute: OnEnable". I move the widget by setting its localPosition. The next frame it snaps back to the anchor position.

I thought if the execute type is set to OnEnable it wouldn't be doing this.

I thought that maybe I could just turn the anchor off, but looking in UIRect.cs it's not clear how to do that. It looks like you need to set each anchor target to null but it doesn't seem like UIRect wants us to do that.

How should I be doing this? I don't want to put the widget in a panel and move the panel, I just want to position the widget via the anchor in the editor, have the game start and have its position set via the anchor, then move it around later via code.

I also want to clone that widget (Instantiate(widget)) and move the instantiated widget around as well, so in that case I think I probably do need to disable the anchoring since I don't want it to run even once.

Edit: it looks like SetAnchor(null); does the trick!

Awesome, thanks.

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.

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.


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?

While you're at it, it would be nice to make an overloaded method for Begin that also accepts eventReceiver and callWhenFinished parameters =)

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";

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);

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.        = Style.Once;
  12.                 comp.enabled = true;
  14. // reset the eventReceiver and callWhenFinished properties
  15.                 comp.eventReceiver = null;
  16.                 comp.callWhenFinished = null;
  18.                 return comp;
  19.         }

Thoughts? I am using the tweening class incorrectly?

Pages: [1]