Topics

1

NGUI 3 Support / UIRoot and static GameOjbect children

« on: January 10, 2017, 01:51:53 PM »

I"ve been learning about GameObject.static. From what I read, since UIRoot scales the entire gui heirarchy (when using pixel perfect...), is it then true that I should never have a static Gui element underneath UI root, aka all Gui element game objects under UIRoot should be non-static?

2

NGUI 3 Support / UIPopupList Set Bug?

« on: September 16, 2016, 02:24:12 PM »

I just updated from 3.9.6d to 3.10.1 and immediately started seeing an issue with UIPopupList having a null [selected]value. I think this happened when you added the optional ability to not trigger a callback in Set(value, notify = true). In this new Set(), if mSelectedItem should be changed, you change it, determine whether to notify, then set mSelectedItem to null, aka after using value_set or simply Set(), value is set to null right after TriggerCallbacks(). This last part of setting mSelectedItem to null wasn't present in 3.9.6d. Is this intended? If so, the only time value has its assigned value rather than null is during the callback, assuming the client chose to trigger it. If they don't choose the callback, value will always be null... Obviously I'm confused by this, but I do know that PopupList.value is always null except during the callback. As I use PopupList alot, I'm dead in the water right now.

As an aside, in both sets of code, you test for mSelectedItem being null after being assigned value and return if it is null which makes sense to me. However, when testing notify, you again retest mSelectedItem for null which it can never be. No harm done, but just thought you would want to know.

3

NGUI 3 Support / UICamera.onHover

« on: February 07, 2016, 09:12:30 AM »

I'm finding circumstances where multiple OnHover(true)s are received on the same object without an intervening OnHover(false). Is this intended?

It is coming from UICamera.ProcessRelease() where your comments suggest you are trying to "restore the visual state of the object", implying of course that an OnHover(false) has already been called and now needs to be restored back to true. This multiple trues in sequence occurs when I click on an object, aka ProcessRelease().

I notice you've commented out sending OnHover(false) from selectedObject.set. The only places I now find it is hoveredObject.set and controllerNavigationObject.set.

I'm guessing this is unintended as I seem to remember encountering a similar issue about 2 years back which you then fixed. :-) Please clarify.

I've been using Ngui now for about 4 years. Wonderful product. Thank you.

4

NGUI 3 Support / UIPopupList onChange EventDelegate

« on: June 10, 2015, 04:18:18 PM »

I've noticed that the onChange EventDelegate for UIPopupList is fired whenever UIPopupList.value is set, even if it is set to the same value it currently holds. Shouldn't that be limited to firing when the value is changed, not just set?

I'm using 3.9.

5

NGUI 3 Support / BoxCollider2D verification and UIRoot scale

« on: November 26, 2014, 03:55:29 PM »

I've just encountered something unusual and would like to get your thoughts on way forward.

I've got buttons on my UI. I like to keep them relatively small - 20 -25 pixels square or so. They have 2D BoxColliders on them which are resized automatically depending on the widget's size. WHen I recently pushed MaximizeOnPlay to demo the UI, I found I could no longer detect these small buttons. It turns out the collider posted a warning in the collider inspector saying the physics engine had failed to validate it because it was too small. My screen height was 1040 (1200 less UnityEditor menu bars, etc.) and UIRoot's scale (flexible style as I'm on Windows and Mac platforms) was 0.00192307 which all makes sense.

After some experimentation, it seems that these colliders, when UIRoot reduces its scale to the value above, need to be a minimum of about 27-28 pixels in both x and y in order to validate.

Now of course I can simply increase the minimum size of all my sprites that contain colliders, but that seems like a temporary hack. Before I go down this route, I'd like to know your thinking on how this might be dealt with more systematically, assuming of course that you have encountered it before. I have found nothing in the forums to date on this, except acknowledgement in Unity that colliders can be too small and not validate.

6

NGUI 3 Support / onPress delegate gameObject null

« on: November 08, 2014, 02:53:32 PM »

I've just encountered a situation where the gameObject sent with the onPress delegate can be null even with a gameObject assigned as the fallthrough. While I can filter it out, I wanted to mention it as it could be a bug unless intended to operate that way. Looking at the UICamera code, I can see you choose to send out a onPress(false) before sending a onPress(true) which clearly is intended. (Not sure why, but I am sure there is a reason  ). I'm seeing the null gameObject when the initial onPress(go, false) is raised.

