Messages

1

NGUI 3 Support / Re: Typewriter text that fits label beforehand

« on: January 25, 2015, 02:30:48 PM »

That's what I would advise, yes. Keep the font at its decently small size and don't worry about shrinking. The typewriter script works best with that kind of text.

Good point, I'll do that.

2

NGUI 3 Support / Re: Typewriter text that fits label beforehand

« on: January 24, 2015, 12:44:08 AM »

Why use shrink to fit with something like this? You should just keep it at something else -- something that doesn't change the size of the text. You can pre-wrap the text easily by simply turning on TypeWriterEffect.keepFullDimensions.

I'm using shrink because sometimes the dialogue might be too long for the label.

I could keep the text a certain size that works for all lengths of dialogue. I suppose that would be more consistent. However I prefer to keep the text bigger for general readability and shrink it just in case the dialogue is too long.

Am I trying to solve a problem that's too difficult? I could just keep the text size small by default and not worry about shrinking as a last resort.

3

NGUI 3 Support / Typewriter text that fits label beforehand

« on: January 23, 2015, 12:12:59 AM »

So I'm using NGUI's example typewriter script to make dialogue "type itself out" when characters talk in the game via dialogue boxes.

The dialogue's label's overflow property is set to "Shrink content," so that the dialogue will automatically shrink if it's too big. I am trying to pre-shrink the dialogue before it's rendered because a dynamic shrink is jarring. I also try to insert line breaks at appropriate locations so that a word is not shoved to the next line as it's typed out -- it automatically goes to the next line because a newline is placed right before it.

To achieve this, I do the following:

1. Give the label the message first, update it, and then record the scale value returned to influence the font size. I had to expose one variable as public first, which I didn't like to do. I don't know much about the internal workings of NGUI so this is something I thought of as an experiment.

1.   // scale text first
2.   // NOTE: this code assumes that the text in this label scales!
3.   mCharDialogueMessageLabel.fontSize = 45;
4.   mCharDialogueMessageLabel.text = message;
5.   mCharDialogueMessageLabel.Update();
6.   mCharDialogueMessageLabel.fontSize =     Mathf.FloorToInt(mCharDialogueMessageLabel.fontSize*mCharDialogueMessageLabel.scale);
7.   mCharDialogueMessageLabel.text = string.Empty;
8.   mCharDialogueMessageLabel.Update();
9.  

2. After the font is scaled by NGUI (or maybe not??), insert line breaks at the correct locations

1.     // account for line breaks at proper positions (i.e. so text doesn't wrap to next line)
2.     // AFTER scaling text properly (since text needs to fit label first, then adjusted for word wrap)
3.     mCharDialogueMessageLabel.UpdateNGUIText();
4.     char[] delimiterChars = { ' ' };
5.     string [] parts = message.Split(delimiterChars);
6.     // add words to the modified string
7.     StringBuilder currLine = new StringBuilder();
8.     StringBuilder overallText = new StringBuilder();
9.     for (int i = 0; i < parts.Length; i++)
10.     {
11.       string currWord = parts[i];
12.       if (currLine.Length > 0)
13.         currLine.Append(' ');
14.       currLine.Append(currWord);
15.  
16.       Vector2 printedSize = NGUIText.CalculatePrintedSize(currLine.ToString());
17.       // this is the part where we find out if we went to next line...if so, then
18.       // we need a line break
19.       if ((int)printedSize.y > mCharDialogueMessageLabel.fontSize)
20.       {
21.         currLine.Remove(currLine.Length-currWord.Length, currWord.Length);
22.         // remove white space at the end, otherwise it will mess up the new line
23.         overallText.Append(currLine.ToString().TrimEnd(delimiterChars));
24.         overallText.Append('\n');
25.         // current line starts over with current word (since we need a new line)
26.         currLine.Remove(0, currLine.Length);
27.         currLine.Append(currWord);
28.       }
29.     }
30.     // currline is within printed size, just add it
31.     overallText.Append(currLine);
32.     // overallText is then given to the typewriter
33.  

Anyway, this code seems to work for the most part even though I'm kind of shooting in the dark. But there is an example where it doesn't work, as seen in this video:

https://www.dropbox.com/s/g1wh1exumngogvj/DialogueTypingError.mov?dl=0

Notice how the dialogue shrinks at the end? I want to avoid that -- it should be scaled appropriately beforehand. I believe that if I print out the fontscale after the typewriter is finished, it's different compared to the scale computed above. Anyway, just wondering if there is a reasonable solution to this or if this has been done.

