(!!!) Improving NGUI: Voice your opinion

[dominus85]

I subscribe to the UIGrid with pivot point.. very useful for mirrored ui's

[jingato]

1. HD & SD Atlas building:  It would be nice to give the atlas make the option to build 2 atlases, and HD and an SD version. Right now I have to build the HD version and then duplicate the generated version and manually re-size it. I have to do this every time I rebuild the atlas so it would be nice it NGUI atlas maker could do that atomatically.

2. I really big thing I would like is a filled sliced sprite. That is, a sliced sprite that also has the same ability as a filled sprite.

3. Some type of markup system to allow you to change the font or make it bold, italic, change size, etc, all in the same label

4. Data binding

5. As I mentioned in an earlier post. Ability to use parameters in button events.

Thanks! and can't wait for uGUI!

[Holdwick]

I've got a feature request for ya.

In our game we've implemented a custom input system so that we can use many types of input(keyboard, joystick, xInput), along with player specific input.  This also includes redefinable keys, and restricting menu input to a single player.  NGUI's current input setup, specifically with GetDirection, Confirm, and Cancel in UICamera, are not quite customizable enough.  For example, you cannot bind an axis, like gas pedal, to confirm.

What would be really nice for this is a way to accept custom input, perhaps through an interface.  That way I can deal with which player is active and what device they use, and send that input to the UICamera.

Something along the lines of:

1. interface ICustomInput
2. {
3.         void GetDirection (ref int vertical, ref int horizontal);
4.         bool MenuCancelClicked ();
5.         void GetMenuConfirmState (ref bool submitKeyDown, ref bool submitKeyUp);
6. }
7.  

Would work splendidly.
Thanks!

[Isamson]

First off, I just want to say thanks for all the latest updates. Here's my request:

We are currently working on a project that is controller input based and I would really appreciate if the "Draggable Panel" could use an index input to display an element within the uiGrid or uiTable nested inside a clipped Panel. What I'm looking for is to generate a list of items, for example, and be able to provide the index of the item so that the list would scroll to that specific item. Being able to set a scroll speed would be nice.

Another option could be to set a headspace for the scrolling. Let's say I have a list of 7 items and only 5 can be displayed due to the clipped panel size. The panel would not scroll until I reach item 4. From there, if I select item 5, the panel would scroll up 1 item to display items 2 to 6.

Example:
                  item 1
------         -------
item 1         item 2
item 2         item 3
item 3         item 4
item 4         item 5
item 5         item 6
------         ------
item 6         item 7
item 7

[ArenMook]

Have you seen UICenterOnClick? It has all the logic you need inside of it.

[Dethanos]

Could buttons automatically have their colliders resized if the button's background size has changed, i.e. when the screen size is changed.

[ArenMook]

If the button is on a widget, yes. Widgets have the option to auto-resize their collider. If you put UIButton on an empty game object then no. Check the provided button controls that come with NGUI.

[dominus85]

When editing a value why not use the up/down arrows to make adjustments to that value? this would allow for perfect placement without having to type all over again the number

[jaz1974]

CLEAR EXPLAINATIONS OF EACH FEATURE, AIMED AT NON-PROGRAMMERS

Without any doubt the biggest improvement you can make (if you want to increase the user base), is to re-write the documentation so that it can be clearly understood by a NON-programmer.
It's fairly clear you are an extremely competent programmer.
However, I'd assumed that the main target audience for NGUI was those who cannot write code, or have limited programming abilities.  After all, those who can program effectively will be able to do most of this stuff for themselves.

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.

You may well find you spend a lot less time explaining things to people on this forum, if you take the time to explain ALL the features of NGUI in a manner which can be understood by someone with a creative mindset.

Personally, what I'd find very useful is a scenario in which you might use each of NGUI's functionality.
I'm assuming everything that you've added, was added with at least one use in mind.

E.g. UIAnchor - explain why its there and what its useful for in non-programming terminology.   Rather than just explaining how the code works.  That's not all that useful for a designer.

Without doing this, I suspect you are selling yourself short.  There's a lot of cool things in there that are probably not being used to their full potential as they are difficult to understand.

I'd also strongly suggest creating more youtube videos showing how, where and why you'd use certain components in certain situations.

Jaz


Update :   Hah!  I just discovered your video for the new Anchoring system.   Spot On!  More of these please!

[bac9]

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

[gyd]

hi,
About ScrollView
Is it possible to create a "loop" scroll view, for example:

|123|456 => 12|345|6 => 12345|612|
|<->|             |      |               |     |
  items in view

[jaz1974]

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.

Think you may be misunderstanding my point.
When I say words like 'Class' don't mean much to a lot of people....I mean they shouldn't be used.  Not that they should be explained.
If NGUI is to become more user friendly (which is what I'd expect to be one of it's core values), then the documentation should be aimed at people who don't understand programming; as well as those who do.
I'm glad to see that, with the new videos explaining the functionality of the new feature set, the NGUI guys are doing exactly that.
Not everyone cares about how a car engine works.  Some people just want to know how to drive it.

If Playmaker requires an understanding of how code works, then that's it's failing. 

I've worked in the video games industry for 15 years as a designer and have seen all kinds of toolsets.
I realise that as systems get more complicated and detailed, it unavoidable at some point you're going to get involved in something that looks like programming.  One thing I can say without exception is that all of the tools I've used have strived to avoid this wherever possible, so that the creative side of things don't get bogged down with the technical parts.

Give any designer the option of having to get involved in programming something, or being able to get on with designing something....they'll choose the same one every time.  Otherwise, they're a programmer masquerading as a designer. 

[505083367]

1 can have an option in widget that ignore it when calculate bounds.  i have some effects in clip panel, when i reposition the panel, the panel clip will scale to the size include those effects, this is not what i want.

2 3.0+'s raycast is using depth. so i think is there any possibility the raycast depend on sprite's pixel alpha which position i clicked on, and then i don't need add some mesh collider to my irregular sprite button.

3 UIRoot scale base on height.  but it's necessary have an option base on width or base on both(internal or not), like  UIStretch.

[Yukichu]

After some consideration, I do have a request for improvement...

The ability to chose an imported sprite to be a "Diced Sprite" in the atlas.  I (and I would think possibly others) have some large sprites that could be reduced in size considerably if they were diced.  Creating a sliced sprite out of them won't really work, so they are currently like 256x256 or larger sprites in my atlas (UI outlines that look very specific and cannot be sliced.)

Yeah, like most everyone else in here my response is, "Improving NGUI means improving my project specifically!"

If this feature never happens, I'll be fine.  It would be nice though and save some considerable space on the atlas size at the expense of a few more triangles.

[jaz1974]

1.  The ability to drag objects out of a scrolling table.

...maybe its already there?  Wasn't the last time I looked.  Would be great if it is.