Messages

1

NGUI 3 Support / Re: Glyph corruption issue in a dynamic UILabel: anyone else?

« on: July 17, 2014, 12:42:33 AM »

I'm getting this pretty consistently after doing a Google Play Billing purchase.  When the Android purchase window pops up it puts the app into pause mode but leaves it open in the background, then when the purchase window closes it resumes the Unity app and messes up the dynamic fonts if I try to set any labels soon after that, and then that font remains corrupted until I kill the app.

2

NGUI 3 Support / Misplaced Component Menu

« on: May 04, 2014, 04:47:06 PM »

The "UIKeyBinding" script shows up in the Component menu under "Game/UI" instead of "NGUI/UI" like every other component.  Can it be moved to "NGUI/UI" in an upcoming build?

3

NGUI 3 Support / Re: Bug in UILable.

« on: March 22, 2014, 07:24:34 PM »

FYI, I changed that "!eastern" to "eastern" and it works again.  Of course I'm not using Eastern fonts, so I don't really know if that somehow breaks something else if you are using Eastern fonts; I couldn't figure out what that section of code was really trying to do. :B

4

NGUI 3 Support / Re: Bug in UILable.

« on: March 22, 2014, 07:04:47 PM »

I stepped through the code and see why it fails.  In NGUIText.cs, line 874:

1. // Doesn't fit?
2. if (Mathf.RoundToInt(remainingWidth) < 0)
3. {
4.         // Can't start a new line
5.         if (lineIsEmpty || lineCount == maxLineCount)
6.         {
7.                 if (ch != ' ' && !eastern)
8.                 {
9.                         fits = false;
10.                         break;
11.                 }
12.  

If it reaches the max length of the line, and the character is not a space, it immediately breaks out of the for loop and returns fits = false.  But the fits value is ignored by everything except ShrinkToFit.  So the string buffer only contains the text it got to at that point, which truncates everything else, and never actually wraps the text either.

5

NGUI 3 Support / Re: Bug in UILable.

« on: March 22, 2014, 06:32:24 PM »

I'm seeing the same bug as Romulus.  Not sure what's causing it yet.

6

NGUI 3 Support / Re: My Big List of Anchor Complaints

« on: February 17, 2014, 05:04:14 PM »

Set UIRoot to Fixed Size (height of your target device), and set the target Aspect Ratio on the Game View, and nothing will change as you resize your game view.

I tried that, and it mostly stays the same, but every anchor still overwrites the scene file with tiny insignificant changes to all the positions if I resize the game view.  It seems like it still recalculates every time I change the window and just gets a different value every time due to floating point rounding.  Ideally there should be a way to tell it to just ignore the game view window, by for example being able to set a fixed width instead of just a fixed height in the UI Root (not great but ok) or by being able to set a fixed "design" resolution that sticks in the scene view and then have the anchors reposition at runtime if it's a different resolution in play mode.  (This is what I'm used to with all other UI tools).

7

NGUI 3 Support / Re: My Big List of Anchor Complaints

« on: February 16, 2014, 04:31:36 PM »

I'm glad to hear the size fields will be editable soon; that will make our lives easier.  I still have to disagree that the game view window is supposed to represent the "true" look of the scene.  I see it as a quick way to test things while in the editor.  The "true" look is when you actually build the game and play it at the intended resolution.  That's why by default, the game view window is easy to resize and move around and in many of the default Unity layouts, it is sitting in a corner at a tiny resolution and weird, too-wide aspect ratio.  NGUI is also the only asset I've ever seen that alters the scene and overwrites your data based on how you move the game view window around in your editor layout.  To me, those things need to be totally separate.  My Unity layout and the size of the game window at any particular point have nothing at all to do with what I want anything in my game to actually look like.  Btw, by "inactive", I mean the game view when not in play mode.  I don't think the game view should have any effect on the scene in general (again, that's a Unity concept; in that all your changes while in play mode don't get saved back to the scene), but I especially don't think the game view should have any effect on the scene when you're not even in play mode.  In both games I'm working on, what's displaying in the game window when in edit mode doesn't really look at all like what the actual final game looks like.  The game view while in edit mode shows all components before they've had "Start" or "Awake" called on them, for example.  In one of my projects, the level is completely procedurally generated, which means while in edit mode the game view doesn't display much of anything, so it definitely doesn't represent the actual look of my game.  Setting the game view to a specific resolution helps a bit, in that NGUI moves things move around much less, but it's still not perfect because NGUI does still nudge things around a tiny bit any time I widen the inspector to look at something or (ironically) expand my scene view to work on the UI.  So it is constantly overwriting the prefabs in the scene with tiny floating point differences in UI transforms every time I touch anything.  I don't really think many people appreciate this "feature"; I see lots of people asking how to set a fixed width in the forums, or asking why NGUI keeps overwriting the scene, but I've never seen anyone say they really liked that resizing the game view window while in edit mode caused their UI to move all over the place in the scene view.  I just don't see the benefit that it gives anyone that outweighs the annoyances.

8

NGUI 3 Support / Re: My Big List of Anchor Complaints

« on: February 15, 2014, 05:31:35 PM »

2) I think what you're looking for is Unity's fixed game view size, not changing how anchors work with window size. Anchors *should* adapt to whatever resolution you're using, as they do.
If you want to have a fixed window size, look at game view, in the top left you can set a fixed aspect ratio or resolution, then if you resize it won't change the ratio of the gui.
However, in the Scene view, it'll keep jumping back to some default value defined by who-knows-what. For example I have a background that stretches to fill UIRoot (fill screen), that keeps jumping to a 4:3 ratio in scene view and 16:9 in game view. which is somewhat annoying... if UIRoot looked at the Gameview dimensions as a reference when sizing the GUI that might stop?

