Messages

61

NGUI 3 Support / Possible Bug In NGUITools.SetActiveChildren (2.6.3)

« on: June 27, 2013, 01:34:53 PM »

In certain circumstances NGUITools.SetActiveChildren will recursively enable objects in Unity 4.0+.

NGUITools.SetActiveChildren(gameObject, true) will call NGUITools.Activate() which contains the following:

1. static void Activate (Transform t)
2. {
3.         SetActiveSelf(t.gameObject, true);
4.         // Prior to Unity 4, active state was not nested. It was possible to have an enabled child of a disabled object.
5.         // Unity 4 onwards made it so that the state is nested, and a disabled parent results in a disabled child.
6. #if UNITY_3_5
7.         for (int i = 0, imax = t.GetChildCount(); i < imax; ++i)
8.         {
9.                 Transform child = t.GetChild(i);
10.                 Activate(child);
11.         }
12. #else
13.         // If there is even a single enabled child, then we're using a Unity 4.0-based nested active state scheme.
14.         for (int i = 0, imax = t.childCount; i < imax; ++i)
15.         {
16.                 Transform child = t.GetChild(i);
17.                 if (child.gameObject.activeSelf) return;
18.         }
19.  
20.         // If this point is reached, then all the children are disabled, so we must be using a Unity 3.5-based active state scheme.
21.         for (int i = 0, imax = t.childCount; i < imax; ++i)
22.         {
23.                 Transform child = t.GetChild(i);
24.                 Activate(child);
25.         }
26. #endif
27. }

Notice that if !UNITY_3_5 and all children of the transform are activeSelf == false, the final for loop is executed. For example, in the following hierarchy:

1. Parent (active)
2.         Child (inactive)
3.                 Subchild (inactive)
4.  

If NGUITools.SetActiveChildren(Parent, true) is called, both Child and Subchild will be enabled. Obviously, this can occur recursively to any depth.

62

NGUI 3 Support / Re: Changing UITextures at runtime

« on: June 19, 2013, 09:58:56 AM »

2.6.1e. I haven't gotten around to upgrading to 2.6.3 yet.

Regarding clearing the texture from the prefab, I threw together a test scene and it looks like that may be the solution. I tested this before but it didn't work because the other issues were interfering. Here's what happens:

Case 1: Adding a new UITexture component to the prefab will have no material, texture, or shader. If copies are instantiated at this point, everything behaves correctly.

Case 2: Assigning a texture to the UITexture prefab will auto generate a material and choose a shader. If copies are instantiated at this point, changing the texture on any instance changes every instance, like one would expect.

The unintuitive part:
Case 3: Removing the texture (and/or shader) from the UITexture prefab does not remove the autogenerated material. If copies are instantiated at this point, one would expect things to act like Case 1 above, but instead changing the texture on any instance changes every instance.

The only way to distinguish when Case 3 will occur is when the Material is hidden on the UITexture prefab. There is no way to get back to Case 1 without removing the UITexture component and readding it.

I can't test this in the original scenario at the moment, so I don't know why it would work for a while and then suddenly stop, but I suspect it has something to do with the prefab being updated with changes to instances.

63

NGUI 3 Support / Re: Changing UITextures at runtime

« on: June 18, 2013, 02:49:37 PM »

Still curious about this if anyone has any insight.

64

NGUI 3 Support / Re: Changing UITextures at runtime

« on: June 13, 2013, 10:34:19 AM »

Thanks for the response. I'm a bit unclear on a couple of your points.

• If you duplicate a UITexture within the editor, it will use the same material until you hit Play.
  So if I copy and paste a UITexture from in the hierarchy, they will use the same material. Thus, changing one texture changes all of them. But when I hit play, they will all get separate materials and can be changed independently. Testing bears this out.
  
  
• If you assign a material instead of assigning a texture, it will always keep using that material (which will then be shared between different UITextures).
  What do you mean it will be shared between different UITextures? If I assign a material to one UITexture, will all other UITextures start using that material?
  
  
• Otherwise UITextures should have different materials, generated dynamically.
  Wouldn't instantiating copies of prefab at runtime fall under this category? If so, I shouldn't be seeing all UITextures change when I change just one, correct? As far as I can tell through testing, if a texture and shader are chosen on the prefab, a material is created for the prefab. If the prefab is instantiated at runtime, it keeps it's material and all instances will share the same material. Changing one changes them all unless a new material is explicitly applied.
  
  Here is where I believe the problem lies. This isn't consistent. When I first load Unity and play my game, every instance acts like it has it's own material. Changing one texture does not change them all. After a few minutes or playing the game a few times (not sure which) they suddenly start acting like all share a material. Changing one texture changes them all.
  

