Messages

106

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

« on: December 09, 2013, 10:04:14 AM »

Words like 'Class', 'Function' and 'Enumerations' don't mean much (or anything) to a lot of people who are likely to use NGUI in an attempt to avoid programming all this stuff for themselves.

While more detailed documentation is always nice, I disagree that anything in this example should be explained in the NGUI docs. Knowing what a method, class or a coroutine is is an extremely basic knowlenge fundamental to practically any developer using Unity, and it should be learned/covered through official Unity docs and tutorials (or even through general-purpose docs on C# or programming in general), not re-explained by every plugin author. Doing so would be like having a racing game explain to the players what a wheel is.

I don't really believe in a mindset of "I'm a designer, I won't touch any code with a ten foot pole", that approach is rarely productive and usually rarely welcomed in the industry. I'm a graphic design and art history graduate, I didn't know jack about code apart from the most vague concepts a year ago, but as I have discovered, learning the very basics takes laughably little time and greatly expands what you can do.

Even supposedly designer-centric solutions like Playmaker still require a basic understanding of how code works and shower you with triggers, variables, methods, statics, loops and all the other terms - which is completely alright, as it's absolutely not some arcane knowledge.

And speaking of other example, I think the documentation explains the UIAnchor in a pretty clear manner:

Anchor script can be used for several purposes, all of which are also covered in Example 0.

• It can make widgets appear pixel-perfect on Windows machines by applying a half-pixel offset (works only for widgets parented to the anchor).
• If placed on an object it can be used to anchor that object to the side or corner of the screen.

Parameters / Tips
[...]

Doesn't sound very much like "programming terminology".

P.S.: ArenMook, by the way, isn't half-pixel thing obsolete now with the release of 3.0.7? Or it was just the inspector property that was removed? In any case, it's probably worth to update the screenshot on that page

107

NGUI 3 Support / Re: Allowing the Notify feature to send arguments?

« on: November 27, 2013, 04:43:25 PM »

Some platforms don't support reflection correctly (like Win8 RT), so the only way to trigger functions there is by using Unity's SendMessage, and you can't have arbitrary parameters with that.

Simply create a custom "data holder" script attached to your buttons. Specify the data you need on that holder script. In the notification function do UIButton.current.GetComponent<DataHolder>(), and do what you wish.

Shame to hear that, hopefully Unity folks will look into improving the situation in the future. As far as I understand, though, SendMessage supports arguments, but only one and only as a number. That could be useful in some cases (like for a set of buttons notifying damage, camera zoom, brush thickness or other similarly written methods with a different magnitude of effect), but I guess it's a bit niche area that can be always handled with a bit of additional code, without a value slot cluttering the Notify window in the Inspector.

Yeah, the idea of using a separate per-button script sounds good, certainly better than using dozens of methods in some sort of a scene manager script handling all transitions in a level. I'll try doing that, thanks! I have initially set up the scene manager thing to avoid remembering and duplicating complex transition setups involving Play Animation/Play Tween/Play Sound/WaitForSeconds for each button, but you are right, using one small component on each button to condense all transition activities sounds like more elegant way of doing it.

108

NGUI 3 Support / Re: Allowing the Notify feature to send arguments?

« on: November 27, 2013, 10:37:40 AM »

Where would you specify those extra parameters in the inspector though? How would you set their values?

Just like the Method parameter appears after a Notify slot is filled, I guess.

New public variables can be created and displayed under it. There is an argument for the selected method, and it's of GameObject type? Public GameObject variable is added to the Notify block, slot for a GameObject appears there (if I'm not mistaken, Unity handles that automatically for any public variable), you drag whatever object you want into that slot, and the value of that variable is used in a corresponding argument when Notify of that NGUI object is called during the game.

109

NGUI 3 Support / Allowing the Notify feature to send arguments?

« on: November 27, 2013, 07:47:35 AM »

Notify function is available with almost every single NGUI element and is immensely useful. Still, there is something that will make it much more versatile.

