Messages

1

NGUI 3 Support / Re: Button Hover-Off, Hover-On Bug

« on: April 22, 2015, 02:54:57 PM »

Changing it to OnPress would remove the user's ability to drag off and cancel the input, which is something they might be used to after using standard PC interfaces. I'll probably modify the part where it reacts to OnDragOver - is there a quick way to have it cancel the touch if no longer on the button itself, but still activate if the touch comes back over the button?

Also, generally how do you feel about my first comment - that its perhaps misleading/unintuitive that the button still gets depressed even though it's not going to activate after a drag-off-drag-on?

2

NGUI 3 Support / Re: Button Hover-Off, Hover-On Bug

« on: April 22, 2015, 02:25:58 PM »

Hm - I can understand the reasoning behind the functionality. I think the visual is flawed then - it feels like the button shouldn't change to it's pressed state again when you drag back onto it. It sends a visual signal that I'm ready to be pressed, and then feels like a bug when it doesn't perform it's function. I associate the pressed state with "I'm about to do the thing I'm supposed to do."

Additionally, I wonder if it's contributing to a bug I'm seeing - users will press a button and occasionally have it not do anything, despite the pressed state being shown. At first I thought the collider was shrinking with the UIButtonScale script, but I wrote a separate one that doesn't and I still see the issue. Could it be that with a button that's just small enough, a drag operation is triggered by the incident sliding of the finger when you tap the button with too much force?

It makes it pretty frustrating for users to get around some of my buttons. Obviously I can make them bigger and hopefully that address the issue, but it doesn't seem like the way it should work - not to mention if they pressed the button near the edges, they might still run into the issue if their finger slides off the edge of the button unwittingly.

3

NGUI 3 Support / Button Hover-Off, Hover-On Bug

« on: April 21, 2015, 05:59:24 PM »

NGUI seems to not register button clicks if I hold down, move my mouse/touch point off the button, and then back on and release.

Video for illustration:

https://www.youtube.com/watch?v=jb3Pl-ROXX0

Is this intended behavior? Because it feels like a strange bug to me.

Thanks

4

NGUI 3 Support / Unity 4.5.5p3 Weirdness

« on: November 07, 2014, 04:31:54 AM »

Hey, I just upgraded to Unity 4.5.5p3. I used to be on p2, and NGUI worked fine. I'm on the latest NGUI from the repository. Now, I see this weirdness:

When in Editor Mode:



When in Play Mode:



Any idea what's going on there? Makes it kind of tough to edit. Some widgets are fine, but there are two containers that despite their anchors show a 2x2 size. Pressing play pops their size and position to the right place.

5

NGUI 3 Support / Re: Button Scale Affects Collider

« on: October 01, 2014, 07:01:19 PM »

Another note - you can tell it happens because although the button stays scaled, the color reverts back to a non-pressed color.

6

NGUI 3 Support / Re: Button Scale Affects Collider

« on: October 01, 2014, 06:58:39 PM »

NGUI 3.6.3. Might be a little risky to at this stage in the project; though I would if it fixed this. UI Root set to Fixed Size On Mobiles. Standard UIButtons with UIButtonScale script on them. Testers keep trying to press buttons on the edge of collision at which point it drops out and doesn't register as a press.

7

NGUI 3 Support / Button Scale Affects Collider

« on: October 01, 2014, 05:28:06 PM »

UIButtonScale seems to affect the collider's scale as well. This results in issues where the scaling causes the collider to no longer be under the finger and the touch gets thrown out. Is this something that you're aware of?

8

NGUI 3 Support / Re: UIRoot Position Bug

« on: July 08, 2014, 02:47:43 PM »

Yup, whatever you did fixed it. My camera wasn't outside the root, but doesn't matter now!

9

NGUI 3 Support / Re: UIRoot Position Bug

« on: July 07, 2014, 10:42:17 AM »

Maybe try my settings / version?

10

NGUI 3 Support / Re: UIRoot Position Bug

« on: July 07, 2014, 02:04:21 AM »

You're on Unity 4.5.1 with your build settings set to iOS?

11

NGUI 3 Support / Re: UIRoot Position Bug

« on: July 06, 2014, 06:28:16 AM »