I've worked around the problem by assigning a new material to each UITexture as they are instantiated, but I still want to understand how this is supposed to work. I can see arguments for instances of prefabs sharing the original material and for having their own, however, changing the texture on one should be consistent. The question is, should changing the texture create a new material so it can't affect other instances, or should changing one instance be able to change all of them? We can obviously assign a new material explicitly when we want to ensure we don't affect other instances, however this could be done automatically with, say, a boolean createMaterialOnChange.

PS While testing this, I noticed other odd behaviors.

• I have a background panel with a UITexture and a second panel with a z = -1 offset that I'm testing on. I'm getting z fighting issues between the two separate panels. If I put a widget on the second panel, which is above the background, and I offset the z value of the UITextures by -1, the UITextures draw below the background, but only if using the same material and only in the editor. The panel tool reports 3 draw calls.
  
  
• When the material is auto-generated the shader and texture are not shown in the editor. This makes it difficult to test things in the editor, as textures changes must be done in code.
  
  
• Changing the texture or shader of an instance of a prefabbed UITexture at runtime, without giving it a new material, causes the prefab to change. Since the instance of the prefab keeps the same material and apparently it is serialized.
  

65

NGUI 3 Support / Changing UITextures at runtime

« on: June 12, 2013, 03:06:41 PM »

I've run into a bit of a problem using UITextures and hoping someone can point me in the right direction. I'm instantiating 6 copies of a prefab with a UITexture on it. Then I'm choosing which texture should be used on each item, of which there are 2 placeholder textures and the rest are downloaded from the internet. What I'm seeing is things working precisely as I expect for a while, but then after running the game enough times in the editor, changing the texture on one instance causes all of the other instances to change too. I'm trying to prevent this from happening.

I'm guessing it has something to do with the materials being used for the UITextures. Possibly that they all have the same material. However, I thought UITextures generated their materials automatically.

Some extra info: the prefab has the Unlit/Transparent Colored shader assigned. The prefab does not have any texture assigned (though I noticed the prefab actually get's updated based on which textures are set at runtime, odd). I'm using mUITexture.mainTexture = downloadedTexture to change the textures.

66

NGUI 3 Support / Re: Script | Scale text to fit in max size

« on: May 13, 2013, 12:20:27 PM »

This is a great addition. However, I'd like to point out that it doesn't seem to work with multiline text. It just shrinks everything on the first line, rather than breaking to a new line and filling it up before trying to scale.

67

NGUI 3 Support / Re: Occasionally Skipping A Tween

« on: March 06, 2013, 04:45:46 PM »

This has the drawback of forcing all TweenedWindows to use the same settings. The script is meant to be generic so that I don't need unique scripts for each differently tweened window.

68

NGUI 3 Support / Occasionally Skipping A Tween

« on: March 06, 2013, 04:15:47 PM »

I'm having a bit of trouble accomplishing something with tweening. I use a generic script from my in game windows with a Hide and Show method that tweens the windows in and out. (from .1 to 1 scale when Show, and reversed in Hide). Occasionally, I want to Show a window, but not have it tween, and I need to accomplish this is such a way that it doesn't interfere with any future Show or Hide calls.

Is there a recommended way to handle this?

For reference, here's what I have currently:

1. using UnityEngine;
2.  
3. [RequireComponent(typeof(TweenScale))]
4. public class TweenedWindow : MonoBehaviour
5. {
6.         public bool tweenOnAwake;
7.         public bool destroyOnHide;
8.  
9.         private UITweener tweener;
10.  
11.         private void Awake ()
12.         {
13.                 tweener = GetComponent<UITweener>();
14.  
15.                 if ( !tweenOnAwake )
16.                 {
17.                         tweener.enabled = false; //This breaks subsequent tweens
18.                 }
19.         }
20.  
21.         private void Show ()
22.         {
23.                 tweener.Play(true);
24.         }
25.  
26.         public void Hide ()
27.         {
28.                 if ( destroyOnHide )
29.                 {
30.                         tweener.onFinished += Destroy;
31.                 }
32.  
33.                 tweener.Play(false);
34.         }
35.  
36.         private void Destroy ( UITweener twnr )
37.         {
38.                 GameObject.Destroy(gameObject);
39.         }
40. }
41.  

69

NGUI 3 Support / Re: Using / Reusing TweenScale : UITweener

« on: February 22, 2013, 12:59:10 PM »

I was just searching for information on what appears to be the same issue. Using a small number instead of 0 fixed the problem for me. I've been using tweening from 0 to 1 for a lot of stuff and only have had an issue in a small number of cases. It works fine 9 times out of 10, but there seems to be a few situations where it chokes. In particular, I've noticed if I have a TweenScale and UIPanel script on the same GameObject, the tweening happens but the textures are not drawn.

On a side note, changing my tween values from 0 to small numbers makes the animation extremely jerky. I'm only seeing 2-3 updates.