Right now, as far as I understand, Notify window populates the Method list strictly with public voids that contain no arguments whatsoever. Adding an argument stops the void method from appearing in the list. It would be nice if methods requiring arguments will be listed too, as they allow to simplify the code surrounding some stuff immensely.

For example, I have a complex encyclopedia style app with multiple screens containing various interfaces and 3d models on them, with animated transitions between those screens. As of right now, I have to make a transition manager script containing methods like:

• public void L1_To_L2 ()
• public void L1_To_L2_Reverse ()
• public void L2_To_L3 ()
• public void L2_To_L3_Reverse ()
• public void L3_To_L41 ()
• public void L3_To_L41_Reverse ()
• public void L3_To_L42 ()
• public void L3_To_L42_Reverse ()
• public void L3_To_L43 ()
• public void L3_To_L43_Reverse ()
• public void L3_To_L44 ()
• public void L3_To_L44_Reverse ()
• public void L41_To_L43 ()
• and so on

Each of them looking like this (or containing something additional like animation playback if I don't want to use Play Animation components on buttons):

1.         public void L43_To_L53A1 () {
2.                 L43Equipment.gameObject.SetActive (false);
3.                 L53A1Generator.gameObject.SetActive (true);
4.         }

One of those methods is then added into the Notify slot of a button triggering the appropriate transition (e.g. "Back" button on screen L3 runs the L2_To_L3_Reverse method). Of course, each GameObject variable has to be manually populated by the user in the scene manager component too.

As you can imagine, it's not exactly the most pleasant setup to work with. It's manageable if, like in my case, screen count is under a dozen or two, but it quickly becomes inconvenient. So, I've been looking to replace it with something more efficient. Like this:

1. public void LA_To_LB (GameObject LevelA, GameObject LevelB) {
2.                 StartCoroutine(LA_To_LB_IE(LevelA, LevelB)); }
3.  
4. IEnumerator LA_To_LB_IE(GameObject LevelA, GameObject LevelB){
5.                         LevelB.gameObject.SetActive (true);
6.                         LevelA.gameObject.animation.Play (exitAnimationName);
7.                         LevelB.gameObject.animation.Play (entryAnimationName);
8.                         yield return new WaitForSeconds(LevelA.gameObject.animation[exitAnimationName].length);
9.                         LevelA.gameObject.SetActive (false);
10.                 }

Then, a Notify list on a "Next Screen" button will show the LA_To_LB method, and upon selecting it, you'll see additional fields created in the Inspector window under the method name: them being two GameObject slots where current screen and target screen will be inserted into.

Or maybe (a man can dream, right?), even listing public IEnumerators in the Notify list, with the Notify method starting the coroutine by itself if one of them is selected.

So, how can that become a reality? Can the argument support be added by myself (if so, which scripts have to be modified and how?) or, perhaps, is it planned for future releases of NGUI?

110

NGUI 3 Support / Re: Few questions about NGUI localization methods

« on: November 26, 2013, 05:48:33 AM »

Great to hear about the CSV support coming.

What I meant in the third question is creating a build where .txt files used by the localization system are not included into the archives or encrypted, and are left out in the open, accessible for editing.

Essentially, instead of using it to embed multiple translations, I'm trying to leverage the localization system to allow text editing without compiling new build. Client complains about some sentence? I change the .txt and all is right again, without bothersome rebuilding. But I don't know how to tell the Localization component to use an external file instead of a text asset that will be hidden in the archive during the build process.

So, for that to work, do I need to alter the localization system script (and if so, what alterations do I need there)? Or maybe, there is simply a way to tell Unity not to pack certain assets (that will solve the issue without the need to change anything in the localization script)?

111

NGUI 3 Support / Few questions about NGUI localization methods

« on: November 25, 2013, 01:19:25 AM »

1. How should I go about rewriting the script to support multiple paragraphs per string properly? Having to use \n every time makes editing of stuff like huge encyclopedia entries quite a pain.

I understand why it's currently not supported: so that first word of the paragraph won't be interpreted as a name of a new string, so apart from adding the recognition of line endings to the script, I'd like to ask how to add safer syntax to the text files - for example, replacing this:

1. string1 = text1
2. string2 = text2part1\ntext2part2\ntext2part3

With this:

1. string1 = "text1";
2. string2 = "text2part1
3. text2part2
4. text2part3";

That, or replacing whole .txt reading with .xml reading where string name would be a name of a certain tag.

2. Is whole range of UTF-8 symbols properly supported (given that the font used in the game to display the game supports it)?

3. Can someone point me to the documentation that covers how can you leave certain assets accessible for editing in a build? I realize it's more of a question for Unity documentation, but I was unable to find anything in Google so I'm probably formulating the question wrong. Essentially: how can you force Unity to leave the .txt files out in the open?

112

NGUI 3 Support / Using NGUI drag detection to as alternative to Input.GetAxis?

« on: November 25, 2013, 01:03:58 AM »

Hi.

I'm working on a project that will be shipped on touch-enabled Windows 7 PCs with some weird touch screen implementation, which is a problem for standard Unity input methods. Internally it works like a mouse, but I can't figure out how mouse drag is implemented there, which is a problem for some of my scripts. While Input.GetMouseButtonDown(0) works, Input.GetAxis("Mouse X") receives no value changes ever on that PC, for some reason. Here is an example of small script that rotates the models in front of a secondary 3D camera in my UI for as long as you press a mouse button and move your mouse horizontally. Ideally, it should also translate to "hold your finger on the screen and swipe":

1. public float horizontalSpeed = 1.0f;
2. public float drag = 0.95f;
3. Vector3 v3Rotation = Vector3.zero;
4.  
5. void Update () {
6.         if (Input.GetMouseButton(0)) {
7.                 v3Rotation.y += horizontalSpeed * Input.GetAxis("Mouse X");
8.         }
9.         v3Rotation *= drag;
10.         transform.Rotate (v3Rotation);
11. }

Good thing is, I have noticed that all NGUI elements are still performing flawlessly on that PC even without a mouse, probably owing to using some custom methods that continue to work no matter if Unity writes down some stuff or not. In particular, scroll bars were still functional.

So, the question is: can I get a value similar to Input.GetAxis ("Mouse X") from NGUI scripts, or can I rewrite the code above in a way that will use NGUI drag detection? I have tried testing OnDrag () but it wasn't firing for some reason (maybe it's for objects that are being dragged and not something that gets called every time drag is done anywhere), so I would appreciate a proper example of using NGUI methods. I don't need anything fancy like collision detection, it's literally the "swipe anywhere on screen, rotate anything on screen" kind of deal.

113

NGUI 3 Support / Targeting a fixed resolution and disabling any scaling

« on: November 15, 2013, 12:12:19 AM »

Hi there!

First of all, thanks a lot for the gorgeous product, this is the first UI system on my memory that is such a breeze to work with. I've had a rather simple question about NGUI, though.

Right now I'm working on a project that will be targeting a very, very limited set of hardware, with absolutely predetermined display resolution (1920x1080). So I was curious if there is a way to completely disable of any and all NGUI elements in the Editor window, as it makes it pretty hard to preview how UI will look, especially when I'm working on a 1680x1050 monitor. I understand that in that case I won't get pixel perfect rendering in the editor window, and I realize that I will need to frequently use zoom in the scene view, but nevertheless, for this particular project I need the size of the screen to be completely set in stone, and elements constantly jumping around to fit to the changing editor viewports are complicating the work a bit.

I know there is a feature in UIRoot allowing me to lock the height of the screen, but as far as I understand, it won't guarantee a final and stable representation of UI as the window layout and proportions get shifted around.

[EDIT] Oh wait, I think that can be disregarded: I forgot about Game viewport aspect ratio lock, which, coupled with the height locking in UIRoot, forces the UI assume a proper width and thus shows it in the same way as in the final build. Nice.