4

NGUI 3 Support / Re: Detecting if ui sprite is partially off screen

« on: November 05, 2014, 02:54:18 AM »

-1 to 1 only works if you are working with view space coordinates, which are not going to be used unless you take the world space position and convert it using camera.WorldToViewPortPoint. Any NGUI widget's rect can be retrieved using worldCorners property.

I see. Seems like worldCorners property is based on the -1.0 to 1.0 coord system too. I can probably use those corners to figure out what percentage of the item is outside of the view, and then shift the item over by that percentage...right?

5

NGUI 3 Support / Detecting if ui sprite is partially off screen

« on: November 04, 2014, 03:40:23 AM »

So my problem is fairly simple: if a ui sprite is partially offscreen (like more than half of it), move it toward the center. The context is that I can select objects in the game, and when I do a menu pops up over the selected object. It doesn't look good if the object is near the edge of the screen and the menu is partially cut off after it appears (i.e. with parts of the menu being rendered off screen).

So one option is to detect if a ui sprite button is offscreen. I've noticed that if the sprite's transform position (not local position) is less than -1.0 in any dimension or more than 1.0 in any dimension, then at least half of it is off-screen. It seems as if NGUI objects end up in a coordinate system that goes from -1.0 to 1.0 in X and Y. Is that a reasonable assumption?

The next problem would be: how would I make sure that the sprite appears onscreen, or with no portions being rendered offscreen? One good solution is that I can push it toward the center by some offset (based on the size of the sprite portion that is off screen).

Edit: I found this thread http://www.tasharen.com/forum/index.php?topic=9889.msg46501#msg46501