I hadn't noticed you could set a resolution instead of just an aspect ration in the game view window.  That helps a little bit, but the anchors still constantly overwrite the scene if you touch any of the editor windows, which is half the problem.

@sintua first:

I just did a quick test:

1. New scene, ALT+SHIFT+S to make a sprite, ALT+SHIFT+L to add a label.
2. Moved the label, advanced anchor, set the Left side to be anchored to the sprite.

The label remains resizable. Nothing is ever grayed out. Even if I anchor it fully it remains resizable. Are you running some old version?

For me, it grays out the width as soon as you anchor either left or right, and grays out the height as soon as you anchor either top or bottom.  I'm using 3.4.9.

1. Why do this? Why not just move the sprite to where you want it to be and then anchor it? Why use numbers at all? If you want to fine-tune its placement, use arrow keys for nudging, just like in Photoshop, or hold CTRL to disable snapping to edges. Numbers are there for those who need them, but are certainly not necessary to create a layout.

Because sometimes we anchor the sprite but then realize we want to change the size, or we set the size and realize we want to change the anchor.  And we have to set the size manually by number to make it pixel-perfect since we have to use Fixed Size to stop everything from sliding all over the place when you move the play window.

2. A good UI tool should always be WYSIWYG. I never liked this feature of DF GUI where the editor would look one way then as soon as you hit Play, things change. It's inconsistent, and is a bad idea. As sintua mentioned, set a fixed size on the game view itself. This way everything will look as you will expect it to. Also, multiple monitors with the game view being on a separate monitor is a very useful thing to have.

It should be WYSIWYG in the scene view.  The scene view should not react to the inactive game window at all.  No other tool or asset I've ever used in Unity acts like that.  Unity is built around the idea that you do all your design in the scene view and then look at it in action in the game view, not the other way around.  Scene view should always take precedence when you're not in play mode.

Edit:  I wanted to add, I just want the OPTION of having a fixed width and height when designing the UI and to have it not overwrite the scene when moving editor windows.  If other people find the current behavior useful, then that's fine, there are already three options in UI Root to get the slidey behavior.  There could be one more for "ActualFixedSize" that actually fixes the size instead of just the height.

9

NGUI 3 Support / My Big List of Anchor Complaints

« on: February 14, 2014, 04:56:28 PM »

First let me start off by saying I love NGUI and have been using it for quite a while now, and appreciate all the work you've put into it ArenMook!  But in the interest of improving NGUI, I'd like to list some issues my team's having with the anchor system.  I'd also like to know if there is a chance that you will look into some of these issues and consider changing the anchor system, or if my whining is a lost cause and I should give up and switch to DF-GUI

1) Too much math.  No offense to my artist friends, but they don't like doing math in their heads, and neither do I to be honest.  If I want a button docked at (16,75) and it's 125x270 pixels, I currently have to do the math in my head to figure out that the right and bottom anchors need to be 141 and -195.  Ain't no one got time for that.  There needs to be a way to dock a widget and set its size like in most GUI designers.  I think the old anchor system was superior in this regard.

