Messages

1

NGUI 3 Support / Re: Tinted sprites not resulting in the expected color...

« on: June 03, 2014, 11:33:26 AM »

Yup, turns out that was it! Sorry for the super late response, I actually forgot I posted this question until I came back to the work ticket it was relevant to. Thank you for your time!

2

NGUI 3 Support / Tinted sprites not resulting in the expected color...

« on: May 28, 2014, 04:57:57 PM »

I've attached an image with the color picker open directly on top of the sprite in question. For some reason the sprite in scene ends up lighter than the desired color (in this case 255,119,0 instead of 255,47,0). When the sprite is set to be pure white it is pure white in the scene as expected. I've tried with other sprites and the outcome is the same.

The atlas is using Unlit/Transparent Colored and I am running 3.6.0 on Unity 4.5

3

NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion

« on: February 06, 2014, 05:03:03 PM »

I agree with makeshiftwings on his #1 pretty heavily. I make a lot of use of strings that I want to ResizeHeight and anchor to another widget or panel, it feels pretty common and time consuming to set that up and then the anchor inspector looks very cluttered all the time.

I also think it would be super cool if you started to move towards making NGUI more extension friendly overall. I find myself writing more and more reusable extension scripts and NGUI is one of the more time consuming things I do this for. Even simple things like a property drawer for atlas/sprite selection would be an incredibly cool time saver.

1. [UIAtlasDrawer][SerializeField] UIAtlas mAtlas;
2. [UISpriteDrawer][SerializeField] string mSpriteName;
3.  

4

NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion

« on: January 31, 2014, 03:56:28 PM »