Has references to HUDText (which I don't have). There are is also a warning regarding directly using Screen.width and height since the UIRoot's settings may not jive with that idea. So I thought it would be best to rely on the (-1.0, 1.0) transformed coordinates to figure out how much of the sprite is offscreen.

6

NGUI 3 Support / Re: Possible to control alpha on word/letter level?

« on: May 13, 2014, 02:04:43 PM »

I've added support for full RGBA color encoding in 3.6.0. Pro users have access to it now. You will find it in the next update.

Awesome. I'll remove my kludge once that comes out.

7

NGUI 3 Support / Possible to control alpha on word/letter level?

« on: May 11, 2014, 08:23:48 PM »

I wanted to write a sentence out by fading in words individually. 

Based on what I know, it's not possible to modify the alpha values of individual words or letters of a label. I suppose a good alternative is to have separate words as labels and tween their alphas individually. Still, I wonder if there is a cleaner method, since I would have to position the words manually (and make their spacing look "correct").

8

NGUI 3 Support / Re: Tiny cosmetic issue with adding items to scrollable view

« on: March 22, 2014, 05:55:57 PM »

UIGrid used by the drag & drop example has "animate smoothly" turned on, which uses SpringPosition to move items into place. SpringPosition has the "Update Scrollview" flag turned on, which simply calls scrollView.UpdateScrollBars(true) on line 108 of SpringPosition.cs -- inside its Update() function.

Ok so I basically have a bool now that is set to false. I update the grid in Update() if the flag is false, then set the flag to true post-update. That seems to work. It doesn't work when I try to set the grid in Awake...at least the former function is called once.

9

NGUI 3 Support / Re: Tiny cosmetic issue with adding items to scrollable view

« on: March 21, 2014, 03:53:31 PM »

Have you tried calling UIScrollView's UpdateScrollbars function?

Since the UIGrid is a child of the panel containing the UIScrollView, I did this:
this.transform.parent.GetComponent<UIScrollView>().UpdateScrollbars(true);

No dice. Now you do have a drag drop example...and in that example it would appear that the scrollbar updates dynamically. You basically just call UpdateScrollbars when each item is "dropped" into the destination scroll view?

10

NGUI 3 Support / Tiny cosmetic issue with adding items to scrollable view

« on: March 21, 2014, 01:47:40 AM »

So I have a scrollable view with a scrollbar (vertical). There is a grid inside of the scrollable panel.  The items are added after the scene loads via a script attached to the uigrid object. Something like this:

1. int levelIndex = 0;
2. foreach(string levelName in mLevelNames)
3. {
4.   Transform newLevelItem = NGUITools.AddChild(this.gameObject,   mLevelItemPrefab.gameObject).transform;
5.   MenuLevelItem menuLevelItem =  newLevelItem.GetComponent<MenuLevelItem>();
6.   menuLevelItem.mLevelName = levelName;
7.   newLevelItem.name = levelIndex.ToString("00");
8.   newLevelItem.localScale = new Vector3(1.0f, 1.0f, 1.0f);
9.   newLevelItem.localPosition = new Vector3(0.0f, 0.0f,0.0f);
10.   menuLevelItem.DisableButton();
11.   levelIndex++;
12. }
13.  

The items are added correctly...however the scrollbar foreground (the draggable part) appears to be the incorrect size. It corrects itself after I start to scroll the area, which is a bit jarring. Setting repositionNow to true on the UIGrid doesn't seem to help, and neither does calling ResetPosition on the UIScrollView. Any thoughts? Thanks.

11

NGUI 3 Support / Re: Strange error regarding buttons that are disabled

« on: August 06, 2013, 12:59:38 AM »

I mean the general OnEnable call. All scripts get this call when they get enabled. UIButton does some things in its OnEnable which likely conflicts with you setting the button's isEnabled state before it.

I've placed breakpoints at the appropriate places (the setter and OnEnable), and nothing seems out of the ordinary there. In other words, those functions don't undo my code in any way.

It turns out the problem doesn't relate to panel A or panel B, but their parent (yes, the menu system is a bit complicated). Panel A and B are children of a "root menu" that can fade if the user wants to view the options or help screens. When the root menu fades in (shows up), there is a function (event receiver) that enables all the buttons of its children by default.  This global enabler function is only called once when the root menu is enabled, so it doesn't normally cause problems when moving between panels A and B. Note that if the root menu is enabled and panel B is hidden (which is the default), that panel won't work even though its buttons are enabled.

But if one were to click one buttons of panel A when that panel is fading out, that root's enabler is called somehow. A bit strange, but it happens. Edit: ah, figured out what's happening. The user can click a button from panel A before the root's tween function calls the enabler function (basically as the root menu is "fading in"). So would could happen is that panel A's buttons can be clicked by the user before that enabler function is called. As I said, they are disabled when they are clicked...but in this scenario the root's tween finishes and the enabler is called, which re-enables the buttons.

12

NGUI 3 Support / Re: Strange error regarding buttons that are disabled

« on: August 05, 2013, 11:30:42 PM »

Which version of Unity are you using, and which version of NGUI?

I am using Unity 4.1.4f1, and NGUI version 2.6.3.

I'm not sure how OnEnable would undo what I am doing, and if it is being called after the buttons are being disabled, but I can check.

13

NGUI 3 Support / Re: Strange error regarding buttons that are disabled

« on: August 04, 2013, 12:52:52 AM »

My guess is that your "is enabled" state gets overwritten shortly after you set it. You need to run your code after UIButton's OnEnable.

You're referring to the isEnable = false code, right? I'm not sure which code would cause the button to enable itself. I should clarify that the gameobject with the UI Panel (A) is a parent to the buttons, and it gets disabled after the tween alpha operation is complete (since the tweener calls a function that does that).

Also the strange thing is that this problem only occurs when the panel is fading for the first time after the scene loads. The problem doesn't repeat itself.

14

NGUI 3 Support / Strange error regarding buttons that are disabled

« on: August 04, 2013, 12:22:28 AM »

This might be a bit complicated so it will take a bit of explanation.

I have two ui panels. One of them has a set of three buttons (panel A), each of which transition to another panel (call it panel B).  If the user clicks one of the buttons, panel A fades out and loads the following ui panel (which "fades in").

A fade out process basically activates the tween object of the panel, causing it to go transparent. At the end of the tween, a function is called which disables the uipanel's gameObject (using something like NGUITools.SetActive(gameObject, false)). Right as the fade begins, the buttons of the fading panel are disabled to prevent any spurious clicks during the fade procedure (by setting each button's isEnabled property to false).

Basically panel A is supposed to fade out while it's buttons are disabled, and it's supposed to be disabled after  fading completes. That works for the most part, except when it does the fading procedure the first time after the menu loads and the user clicks a button, the buttons can be clicked during the fade -- they are not disabled even though they are in the code. That's the bug. Now let's say the user goes back from panel B to panel A. The same button is clicked again and panel A fades again. This time the UI behaves perfectly.  So this bug only occurs once...and I'm not sure why.

Anyway, I can provide the relevant code...I just thought I would explain from a higher level before doing so.  Any suggestions would be appreciated.