Messages

1

NGUI 3 Documentation / Re: UIRoot

« on: September 23, 2014, 03:57:53 PM »

In that case my main camera is a 2D camera. However, comparing the cameras, I noticed that I had my main camera set to a size of 5, which created the discrepancy. Once I set my NGUI camera to 5 as well, everything is as it should be. Problem solved! 

Thanks so much for the help, ArenMook

2

NGUI 3 Documentation / Re: UIRoot

« on: September 22, 2014, 06:34:22 PM »

Thanks for the thought, ArenMook… I'm not sure I understand, though. What is a 2D camera, or rather how would I create it? I can only find one type of camera in Unity, and in my scene I have the 2D toggle switched on. What am I missing?

3

NGUI 3 Documentation / Re: UIRoot

« on: September 21, 2014, 06:34:28 PM »

It's not maroon. It's bright red. Enclosed is a screenshot for you to look at. I've noticed that the red box changes depending on how I adjust the "Game" screen window, but no matter what I do, it never matches up with the actual size of the scene. Keep in mind that my scene is supposed to be a single-screen entity. Think of it as a menu screen that does not scroll or move or anything.

With the current set up it is virtually impossible to place or control UI elements because they have to be placed on positions that have absolutely no relation to the actual scene positions, not to mention that they will all clutter up there in the small rectangle in the center of the screen, obscuring whatever else is supposed to be there in the scene view.

I hope it's a bit clearer now.

4

NGUI 3 Documentation / Re: UIRoot

« on: September 18, 2014, 06:07:24 PM »

I am seriously confused at this point. I haven't done any work with NGUI for some time and just upgraded to 3.7.2, and nothing seems as it used to be, and I'm lost…

When I create a new 2D GUI it creates a UIRoot with an attached camera, which is fine. However, the red rectangle representing the camera view is ridiculously small, using up, only about a quarter of the width of the actual screen/scene. Why is that? Am I missing something?

I am using one fullscreen scene, representing a 2D screen in the game, so nothing is scrolling etc. Ideally, it would be helpful if the UI placement would actually match the backdrop in terms of size and positions. As it stands right now, I have place the UI elements in places that have no actual relationship to the game screen itself, and it is impossible to place them in code, because the object positions follow an entirely different scale than those of the actual game graphics. The way it is currently, is really quite unusable, but I found no way to fix this.

What am I doing wrong? How can I get NGUI to create a user interface that matches the scale and placement of the scene it belongs to, so that it's not entirely disjointed?

Thanks for any suggestions.

5

NGUI 3 Support / Re: HTMLEngine for NGUI and Unity3D.GUI [RELEASE]

« on: June 19, 2013, 06:14:35 PM »

Does this package work with NGUI's localization? Also, is there way to get a copy without the free NGUI version being part of it? I don't want the installation to completely mess with my existing project and installation.

6

NGUI 3 Support / Re: Screen coordinates of a box collider

« on: June 15, 2013, 05:37:08 PM »

Finally got it to work. :-)  Thanks for the input, Michael.

7

NGUI 3 Support / Re: Screen coordinates of a box collider

« on: June 15, 2013, 02:10:03 AM »

Thanks for trying to help but in all honesty, I have absolutely no idea what NGUIMath.CalculateAbsoluteWidgetBounds does. I look at the code and I have no clue what is happening there, let away which of these lines of code would relate to transforming a position to screen coordinates.

Isn't there some standard API routine or a few lines of code that take an object, get its collider box and translate the position to screen coordinates? With all this code and all the tests I've been running trying to get this to work, I feel like I am completely in No-Man's land here, because nothing I do yields any results that even remotely resemble the correct screen coordinates.

8

NGUI 3 Support / Re: Screen coordinates of a box collider

« on: June 13, 2013, 08:32:25 PM »

The "big" code was there because I kept working on this, rewriting it a million times, trying to get it to work. in the end, yes, of course, caching the look-ups will be part of the code. But first I need to get it to work - and I can't.

I tried this world to screen etc, but all I'm getting are fantasy values. So, perhaps it is time for me to rephrase my original question.…

How can I get the on-screen coordinates of a scaled object's collider as a rectangle?

9

NGUI 3 Support / Print properties of an object

« on: June 13, 2013, 08:08:38 PM »

Does anyone here have any helper functions or classes they'd like to share that would allow to print the properties of any C# object? Since Mono's debug capabilities are so limited, it seems almost imperative to have something that allows you to look at the contents of an object during run time but I can't seem to find any decent function to do that.

Any help would be very much appreciated.

10

NGUI 3 Support / Screen coordinates of a box collider

« on: June 11, 2013, 05:35:14 PM »

I am still struggling with this and can't seem to get this right. I need the on-screen coordinates of a box collider attached to a gameObject.
Here is the code I'm currently using, but for some reason it seems to be constantly off by 20 pixels or so.

1.         Vector3 bPos = gameObject.transform.localPosition;                                                                      // Box position
2.                
3.         float bcCenterX = gameObject.GetComponent<BoxCollider>().center.x * gameObject.transform.localScale.x;          // Calculate adjusted center offset
4.         float bcCenterY = gameObject.GetComponent<BoxCollider>().center.y * gameObject.transform.localScale.y;
5.                
6.         float bcWidth = gameObject.GetComponent<BoxCollider>().size.x * gameObject.transform.localScale.x;                      // Calculate adjusted dimensions
7.         float bcHeight = gameObject.GetComponent<BoxCollider>().size.y * gameObject.transform.localScale.y;
8.  
9.         float colliderX = bPos.x + bcCenterX - ( bcWidth / 2 );
10.         float colliderY = bPos.y + bcCenterY - ( bcHeight / 2 );
11.  
12.         Rect collider = new Rect( colliderX, colliderY, bcWidth, bcHeight );
13.  

Could anyone tell me what I am doing wrong here? It seems so straight-forward but for some reason my resulting rectangle is just not correct.

11

NGUI 3 Support / Re: NGUI for non games

« on: June 07, 2013, 07:45:39 PM »

Yes, yes and yes! While it may not have been created with that purpose in mind,  NGUI is incredibly flexible and powerful and can be used for just about anything.

12

NGUI 3 Support / Re: How to add a UIToolTip?

« on: May 31, 2013, 04:31:03 PM »

In your Scene create an empty GameObject and attach the UITooltip script to it. Then create a Label as a child under it. Set it up so that the UITooltip script uses that label for the text output by assigning it in the Inspector.

Now all you have to do in your own code is make a call to UITooltip.ShowText( "Here is your own string" ) to display the text.

13

NGUI 3 Support / Re: Overlapping box colliders causing trouble

« on: May 30, 2013, 12:24:45 AM »

That would be a god-send, really!  Thank you so much!!!

14

NGUI 3 Support / Re: Overlapping box colliders causing trouble

« on: May 29, 2013, 12:22:32 PM »

Thanks, Michael. I'll try to find a work-around, probably using the bounds of the large panel to determine if it's been triggered with a FALSE event while he mouse is still on top of it.

15

NGUI 3 Support / Re: Overlapping box colliders causing trouble

« on: May 29, 2013, 12:10:02 PM »

Since I have not only a second, but a third, fourth, fifth, sixth… 12th collider on that panel, that is not really a desirable option. As I mentioned in my post, I simplified my problem for illustrative purposes but there is a lot more going on. Doing a collision detection within the collision detection doesn't really seem all that sensible an approach. After all, that is exactly what I expected OnHover to do.

I still do not understand why the collision is trickling down from the top collider to the bottom collider? Why would the logic turn off the underlying collider? After all, the mouse is still over it?