Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - ArenMook

Pages: 1 2 [3] 4 5 ... 10
Misc Archive / Just to make it easier...
« on: July 22, 2014, 11:13:11 PM »
As you guys know, NGUI 2 is a free package. It's available for download free of charge, and can be used in any project, falling under the same restrictions as Unity Free. This also means that since it's free, Tasharen can't provide any dedicated support for it, but it doesn't mean that the community can't help each other out. The only issue was that there hasn't been a dedicated place for people to do so, and NGUI 2 questions were mingled with NGUI 3 questions in the support forum. Well, hopefully this forum will clear things up. If you're using NGUI 2, you are welcome to use this forum to post questions, and perhaps others can help you out.

Misc Archive / Oh right, this forum...
« on: May 09, 2014, 09:52:37 PM »
Blarg. The other day I was wishing I could just make some kind of a video or a post about what I'm doing with Windward (currently doing a moddable inventory system), but thought about it and realized that putting it on YouTube wouldn't be a good idea (too technical, most people's eyes would glaze over). Somehow I totally forgot that I have this place, viewable only by a few technical people that I can simply use as a scratch pad / brain dump. Hmm!

NGUI 3 Documentation / Property Binding (data binding)
« on: March 27, 2014, 07:05:39 AM »

Property Binding component lets you do basic data binding. Data binding is when you have one value automatically update some other value without having to write code.

NOTE: This feature was added in NGUI 3.5.6.

To use it, simply attach the Property Binding component to any game object. It's not UI-specific and will work just fine on any game object.

Once the script is attached, choose the Source object that contains the script with one of the values you want to bind, then the Target object that contains the script with the target value you wish to bind it to. Choose the appropriate property or field from the drop-down list that will appear underneath each object, and that's all it takes to bind two values.

You can change which value updates the other by modifying the Direction, and you can change when it gets updated using the Update field. When working with a script that should not be updated while outside of Play mode you might want to turn the Update in Edit Mode off.


Under the hood the Property Binding script is actually quite short. It simply has two public PropertyReference fields and it sets one's value based on the other's value. You can use PropertyReferences yourself freely in your own script. For example this small script will update one property using the value of another:
  1. using UnityEngine;
  3. [ExecuteInEditMode]
  4. public class Test : MonoBehaviour
  5. {
  6.         public PropertyReference myProperty;
  7.         public PropertyReference secondProperty;
  9.         void Update ()
  10.         {
  11.                 myProperty.Set(secondProperty.Get());
  12.         }
  13. }


Class Documentation

If you have a question regarding this component or would like me to clarify something, just post a reply here.

NGUI 3 Documentation / UIKeyNavigation
« on: March 22, 2014, 08:46:10 PM »

UI Key Navigation component makes it possible to add keyboard and controller-based navigation to your UIs.

By default it's not possible to navigate the UI using keyboard, joystick or a 360 controller because without a touch or mouse input it's not immediately clear what should be receiving the events. To remedy this situation, NGUI treats the currently selected object as the object that will receive the events, and the Key Navigation component makes it possible to change the selection based on user input -- such as pressing arrow keys on the keyboard or using a thumb stick on the 360 controller.

To begin, simply attach the UIKeyNavigation component to the widgets that should respond to controller events. This generally means all your buttons, sliders, toggles, popup lists, etc. If your game is not meant to be controlled by mouse or touch, it's also a good idea to ensure that one of the navigation scripts has an active Starts Selected flag so that it becomes selected (and thus -- controllable) from the very beginning.

The script will automatically determine what should get selected when the arrow keys get pressed, selecting the next active object that has UIKeyNavigation attached in the direction of movement. If you want to restrict movement, use the Constraint field. "None" means no restriction on movement. "Vertical" and "Horizontal" limit the movement only to the axis of your choice. Setting the Constraint to "Explicit" will disable the automatic  detection altogether, and only the explicitly specified values under the Override section will be used.

Speaking of that, Override is what ultimately "forces" the value to be what you chose it. If an override value is set, that value will always be used regardless of the Constraint setting. So if you wanted to fine-tune the navigation on specific buttons to select something that may not be obvious to the system, you would do it by setting the appropriate override fields.

Last but not least, if you have a button that opens a new window on click, you may want to set the Select on Click field to a control inside that window so that the selection is moved accordingly. In the Controller Input example scene the "Options" button shows the Options menu and also gives focus to a button inside of it.


You don't need to set the Override fields unless pressing the key does not result in the correct widget being selected.

Class Documentation

If you have a question regarding this component or would like me to clarify something, just post a reply here.

The topic says it all. I'll be in San Francisco for GDC 2014 Monday through Wednesday, so support will be limited. Sorry guys -- but hey, if you're coming to GDC yourself, say hi!

NGUI 3 Support / Do you need Unity 3 support?
« on: March 13, 2014, 02:09:36 AM »
I just noticed that handles don't work properly in Unity 3. When I start resizing the widget, weird stuff happens. Turns out that this is because Unity reports the Scene View dimensions when querying game camera's pixelWidth and pixelHeight. It seems to be only a bug in Unity 3, but it got me thinking... who here still needs Unity 3 support?

I for one am pretty tired of all the #if UNITY_3_5, hack it, otherwise do something properly statements all over my code. I want to clean up all that stuff and officially drop support for Unity 3. But before I do that, I wanted your opinion. Do you still need NGUI to support Unity 3, or can I focus on Unity 4?

Misc Archive / Seeking a 3D Artist
« on: March 08, 2014, 12:39:55 PM »
One of my current side-projects seems to be taking me into a direction that involves creating modular spaceship parts, which would look much nicer if they were done by a non-programmer. And so... I am looking for a sci-fi artist that would be comfortable making various spaceship parts for a game set in the near future (~2050).

And just to clarify -- I'm not looking for entire spaceships. I am looking for modular parts that can be used to create spaceships instead. This means following a rigid set of constraints for the dimensions of the connecting parts. So if you are a freelance artist who would feel comfortable doing something like that... please get in touch and let me know your rates. :)

Misc Archive / Random Self-reflection
« on: March 03, 2014, 07:21:35 AM »
Have you ever had one of those days when you wake up in the morning thinking about something from years ago that you have all but forgotten about? Perhaps it was some event that you were particularly embarrassed about, or an opportunity you've missed, or just a person with whom you've been really close with but haven't spoken with in ages? And then one thing leads to another and you find yourself wondering how much everything has changed since that time long ago.

Yeah, I'm having one of those days.

Thinking back, I used to hold true to my belief that "people don't change". In fact it was my motto of sorts not long ago. And yet looking at myself today and comparing the "me" of today to "me" of years ago, I cannot deny a pretty noticeable difference. I remember years ago I used to write these epic novels on various topics -- mostly to myself, mind you... but now? I hardly have the time to look back and reflect. Days like today are now a rare breed.

I'll start with "today", as that's closer to what some of you may already know. Today I'm a fairly successful independent software developer with a messed-up sleeping schedule who is rarely seen at public events and gatherings. I'd even go as far as describing myself as antisocial. Some have said to me that I seem to have an abundance of patience to do what I do on my own for so many years and still calmly answer simple posts that basically ask me to teach the basics of Unity -- and I find that particularly revealing today as "patience" has never been my strong suit. In fact, the "me" from just 4 years ago was a blunt, arrogant and short-tempered person who has blown a fuse at stupid questions on more than one occasion. "What's a DLL?" another developer once asked me. That kind of stupid.

If you had told the "past me" that I would be dealing with similar questions on daily basis today, I would have laughed at the notion. In fact, when I started the whole NGUI ordeal, my friends were joking that they were giving me a maximum of one month before I flipped the desk. And yet, here we are, years later. But have I truly changed? I wouldn't say so. I would say I simply learned to deal with my short temper a little bit better. Not that well, mind you -- I still reply unkindly every once in a while to someone I perceive as being rude or purposely wasting my time -- but certainly better than before.

And speaking of something affected by perception, where does one draw the line between confidence and arrogance? After all, the difference between the two lies in knowledge. One is backed up by actual knowledge, while the other is backed up by mere pride. Perception further blurs the line, for someone with a short temper can easily come off as being arrogant simply because of unwillingness to expend time in order to explain the reasoning behind their statements. In the end, it's simply wiser not to insert one's self into conversations in order to "enlighten" anyone, as I've long ago learned. People will be wrong, but the life will go on. As it turns out it's always a much better idea to spend less time arguing and more time doing something productive anyway.

On the same note, I accomplish what I do by (mostly) working from home, which means I get very little interaction with the outside world. Many years ago I was a pretty social person. I was always outside dong something with friends or chased after girls -- you know, the typical guy stuff. Now that I'm older I find myself being able to count the number of friends I regularly stay in touch with by the fingers of a single hand. Many of my closest friends from years ago I haven't even seen in months. Some I've pushed away deliberately... but most simply drifted away on the winds of time. Some of them I find myself wondering about every so often -- those I've pushed away in particular -- but I never seem to reach out and reconnect. And I honestly don't know why. "Too busy" is the common excuse I give myself, and yet I know it to be a lie. It doesn't take much time to get back in touch. I've just never been good at it, I suppose. "Maybe some day they will contact me", I always think.


Maybe some day.

When requesting for help, DO NOT upload your projects containing NGUI's source code. NGUI's source code is not open source. The first time you do it I will simply remove the link and refrain from answering the offending post.

The second time you do it, you will get permanently banned from this forum and I will no longer give you any support.

I'm sorry to be harsh, but use some common sense, please. You'd feel the same way if I posted your proprietary work in a public forum.

If you wish to provide your project and/or example of some kind, either post it without including the NGUI folder, or send it to me via email instead (support at

Thank you!

NGUI 3 Documentation / Localization system
« on: February 14, 2014, 04:45:59 AM »

Localizing your game using NGUI is as simple as creating a CSV file with all your text and using the UILocalize component on your labels and sprites that you want to be localized.

NOTE: The CSV support was added in 3.5.0

The first step is creating the CSV file. You can use Google Docs, Excel, or any other application that's capable of creating excel style files.

The CSV file should contain two or more columns. The first column should contain keys that you will use in the Key field of the UILocalize component. Other columns should contain the actual localized values for those keys.

The first row should contain your language names -- English, French, Simplified Chinese, etc. When you want to switch a language in-game you can either use Localization.language = "English;" (or any other language defined in the first row), or just attach the LanguageSelection component to a drop-down list, turning it into a language selection list.

All other rows should contain the key in the first column and text values in all the subsequent columns. Just make sure that there are localized values present for all the given keys, or things may not work properly.

Once you're done, export the file in CSV file format as Localization.csv, and place it in the Resources folder. Unity 4 treats CSV files as Text files, but if you are still on Unity 3, you will need to rename that file to have a TXT extension or it won't be recognized.

To localize any label or sprite, attach UILocalize script to it and choose a key defined in the CSV file you created, and that's it! The label or sprite's value will be pulled from the localization file automatically, and when you switch languages, so will your label or sprite.

Pro-Tip #1

If you don't remember what your key was, just start typing in the UILocalize's "key" field. It will bring up a list of relevant entries for your convenience. Click on one of them to choose that value. Likewise you can click on the Preview options to have the localized object immediately assume that value.

Pro-Tip #2

If you are doing custom localization, you can still use the localization system. Use Localization.Get(key) anywhere in code to retrieve a localized value for the current language. To change the language -- Localization.language = "New Language";

Pro-Tip #3

Want even better localization tools? Have a look here --

Class Documentation

If you have a question regarding this component or would like me to clarify something, just post a reply here.

NGUI 3 Support / Limited support January 9th to 16th
« on: January 08, 2014, 02:15:53 PM »
Wife said she needs a vacation and for some reason I have to tag along. :(

So... I'll be on a beach in Jamaica for a bit. I'll bring my laptop, and the resort should have Wifi... but chances are high that the support will be quite limited during that week.

My apologies!

NGUI 3 Documentation / UIRect
« on: December 06, 2013, 06:09:05 PM »

UIRect is the base component that both Widgets and Panels derive from. You won't be able to create it as a component it as it's an abstract class. Instead, create a Widget or a Panel if you want something tangible.

Video that shows the different anchor types in action:

All NGUI elements that have a modifiable area can be anchored to other elements or even 3D objects. When choosing an anchor point, you can decide whether you want all sides to be anchored to the same object, or different ones. Choosing Unified will give you one option, while going with Advanced will give you one per side.

To anchor a widget, move it in the desired position, choose one of the presets, and drag & drop the Target you want it to be anchored to. The anchor's values will be filled in automatically.

To set up a widget inside to always be "inset" in another widget, make it a child of that widget then choose the Unified option. The target widget will be picked up automatically and the initial values will be filled in for your convenience. You can then further adjust the widget either in the scene view like you normally would, or by modifying the options.

Each side is anchored independently of the others, and for each you get to choose which of the 3 preset anchor points it will use. For example for Left and Right, they are Left, Center, and Right. If neither suit your needs, choose Custom and set the values yourself.

Custom setting gives you a Relative value to work with. This value is relative to the target's dimensions, and as such will only be selectable when you are targeting another widget or a panel as the Target.

With a Left or Right anchor, 0 means left, 1 means right, and 0.5 means right down the middle. 0.25? 25% of the target's width from the target's left.

Choosing "Set to Current Position" will simply set the anchor point to where the side is currently positioned, making the offset be zero.

If you want more control, or if you want to anchor only specific sides, then Advanced anchor type is what you should go with. With Advanced mode you can specify unique targets for each anchor point, effectively controlling which sides will be adjusted by the anchors, and which ones will remain as you left them. In the picture above I did just that for the slider's thumb: I chose padded anchors for the Top and Bottom, making them resize as the slider's height changes, but I left Left and Right as None. This means that resizing the slider horizontally won't affect the thumb.

You can examine this further by dragging in the Simple Horizontal Slider control into your scene and selecting its thumb.

Last but not least, you don't need to specify widgets or panels as the Target. You could also specify a random game object of your choice in order to make the UI widget follow it. If your rectangle is on a widget, you can also make it automatically hide itself it it detects that it's no longer visible. Since the alpha is cumulative, doing so will automatically affect all of its children.

Class Documentation

If you have a question regarding this component or would like me to clarify something, just post a reply here.

NGUI 3 Documentation / UIScrollView
« on: November 23, 2013, 08:49:55 AM »

A clipped UIPanel is not complete unless it can be dragged around like a scroll view, right? Right!

Turning a panel into a Scroll View is a short 3-step process.
  • First, select the panel you want to be your scroll view and right-click anywhere in the Scene View to bring up the context menu, then choose Attach -> Scroll View.
  • Now that you have a scroll view, choose its rectangle by dragging the purple handles just like you would choose the widget's rectangle.
  • The last step is to add the UIDragScrollView script to at least one collider. Again, select the collider, right click in the scene view, Attach -> Drag Scroll View (it will be on top if you've followed the previous steps).

Note that if you have more than one collider, then you will need to add Drag Scroll View script to all of them that the user will be able to press on. So for example if you have a scroll view like in the Scroll View Example where you have a background area and a bunch of items inside it, then you will want to add the UIDragScrollView to the background as well as each of the children. The idea behind it is simple: every collider that can intercept the event should be capable of dragging the scroll view.

Note that the context menu-based approach is context-sensitive. So if you right-click on a widget that doesn't have a collider, you won't be able to see the drag scroll view option.

On the scroll view script you have several options for you to tweak. First comes the Content Origin that's used to specify where the scroll view's content will originate.

Next comes the Movement that lets you choose whether you are making a Horizontal or a Vertical draggable panel. You can also choose Unrestricted movement which will let you drag the content around freely. If you want some custom movement, you can set the field to Custom and set your own X and Y values.

The Drag Effect option controls how the scroll view behaves when you drag it around. MomentumAndSpring is the default iOS-like behaviour.

If you want the scroll view to be scrollable with the mouse scroll wheel, play with the Scroll Wheel Factor value. Note that you can specify a negative value such as -0.25 if you want the mouse wheel scrolling to be inverted.

Momentum Amount controls how the scroll view behaves when the user lets go of the drag mid-swing (swiping gesture). Tweak this value to make it more or less sensitive based on what you desire.

In most cases you will want to have Restrict Within Panel option left turned on, as this is what will prevent your scroll view's content from leaving the scroll view's region. In case you haven't guessed it already, the dimensions of the scroll view's content should already be outlined by the orange color in the scene view.

Cancel Drag If Fits option will prevent the content from leaving the bounds at all. If left off, it will be possible to drag the content outside the bounds, but there will be visible resistance in doing so.

Smooth Drag Start and IOS Drag Emulation options further tweak the behaviour of the scroll view script, and in most cases you will just leave them at default values.

If you have a Horizontal or a Vertical Scroll Bar, you can specify them in the appropriate fields. Once done, you can also choose what happens to the scroll bars when they are not needed by adjusting the Show Scroll Bars option.


In NGUI 3.5.5 and earlier versions, a scroll view will only clip the widgets directly underneath it. If you nest scroll views, the clipping will not be nested. Only one scroll view can clip the content inside of it. NGUI 3.5.6 lifts this limitation, provided you stick to using an NGUI's shader on your atlas such as Unlit - Transparent Colored.

Pro-Tip #1

It's best to leave the Scroll Bars Show Condition at OnlyIfNeeded so that your scroll bars will get automatically hidden until they are actually needed.

Pro-Tip #2

If you want to create an Endless Scroll View, attach a UIWrapContent script underneath it like so:

Class Documentation

If you have a question regarding this component or would like me to clarify something, just post a reply here.

Pages: 1 2 [3] 4 5 ... 10