Messages

31

NGUI 3 Support / Re: 3.0.9 f4 Creating a UIWidget with no UIRoot screws up layers and scale

« on: January 24, 2014, 09:31:36 AM »

This actually happens in the Editor as well as at runtime. Specifically, I have a static UIWidget on a GameObject that starts out disabled (it's not added at runtime, so I can't really use NGUITools.AddChild). As soon as the object is enabled, it creates a new UIRoot. It's not under a UIPanel because it's just a collider for catching events. It only has a UIWidget on it to prevent that weird depth issue. It doesn't draw anything, so it has no real need to be under a UIPanel.

32

NGUI 3 Support / 3.0.9 f4 Creating a UIWidget with no UIRoot screws up layers and scale

« on: January 23, 2014, 02:05:20 PM »

When creating or enabling a UIWidget in a hierarchy that doesn't contain a UIRoot, it creates one and re-parents the hierarchy under it. This causes problems. We don't use a UIRoot because we do some more complicated scaling the results in pixel perfect UIs on a couple target devices, and then scales to fit based on both width and height on other devices. We also have a couple of stand alone colliders that intercept and process events. I've added UIWidgets to these colliders so it gets sorted correctly for events. The problem is, when the UIWidgets on these colliders are enabled (i.e. when the GameObject is enabled), they basically destroy hierarchy. There are two outcomes. 1) The widget doesn't find a UIRoot on the root object, so it creates a new UI and re-parents the current hierarchy under it. Problem is, the re-parenting resets all layers in the game to Default. We use a couple layers for masking events and this breaks all interaction. 2) The widget finds a disabled UIRoot on the root object and resets it's scale to 1,1,1 for whatever reason. Our custom scaling script was originally on the root object (effectively replacing UIRoot with a custom one) so this object has a specific scale set. Resetting the scale blows up the game.

I ended up setting up the hierarchy with a disabled dummy UIRoot as the root object, the GameScaler under that, then the UICamera under that. Like so:

• Root (disabled UIRoot)
• • GameScaler (GameScaler)
  • • Camera (UICamera)
      

And this doesn't break things.

33

NGUI 3 Support / Re: 3.0.9 f4 UIWidget Not Updating BoxColliders

« on: January 23, 2014, 11:49:32 AM »

Yep, it works that way. I was using Ctrl+Shift+A to add a BoxCollider. It doesn't work if you add the collider without using Alt+Shift+C.

34

NGUI 3 Support / Re: EventDelegate.Remove Failing

« on: January 23, 2014, 09:02:00 AM »

That seems like a really inconvenient pattern. Any chance you could be coerced into working around that limitation? Presumably you could just remove from the original list, not the copy.

35

NGUI 3 Support / Re: 3.0.9 f4 Problem With Colliders On Scroll Views

« on: January 22, 2014, 05:27:36 PM »

Another problem helped me figure out what's probably going on here. When the UICamera Event Type is set to UI, colliders are sorted by depth to determine which one receives the event. Colliders get their depth from either widgets on the object or in it's children. I'm guessing the collider ends up at the same depth as the colliders on the elements in the list and so you get the fighting. Adding a UIWidget to the parent along with the collider and settings it's depth appropriately will probably fix the issue.

36

NGUI 3 Support / 3.0.9 f4 UIWidget Not Updating BoxColliders

« on: January 22, 2014, 05:18:49 PM »

Title basically says it all. Add a UIWidget and a BoxCollider to a GameObject, check Auto Adjust To Match, and the BoxCollider never changes. I'm not sure if it's supposed to update the BoxCollider as the widget changes or when the game starts, but I can't seem to get it to update at all.

37

NGUI 3 Support / EventDelegate.Remove Failing

« on: January 22, 2014, 04:31:25 PM »

I've run into multiple circumstances now where EventDelegate.Remove fails. It returns false and the previously Added callback will continue to get called. I haven't had time to dig down and figure out the problem, but I've noticed the actual reference to the onFinished list has changed and is empty. Explicitly specifying that it's not a one-shot callback doesn't help.

A small code example:

1. TweenPosition registrationTwn;
2. List<EventDelegate> registrationRef;
3.  
4. public void CancelButtonPressed ()
5. {
6.         isCanceled = true;
7.  
8.         registrationTwn = tween;
9.         registrationRef = tween.onFinished;
10.         EventDelegate.Add(tween.onFinished, TweenOutFinished);
11.         //EventDelegate.Add(tween.onFinished, TweenOutFinished, false); //Same results
12.         tween.Play(false);
13. }
14.  
15. private void TweenOutFinished ()
16. {
17.         Debug.Log("tween Equal Original: " + ReferenceEquals(registrationTwn, tween)); //True
18.         Debug.Log("onFinished Equal Original: " + ReferenceEquals(registrationRef, tween.onFinished)); //False
19.  
20.         Debug.Log(
21.         EventDelegate.Remove(tween.onFinished, TweenOutFinished) //Fails
22.         );
23.  
24.         UIManager.ToggleUIElement(UIElement.InputBlocker, false);
25.  
26.         friendList.enabled = false;
27.         root.SetActive(false);
28.  
29.         if ( FriendsSelectedCallback != null )
30.                 FriendsSelectedCallback(( isCanceled ? null : selected ));
31. }
32.  