Is the Widget Wizard being abandoned/depreciated? I kind of hope not (as I don't like having to pull the Examples in to every project) - if so it would be good to know so I can be sure to pull examples in and start using the new approach.

If not would it be possible to get the UIImageButton creation updated so that the UIImageButton script is on the Sprite and not as a parent of the Sprite? The default method of creation (collider / ImageButton script on parent, sprite and label as children) doesn't work well with the new anchoring system / collider maintain size methods.

Thanks either way!

5

NGUI 3 Support / Re: UILabel Line Spacing?

« on: December 20, 2013, 03:04:10 PM »

I actually came to make the exact same request (UILabel line spacing support for Dynamic Fonts) and this is the top post on the forum. Just wanted to add my voice to the list of people who would really appreciate this feature!

6

NGUI 3 Support / 3.0.2 DragDropItem can drop erroneously

« on: October 23, 2013, 11:02:09 AM »

I'm sure there is also an issue on how I have my object set up, but it manifests itself in a way I would consider a bug with NGUI as well.

So basically I have a DropDropItem that has a collider of course. Part of that DragDropItem is a button (nested under the DragDropItem root). Clicking the button can cause Drop() to be called in situations where OnDrag is never called. I fixed it by changing:

1. mIsDragging = false;
2.                         Collider col = collider;
3.                         if (col != null) col.enabled = !isPressed;
4.                         if (!isPressed) Drop();
5.  
6. to
7.  
8.  
9. if (mIsDragging)
10.                         {
11.                                 mIsDragging = false;
12.                                 if (!isPressed) Drop();
13.                         }
14.  
15.                         Collider col = collider;
16.                         if (col != null) col.enabled = !isPressed;
17.  
18.  

in OnPress of DragDropItem.cs


EDIT:
I forgot to mention that this is an issue because 'dropping' an object that has never been dragged causes the depth to creep lower in increments of 100.

7

NGUI 3 Support / Tween the alpha of groups of objects with the new panel depth...

« on: October 11, 2013, 08:20:44 AM »

I have what's not a problem, but more just an inefficient workflow issue with the new panel depths. First, I find them insanely handy for my major panels - I can say the game's Codex is depth 51 and never worry about issues with it clipping through [insert other random window that may be open underneath or on top of it]. However, I make very frequent use of fading in and out groups of sub objects. If the groups of objects always faded from 0->1 and back again it would be easy to just make a new component that handles this for me by grabbing all the child widgets. However, I also frequently have situations where one or more of the widgets isn't 1.0 alpha - it's some other value when the group is fully opaque.

Anyhow, pre 3.0.2 my work flow for this was simply to use panels for these groups and fade in and out the alpha of the panel. It works splendidly satisfies all of my needs. I use this setup frequently with prefabs that will spawn as children of the main panel at runtime, which also works great.

With the introduction of panel depth, however, I've found myself fighting those numbers and missing children panels somewhat frequently - especially with the prefabs that spawn at runtime. It also makes changing the depth of one of the major panels a bit of a pain (as I then have to go through the process of identifying all of the children panels and updating them as well, many of which are in separate prefabs).

So, I'm wondering if anyone in the community has a better approach for this or if it's just worth working around? My one immediate workaround thought is to create an "InheritPanelDepthFromParent" component that just crawls the hierarchy up in Start and identifies the first panel without such a component and copies it's depth. Then I'd write a real quick editor window that just identifies all UIPanels in a scene that have a parent but do not have this component (not auto-adding the component though, as obviously sometimes that wouldn't be desirable). It would still involve some extra steps, but it would let me take advantage of the awesome new panel depth feature and would completely eliminate the "well what if I update the Depth of a parent panel sometime later and forget to update this random prefab that doesn't always get spawned at runtime" worry.

Anyhow, I appreciate any thoughts/input!

8

NGUI 3 Support / Re: UILabel - ProcessText and UITable

« on: October 08, 2013, 09:24:50 AM »

Just wanted to bump this up to share the actual problem I was having. Since ArenMook couldn't reproduce the issue with the exact same font it dawned on me that the problem very well could be caused by our setup of that font.

We had the "spacing" of the font in the settings for it set to 0,3. Having an odd spacing along the vertical is what was breaking it on every other line. I don't think it's worth disallowing odd spacings at all since they're definitely used and useful in certain situations - but just be careful that they can break pixel perfection in other situations.

Thanks for helping me resolve this ArenMook! Excellent support as always.

9

NGUI 3 Support / Re: UILabel - ProcessText and UITable

« on: October 02, 2013, 11:37:31 AM »

Thanks for the quick response!

I'm attaching a font that allows for easy reproduction of this. It seems to vary based on the specific font (sometimes it works fine, sometimes every even line breaks pixel perfect, sometimes every odd line breaks pixel perfect).

Reproduction is very easy, just create a centered label in an empty scene and write a few lines. You should notice with this font that every other line breaks pixel perfection. I'm also attaching screenshots of what it looks like.

EDIT:
The issue seems to be caused by an odd value in "mHeight" - rounding it like above fixes the issue, but perhaps a better fix is to enforce not only an int mHeight, but an even int mHeight when it's getting set?

10

NGUI 3 Support / Re: UILabel - ProcessText and UITable

« on: October 01, 2013, 11:21:06 AM »

Unrelated issue, but I'm also curious if there is any reason the Y centering of fonts is not rounded to a pixel border?

With certain font sizes pixel perfection is broken depending on how many lines are rendered (usually an odd number == pixel perfect, even number == not pixel perfect).

I can easily resolve this on my end at line 774 of UILabel (in 3.0.1) and changing:

1. // Center vertically
2. fy += Mathf.Lerp(mSize.y * scale - mHeight, 0f, po.y);
3.  

to

1. // Center vertically
2. fy += Mathf.Lerp(mSize.y * scale - mHeight, 0f, po.y);
3. fy = Mathf.Round(fy);
4.  

Is there any reason I shouldn't do this?

11

NGUI 3 Support / UILabel - ProcessText and UITable

« on: October 01, 2013, 10:52:35 AM »

Hello,

First let me say I'm loving 3.0 so far. A lot of really, really awesome changes came through. However, I'm having an issue I can't seem to find the 'correct' way to solve. I have several situations where I am updating the text of a Label and then immediately resizing a UITable that contains the label. On 2.7.0 this worked fine, however - since moving to 3.0 it does not accurately resize any longer. The problem seems to be that I need to call "ProcessText" before resizing the lable. I can force this by accessing various values - but it would really be ideal if I could just directly call ProcessText() by making it public.

This is a super easy 'edit' for me to maintain, but I thought I would post just in case I'm missing something obvious. MakePixelPerfect isn't a good resolution because it also seems to be changing the dimensions of the label (one is set to "ResizeHeight" only and MakePixelPerfect is adding width to it, where as ProcessText works as expected).

Thanks for any feedback/input!

Best,
Kyle

12

NGUI 3 Support / Re: UIImageButton disabled doesn't always work based on order of operations

« on: June 01, 2013, 06:27:05 PM »

Oh excellent, thanks!

13

NGUI 3 Support / UIImageButton disabled doesn't always work based on order of operations

« on: June 01, 2013, 12:56:38 PM »

Hello,

I just wanted to submit a quick bug/fix. Depending on how the execution order goes, it's possible for a UIImageButton to immediately flicker back from the disabled sprite to the hover sprite (my script calls imageButton.isEnabled = false, then within the same frame the UICamera passes the OnHover event to the ImageButton). I fixed this locally by asking if (enabled && isEnabled && target != null) instead of if (enabled && target != null) in the OnHover method of ImageButton.cs

Not sure if you want to add this to the main release or if there's a more efficient way to fix the issue, just thought it may help someone (and hopefully it does get included so I don't have to remember to re-fix upon updating ).

Best,
Kyle