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.


Messages - Maxii

Pages: 1 2 [3] 4
31
NGUI 3 Support / Re: UILabel won't resize freely when anchored
« on: August 29, 2014, 09:15:45 AM »
I'm now adopting the new anchoring system and am encountering this issue. I want to anchor a label with a background to the screen, and I want the label (and the background) to resize freely.

What hierarchy (label, background, anchoring and envelopConent) would you suggest using to accomplish this?

32
NGUI 3 Support / Re: Scroll and OnClick events
« on: August 29, 2014, 06:43:15 AM »
Thanks for sticking with me.

I've solved my issue by directly assigning fallThrough to a known, non-UI gameObject (my main camera). This makes sure all events are raised. I then subscribe to the events I'm interested in and, after confirming !isOverUI, test to see if the provided gameObject is the fallThrough. This gives me what I'm looking for - eg. an unconsumed click, a scroll, etc.

33
NGUI 3 Support / Re: Scroll and OnClick events
« on: August 27, 2014, 03:08:38 PM »
Thanks for the explanation. I've indeed confirmed that your stopgap Start() change does result in regaining visibility to all events via the delegates, just like the genericEventHandler approach I relied on. Of course, I know you are aware that other issues pop up:

- With multiple cameras, there are multiple camera gameObjects,
- If the camera gameObject is the 2DCamera, isOverUI returns true even if the cursor is not over the UI,
- Setting fallThrough to a default value in Start breaks the [now deprecated] genericEventHandler functionality that relies on fallThrough being null, etc

As you recommended, a couple of years ago, I adopted the Ngui event system and now use it exclusively. I based my UI on having visibility to all events where I analyze them and then route them to where they should go. GenericEventHandler (or Fallthrough with a nothing mask) provided this visibility. This is what you were recommending at the time.

I would like to track your change to delegates, but losing visibility to some events breaks my UI.
I would like to request that you provide some mechanism to use delegates without losing visibility to events that used to be visible.

34
NGUI 3 Support / Re: Scroll and OnClick events
« on: August 26, 2014, 02:15:14 PM »
Thanks for the reply, but I'm confused.  ???

How does assigning the unassigned fallthroughEventHandler field to the camera's gameobject result in all onScroll/onClick events raising a delegate whether or not they are over a gameobject?

What I'm trying to get back too is the genericEventHandler behavior where every user mouse action (scroll, click, etc) generates an event whether or not the cursor is over a gameobject.

35
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.

36
NGUI 3 Support / Re: Widget.size
« on: October 13, 2013, 11:33:45 AM »
Yes, that is what I concluded also. I'm afraid I got confused listening to your comments on the video when talking about local scale. Also, transform's scale display in the inspector is 'greyed out' in 3.02, implying that one shouldn't use transform.scale..., or at least that is how I read it.

Thank you for your timely support as always.

37
NGUI 3 Support / Re: Widget.size
« on: October 12, 2013, 05:33:35 PM »
UISprite/Widget width and height are ints aren't they? I'm getting the feeling I'm missing something pretty simple here... :-\

38
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...

39
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.

40
NGUI 3 Support / Re: UICamera.isDragging bug?
« on: September 04, 2013, 05:10:25 AM »
Yes, that was my reading of the code too. The reason I thought it was a bug/oversight is that the OnPress(false) event (over the same object) is "a result of dragging" too, not just the one that occurs when the object is different.

As you are the man here, I'll of course go whichever way you choose to call this. Making my own boolean isn't too difficult. :-)

41
NGUI 3 Support / Re: UICamera.isDragging bug?
« on: September 02, 2013, 08:23:56 PM »
Thank you for the timely reply on Labor Day!

isDragging is public and I'm using it per the documentation to determine whether the OnPress(false) is occurring at the conclusion of a drag event. If it is, then I don't want my context menus (Contextual) to open up. As it is now, they will open if OnPress(true) and OnPress(false) occur in sequence over the same object, even if it was a drag that was going on between the two events.

As Ngui is the senior citizen here and Contextual is derived, the issue could clearly be put on Contextual, but then they would do the same thing I did, test isDragging the way I'm attempting per the documentation.

I don't mean to raise an issue between Ngui and the derived Contextual, but the Ngui documentation is clear on what the public isDragging will indicate as a public field including OnPress events as a result of dragging. I inspected the code to make sure I knew what I was saying before I said it, although admittedly, I could have missed something.

I became aware of isDragging from your answers on another thread when someone was looking to create their own dragging boolean and you said, "no need, use isDragging." or words to that effect.

I honestly thought I had uncovered a small bug. :-\

btw, saw your Unite presentation. Looking forward to Ngui 3.0 in Unity!

42
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.

43
NGUI 3 Support / Re: Event forwarding
« on: August 30, 2013, 10:12:09 AM »
Thanks! I can see my way forward now that I know I wasn't missing something obvious.  :)

44
NGUI 3 Support / Event forwarding
« on: August 29, 2013, 04:48:09 PM »
I'm struggling with how to forward events to their targeted game object from a FallthruEventHandler attached to my main 3D UICamera. I've successfully implemented the handler that gives me a copy of all UICamera events except those that go to my Gui layer (handled by a separate 2D UICamera on that layer). The main UICamera's EventReceiverMask is set to nothing like you did in Windward. I can see them arriving just like you said. What I can't figure out is which game objects they should be forwarded too and how to do it. UICamera.hoveredObject always points to the FallthruEventHandler which makes sense as there never was a hit on a gameObject collider, due to the eventMask. Without a hit on the game object being recorded in hoveredObject, how do you know who you were attempting to talk too?

I expect the answer will cause me to be :-[, but I'm at the point where I have to ask. What am I missing?

45
Quote
Just doing a straight boolean eval on a monobehavior is supposed to check it against null as well as the destroyed object queue.

Aren, have you been able to verify the above? My testing seems to indicate that a monobehaviour and/or game object slated for destruction but not yet null returns true. It sure would be helpful if it were true!

Pages: 1 2 [3] 4