7

NGUI 3 Support / Visibility Changed delegate?

« on: October 04, 2014, 03:35:22 PM »

I'm looking for a way to be notified when a widget or panel transitions into/outof camera line of sight like MeshRenderer.OnBecameVisible/Invisible does for meshes. As UISprite doesn't use a MeshRenderer, I don't have that notification available to me.

8

NGUI 3 Support / UISprite and Anchoring

« on: September 26, 2014, 02:47:41 PM »

I'm trying to anchor a UISprite in the UI Layer to a gameObject on a world layer in code. I've successfully done this with UILabel using SetAnchor(gameObject). In that case, I relocate the label to the same location as the world object, setting z to 0, then call SetAnchor(gameObject), followed by ResetAndUpdateAnchors(). This results in the proper unified offsets and the label in the UI layer follows the gameObject.

Doing the same thing with a Sprite has me stumped though. The 32x32 sliced sprite resizes to 2x2 (smallest possible I know) as a direct result of SetAnchor(gameObject) being called. As a result, the anchor offsets are all zero (which makes sense, given such a small sprite). I can see the now tiny sprite is in the right position, but it is too small to be useful. Interestingly, calling MakePixelPerfect() after this increases the sprite back to 32x32, but propels it to never-never land, aka enormous offsets. It is now the right size, but way off the screen.

The gameObject itself is simply an empty child GameObject of my real moving target which acts as a relative offset positioned where I want the label/sprite to be anchored.

Thanks for your excellent support. I always spend a few hours myself trying to figure these things out reading other threads before I ask.

As an aside: I can tell the anchoring system is extremely powerful and flexible, but it has a pretty steep learning curve, at least for anything more than basic concepts.

9

NGUI 3 Support / UICamera.current vs UICamera.currentCamera

« on: September 17, 2014, 11:52:50 AM »

I have a Camera2D limited to the UI layer, set to orthogonal with depth = 1. It has a UICamera script with the eventType set to 2D UI and an event mask also limited to the UI layer.

I also have a MainCamera that excludes the UI layer, set to perspective with depth = -1. It also has a UICamera script with the eventType set to 3D World and an event mask that excludes the UI layer.

When I click on a 3D gameObject (not on the UI layer), I print out UICamera.current.name, UICamera.current.eventType and UICamera.currentCamera.name.

I get back, in order: "Camera2D", "2D UI", and "MainCamera". I was expecting MainCamera, 3D World and MainCamera. Shouldn't UICamera.current be the mainCamera's UICamera that can see the gameObject, rather than the Camera2D which can't? How can UICamera.current and UICamera.currentCamera refer to 2 separate cameras immediately after an event is received?

EDIT: I've also now printed out the event mask from both UICamera.current and UICamera.currentCamera yielding respectively: UI layer only, and other layers excluding UI. This seems to confirm that the event must be coming from the MainCamera, even though UICamera.current returns Camera2D.

10

NGUI 3 Support / UICamera Event occlusion

« on: September 11, 2014, 10:54:59 AM »

I have a mostly transparent plane with a trigger collider in 3D space that I use to detect onScroll events, allowing me to scroll in/out to/from it. It has no other purpose besides this.

There are other 3D gameObjects with colliders behind the plane that I want to be able to detect onClick/onSelect/onHover, etc. As is right now, the plane collider intercepts these events, but does nothing with them of course. The only way I've been able to figure out how to get the gameObjects behind the plane to get the onClick/... event is to detect it on the plane, then do a raycastAll to see if another object is behind the plane where the cursor is located, then relay the event to that object.

While this will work, I wanted to ask whether you know of another way to accomplish the same thing with the event system that would avoid needing to repeat a raycast?

EDIT: Looking for further insight, you've mentioned in the past that for Windward you exclusively sent all events to the fallThrough (mask = nothing) and then sent them where you wanted them to go from there (using UICamera.Raycast and UICamera.Notify I presume), thereby allowing some routing judgement (like I'm referring to above) to be applied before forwarding them. In looking at the UICamera code, doesn't that result in 2 slow SendMessage() calls for EVERY event?

With your addition now of event delegates, have you changed the approach any? I guess I'm looking for insight into how to use the event system for best performance as you add more flexibility to it.