I did your three steps, and it worked fine. Then I changed the Scaling Style to "Fixed Size On Mobiles" and it started happening again. So there you go! Diagnosed.

12

NGUI 3 Support / Re: UIRoot Position Bug

« on: July 05, 2014, 01:40:53 PM »

I'm honestly not sure what else. It's a blank scene minus some scripts to instantiate objects on runtime. Here's the inspector for the UI Root object and the UI Camera. Beyond that, it's an iOS project in Unity Pro 4.5. If there's any other information I can give you, or if there's a specific place in code where you draw the box and you'd like me to do some debugging, let me know.

13

NGUI 3 Support / UIRoot Position Bug

« on: July 03, 2014, 11:54:53 PM »

Hi there,

I'm on the latest version from the repo (ec92cfa). I seem to be getting a bug where moving the UI Root vertically causes the magenta visualization rectangle in the Scene to become offset from the actual root.

GIF for clarity:

14

NGUI 3 Support / Layout System: Pixels vs Percentage

« on: June 10, 2014, 04:42:16 PM »

Hi there,

We're in the process of setting up our screens and are running into some layout system issues. The promise of the system, if I understand it, is that screens can be built in a way that makes them resolution independent (i.e. portrait, landscape, super-tall, androids, iphones, tablets, whatever) and that widgets can be positioned and scaled relative to each other.

The issue we're running into specifically is that the layout system by default uses pixels to define offsets from targets. This means that when we're setting up a layout in portrait mode, and then we switch to landscape mode, the UI is incapable of handling the change in height because it's trying to respect the pixel offset from the anchor.

We were able to get around this by using the Custom setting, which lets you specify a % of the target's height. The issue is now that none of your tools for resizing or moving widgets respect percentage settings. Moving or resizing a widget in the scene will start to add pixel values to the anchor, which then screws up the layout on different resolutions.

Example:

Original:


Using Pixel Anchoring:


Using Custom / Percentages:


This is the anchoring of one of the buttons:



In order to have them positioned correctly and scale correctly when in landscape mode (i.e. for their widths to stretch but their heights to not overshoot the vertical space of the screen), we had to use % instead of pixel values.

This is really hampering our ability to make layouts, because it means that every widget must be sized and positioned using numbers in the inspector, as opposed to the handles. It feels like NGUI should support both pixel and percentage anchoring - and the handles we use to resize widgets or reposition them should be able to affect both pixels and %, depending on what the anchor is set to.

How did you create layouts with just pixel anchoring? Is that truly the right way of doing things? And if not, please please add % support ASAP - we're in production and could really use handles that change the %, not the pixel offset.

15

NGUI 3 Support / Re: Buttons Stopped Working After Upgrade

« on: May 29, 2014, 01:04:46 PM »

Some debugging reveals that in UICamera's Raycast function, this code is perhaps causing problems?

1.                                 for (int b = 0; b < hits.Length; ++b)
2.                                         {
3.                                                 GameObject go = hits[b].collider.gameObject;
4.                                                 UIWidget w = go.GetComponent<UIWidget>();
5.  
6.                                                 if (w != null)
7.                                                 {
8.                                                         if (!w.isVisible) continue;
9.                                                         if (w.hitCheck != null && !w.hitCheck(hits[b].point)) continue;
10.                                                 }
11.                                                 else
12.                                                 {
13.                                                         UIRect rect = NGUITools.FindInParents<UIRect>(go);
14.                                                         if (rect != null && rect.finalAlpha < 0.001f) continue;
15.                                                 }
16.  
17.                                                 mHit.depth = NGUITools.CalculateRaycastDepth(go);
18.  
19.                                                 if (mHit.depth != int.MaxValue)
20.                                                 {
21.                                                         mHit.hit = lastHit;
22.                                                         mHit.go = lastHit.collider.gameObject;
23.                                                         mHits.Add(mHit);
24.                                                 }
25.                                         }
26.  

Although the loop goes through all the proper game objects and "go" becomes the backing and the button and whatever else we hit, the line

1.                                                         mHit.go = lastHit.collider.gameObject;

causes only the backing to get added to the mHits array over and over again.

So by the time it gets to the sort line below that block, the mHits array just has multiple instances of the backing in it, and none of the other widgets got added.