In this case, it would be sufficient to make it one-shot, but I'm running into the same problem in cases where that's not an option.

38

NGUI 3 Support / 3.0.9 f4 Problem With Colliders On Scroll Views

« on: January 22, 2014, 01:51:52 PM »

When creating scrolling lists, it's common to have 2 different types of colliders: ones on the list elements, if they are buttons, and a "catch-all" collider that allows the player to scroll from anywhere in the list, not just over the elements. With the recent changes, if the catch-all collider is on the parent object of the Scroll View it will overlap and block some of the element colliders. Some elements will be clickable and others will not.

This only occurs with the Camera Event Type set to UI. It appears to work perfectly with it set to World (presumably it respects z-value), but in this case list element colliders aren't clipped when scrolling so it's more work to go that route. For now, it's not difficult to work around this, but it's cleaner not to need a dedicated GameObject just for the collider when it can be put on the existing parent object.

This doesn't work (random elements won't be clickable):

• Friends List (w/Collider)
• • Scroll View
  • • Grid
    • • Element
      • Element
      • Element
      • Element

But this does:

• Friends List
• • Collider
  • Scroll View
  • • Grid
    • • Element
      • Element
      • Element
      • Element

I'm emailing a test project for this in case it's not very clear.

39

NGUI 3 Support / New UIInput doesn't get along with Explicit Render Q UIPanels

« on: January 21, 2014, 12:19:26 PM »

The new caret and highlighting on UILabels don't draw properly when the Render Q on a UIPanel is set to Explicit. This is because they use UITextures which creates a new draw call. The UITextures will have the same z-value as the rest of the widgets which causes z fighting. I suppose the easiest thing here is if the parent UIPanel is set to Explicit, provide an option for a manual z offset on the textures.

Two other less important things with UILabels: 1) Possibly provide an option to specify a sprite or texture to use (customization, plus makes it possible to use an atlased sprite instead of a texture). 2) The depth set on the UITextures only takes the depth of the UILabel into account and ignores other widgets. This isn't necessarily bad as long it's clear this is what happens, but it's currently not. Plus, I imagine the cost of creating a new draw call which will happen with Automatic UIPanels is greater than the cost of finding the maximum depth on the panel. Alternatively, an option to specify the depth that will be used along with the z-offset would do the trick.

40

NGUI 3 Support / Re: Problems with the drawing of sprites

« on: January 17, 2014, 12:57:35 PM »

It's hard to get a clear idea of what's going on from your description. It sounds like it may be the same or a similar issue as the one I'm experiencing. A few questions:

• What is your Render Q setting on your UIPanel?
• What are the z-values and depths of the background and instantiated UIWidgets?
• When you instantiate the prefab multiple times, are they all using same depth? This can cause problems if they overlap at all.

41

NGUI 3 Support / Re: 3.0.8 f7 UITexture Draw Order Oddity

« on: January 09, 2014, 06:47:28 PM »

Absolutely.

42

NGUI 3 Support / Re: 3.0.8 f7 UITexture Draw Order Oddity

« on: January 09, 2014, 06:42:03 PM »

Apologies. Just trying to bring an issue to light.

43

NGUI 3 Support / Re: 3.0.8 f7 UITexture Draw Order Oddity

« on: January 09, 2014, 06:34:44 PM »

Nope, I have the project set to 2D. Enjoy your vacation. Hopefully it's a relatively easy fix when you get time.

44

NGUI 3 Support / Re: 3.0.8 f7 UITexture Draw Order Oddity

« on: January 09, 2014, 03:11:50 PM »

I finally managed to reproduce this in a small project. [link removed]. To see the issue, simply start disabling and reenabling Sprites or Textures. You'll see the draw order changing in strange ways. The z values are set appropriately, as are all the depths.

Stranger still, if you simply move all the widgets one unit closer to the camera (i.e. z => z-1) different things happen.

45

NGUI 3 Support / Re: 3.0.8 f7 UITexture Draw Order Oddity

« on: January 09, 2014, 12:03:27 PM »

z-values are set appropriately.

BackgroundFiller (UITexture)	Material A	z = 2	depth = 0
Background (UITexture)	Material B	z = 1	depth = 1
All UISprites	Material C	z = 0	depth = 2-10
Digits 0-7 (UITextures)	Material D	z = -1	depth = 11-18