11

NGUI 3 Support / Feature Request: PlayAnimation Mouse Button selection

« on: September 08, 2014, 10:24:32 AM »

I'm using PlayAnimation on a number of buttons to bring up new menus. I only want a left click to activate the animation, not any click. Would you consider adding a mouse button distinction setting on this script, and/or more generally across other applicable scripts?

Currently, the only way I've been able to handle it is to write my own MyPlayAnimation with the filter built in. Obviously this has limits as PlayAnimation gets updated.

12

NGUI 3 Support / Scroll and OnClick events

« on: August 25, 2014, 04:27:11 PM »

I've just updated to 3.7.1 and am trying to change to using the new generic delegates now that genericEventHandler has been deprecated in favor of said delegates. This is proving challenging...

In the case of onScroll, I'm finding that the delegate is only raised when there is a gameObject underneath the cursor, aka mHover != null. Previously, with the genericEventHandler field assigned, the OnScroll event was passed to the genericEventHandler whether or not there was a gameObject underneath the cursor. If there wasn't, the genericEventHandler gameobject was assigned as the gameObject. Thus there was an event for every user scroll action.

A similar situation seems to be present with onClick, where the delegate is raised only when there is a gameObject underneath the cursor...

While I think the fallthroughEventHandler could be used to fill in for the delegate not being raised, wouldn't it be better to have the delegates raised for all user mouse actions with the gameObject set to null when not over a gameobject?

This way we could always rely on the event occurring and test for the presence or absence of the gameobject.

13

NGUI 3 Support / Widget.size

« on: October 11, 2013, 01:48:53 PM »

I've just successfully converted my project from Ngui 2.7 to 3.02 and am now working on sprite scaling. Using 2.7, I was scaling a sprite on a billboard attached to a 3D gameobject using transform.scale. As the camera distance changed, the sprite size adjusted (via transform.scale) to retain the same footprint on the screen. All well and good.

Now with 3.0 I've started using Widget height and width. When I scale height and width the sprite does enlarge/shrink as a function of camera distance, down to 1,1. Unfortunately, the sprite is too large at 1,1 when I zoom up close. Of course I can't go lower in height and width, so I figured my sprite was just too large to start with, so I tried a much smaller one and it makes no difference at 1,1 when zoomed close. It is the same size relative to my objects up close as the larger sprite. I must admit I don't understand why.

I finally was able to get the image small enough when zoomed in by scaling the transform like I was doing in 2.7, although I thought that wasn't supposed to work anymore.

The bottom line of all this is I want to scale a sprite as a function of camera distance, thereby retaining the same 'visual footprint' on the screen. The problem is I can't go below 1,1 whereas with 2.7 using transform.scale I could. How would you accomplish this objective with 3.0? I'd prefer not to have to manipulate BOTH widget height/width AND transform.scale at the same time...

14

NGUI 3 Support / UICamera EventReceiverMask

« on: September 24, 2013, 01:55:10 PM »

I've entirely adopted the NguiEventSystem for my project which has been great. Thanks for that!

I'm now facing a situation on my main camera where I've got colliders from one layer covering up colliders from another, yet I need to have each able to receive events concurrently. The main camera sees both layers.

I'm wondering the best approach to take - 1) place two UICamera scripts on the main camera with the event receiver mask set to Layer A or B respectively (this works so far), 2) create a second camera slaved to the first, targeted at Layer B holding the second UICamera script, or 3) dynamically change the MainCamera's UICamera.EventReceiverMask programatically between the two. The last of course means that the two collider types can't be receiving events concurrently but I might be able to get away with this by changing the game criteria.

Which of these in your opinion, given your knowledge of the Ngui system, is the least problematic approach? Thanks for the advise.

15

NGUI 3 Support / UICamera.isDragging bug?

« on: September 02, 2013, 10:10:25 AM »

UICamera.isDragging is defined in the documentation as "Set to 'true' just before OnDrag-related events are sent (this includes OnPress events that resulted from dragging)."

From my testing and code inspection, there appears to be a case where this is not accurate. When a drag starts and ends over the same object, isDragging is false when OnPress(false) occurs on that object after the drag.

isDragging is true when OnPress(false) occurs on an object that is not the same object as the drag was started on, and during all OnDrag events.