2) Anchors need to be completely divorced from the size of the game window in the editor.  I don't think anyone gets any benefit out of having their UI slide around when they widen the inspector to look at some random thing or resize Unity to look at their web browser.  And the fact that Anchors constantly overwrite the transforms of everything while in edit mode causes the scene to constantly need to be saved over and over and causes lots of bloat and annoyance with source control.  We should be able to set a default width and height for our UI that is consistent within the editor, and UI should only get stretched by the game window size when actually entering play mode, so that it is runtime only and doesn't overwrite the scene file.  I really need to know if this will change or if you are wed to the current system, because it's causing too many headaches.

I was going to whine more about anchors, but really those two are my biggest complaints; if I knew they were being addressed at some point it would put my mind at ease.

10

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

« on: February 11, 2014, 06:12:50 PM »

A few more headaches with the new anchor system:

- As mentioned above, it should be easier to only anchor to particular sides (top and left) rather than needing to anchor every side.
- To go along with that, if you use Advanced mode and leave some anchors blank, you need to re-enable the widget size controls so we can actually size it.
- Ideally, don't ever disable the widget size controls, and just change the anchors if the user changes the size (maintain anchor based on pivot location) and vice versa.

11

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

« on: February 06, 2014, 01:51:33 PM »

A few things that would make my life much easier:

1) When selecting "Unified" anchor, put checkboxes next to Left, Right, Top, Bottom to turn them on or off.  I know you can do it by using Advanced and deleting the object from the fields for the ones you don't want, but that's unintuitive and takes up a lot more inspector space.

2) There should be a way to set a fixed width in scene mode for designing your UI, and not have it automatically move around when you resize the play mode window.  Nothing else in my scene view while in scene mode reacts to me moving or scaling the play mode window, so it's disruptive to have NGUI do it.  Especially since I usually have the play window under the scene window, and enlarging the scene window so that I can have a better view of my GUI has the exact opposite effect because it causes everything to fly off to the sides of the screen in whatever ridiculous aspect ratio the play window is in.

3) We should be able to set the size of a non-clipping panel.  Currently to make something like a window I have to make both a panel and a blank widget and set the size in the widget.  This seems dumb since a panel has its own rect already and just adds more clutter to the hierarchy.  I think for most people, the use case of a panel with some sort of size to it comes up much more than a use case where you need a panel of infinite size.  I guess a simpler way would just be to make a panel a widget.  Is there a reason that a panel is not a widget?  Maybe you could add a "Window" or "Container" class that is basically just a panel-widget, if you need to preserve backwards compatibility for people who need infinite size panels?

12

NGUI 3 Support / Re: 3.0.9f1 broke my tweens!

« on: January 18, 2014, 04:54:00 PM »

The change that broke it is this, from the Update call in UITweener:

1. List<EventDelegate> mTemp = onFinished;
2. onFinished = new List<EventDelegate>();
3. EventDelegate.Execute(mTemp);
4.  

You set onFinished to an empty list, which makes it delete the onFinished method after the first tween, so it never gets called again.  Looking at it, I assume you meant to add "onFinished = mTemp" afterwards.  I added that and it fixed it.

13

NGUI 3 Support / 3.0.9f1 broke my tweens!

« on: January 18, 2014, 04:29:45 PM »

(Edit: solved, see second post)

I had a Table full of icons in a Panel that would tween position down, then reorder the icons, then reset the tween and play it again.  (Basically to create a looping slot machine sort of effect).  This was working fine until the update to 3.0.9f1 today.  Now it tweens down only once, and when I call tween.ResetPosition and tween.PlayForward from OnTweenFinished, it doesn't seem to do anything.  I saw in the patch notes that you made some changes to how OnTweenFinished works, but in my case it seems to have broken all the tweens.  Any ideas?

14

NGUI 3 Support / Re: Dynamic Fonts v2.6.1 UILabel \n Escape character failure？

« on: May 09, 2013, 05:32:51 PM »

Doesn't it still do a string replace to deal with the NGUI custom format tags like color codes?

15

NGUI 3 Support / Re: Dynamic Fonts v2.6.1 UILabel \n Escape character failure？

« on: May 08, 2013, 07:03:50 PM »

I'm using NData, and \n has stopped working in all the TextBindings.  Do you know how to best fix this?

Edit:  I've started adding string.Replace("\\n", "\n") to everywhere in my code where I pass a string to a label, but this is going to be a huge pain.  Is there a reason that you removed the automatic conversion?