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 - konsnos

Pages: [1] 2
NGUI 3 Support / Re: Not seamless NGUI using Application.LoadLevelAsync
« on: December 05, 2014, 03:20:32 AM »
That did the job. Thanks!

NGUI 3 Support / Re: Unity 4.6 and Ngui 3.7.5 problem
« on: December 02, 2014, 10:44:12 AM »
NGUI canvas position problem. buttons outside of ngui canvas.
Can't you put the buttons inside the NGUI Canvas?

You are fast! :P
Thanks :)

NGUI 3 Support / Re: Not seamless NGUI using Application.LoadLevelAsync
« on: December 01, 2014, 02:07:23 AM »
If you have multiple UIs in the same scene, you must ensure that they use different layers, otherwise one UI's camera will interfere with another's.
You mean Unity's Layers? Not depth?

Tried it, didn't help. Previous UI was Default layer, the Gameplay UI has Layer GUI. It had the same problem.

NGUI 3 Support / Not seamless NGUI using Application.LoadLevelAsync
« on: November 28, 2014, 04:20:14 PM »
Hello again,

I'm having a strange problem. I have a MainMenu screen, which I set the UIRoot to be Constrained (Width 1920, Height 1080, both Fit), a Loading screen with the same parameters, and my Gameplay screen which is set to Flexible.

The transition between MainMenu and Loading screens is seamless. However when I LoadLevelAsync from Loading, which I have set to DontDestroyOnLoad, to Gameplay screen, I can see my Gameplay UI correctly and when I manually destroy Loading screen, it then repositions itself to somewhere in the middle.

I have tried to fix it but to no avail :( Am I missing something? Any help is appreciated. I want to keep the Scaling Style Flexible for Gameplay screen.

Hello Aren,

I've been messing around with Atlas Maker quite some time now and one thing has really irritated me. It isn't easy to remove many sprites. Could there be a multiple selection for it?

Other than that, it's great. Once again thanks for NGUI :)

NGUI 3 Support / Re: namespace?
« on: October 01, 2014, 04:16:32 AM »
A change in namespace would break current codebase of all those who are using NGUI. Everyone would have to change in their classes the usings in order to make it compatible again.

Using namespaces is nice and helps class organization but such a change should not be done at a blink of an eye.

NGUI 3 Support / Re: namespace?
« on: September 16, 2014, 03:34:33 AM »
I second the suggestion to add namespaces, at least for NGUI 4. It would be highly helpful.  :)

NGUI 3 Support / Re: Upgraded to 3.7.2 - Problem with UIButton
« on: September 15, 2014, 02:33:02 AM »
You can use 3.7.1 until this is fixed. There no need to get anxious.

Sorry for the triple post. Found the problem and reported it. Here is the bug report to anyone having the same problem.

I tried to replicate the bug, but I couldn't. Also the new Unity GUI seems to have the same problem in my project but not in an empty one. Seems that the problem exists only on my current project and only on 1080P :-S
What could possibly go wrong? What can I check?

I'll keep testing things...

You should report this to Unity if that's the case. Regression bugs like these tend to get fixed quickly.

I suggest creating a simple repro case for them though -- something that just prints the touch position.
Hm, I'm not sure if it's a Unity bug. What can I test to pinpoint it? As far as I understand it the colliders aren't in the correct position.

If I find that this is a bug, can I send the bug report with NGUI code? I'm not sure if I can help them much since I haven't looked at it and don't know how it works.

sorry to revive such an old thread. Running an app from a build for Windows Phone at Visual Studio, on Emulator 8.1 1080P 5.5 inch has the same result. Colliders are positioned at a lower position. This doesn't seem to be the case for any other versions of the app, or the smaller screen size emulators. Nokias 1520 are affected by this, while others eg. 630 are not.
Unity version 4.5.4.

NGUI 3 Support / Re: [Request] Better Tooltip controls
« on: August 27, 2014, 02:16:28 AM »
Thanks for the response.

Tooltip's pivot is indeed top left by default. I'm not sure I see a use case for it being something else...

In my case it falls directly upon the button that activated it, hiding it.

Multiple text sizes... you can already achieve this just by using multiple labels in your tooltip. I'm doing just that in Windward. The whole tooltip is just an example. Don't use it as-is. ;)

Indeed that works. But it needs some tweaking when there is need for multiple tooltip formats. Eg. one for stats with small size labels that shows off stats, and one for button tooltips with just two labels with title and description.
I've added a function to swap the instances to implement that.

NGUI 3 Support / [Request] Better Tooltip controls
« on: August 25, 2014, 10:22:45 AM »
Hello ArenMook. I've been using NGUI for a lot of time now, and the more I used it the better I understand it. It's really top and must-have for Unity3D and IMO better than uGUI so far.
But I have a few requests about the tooltip which I feel is undervalued in the whole package.

Follow mouse - Sometimes it shows up in totally bad places and I want to move it out. If the tooltip follows the mouse it would be highly convenient. Many times in games which have this feature I move it in the best possible place to watch the game but in parallel read the tooltip (eg. an ability which I want to better understand or the updated stats of my units in Rome Total War)
Multiple Text sizes - Example: Title and the description of an item. Things in parenthesis, and other stuff. I know I can set a tooltip with many UILabels to achieve this but it is not straightforward (in fact a bit hard, and adding more than one tooltips needs some tweaking), but it would be more convenient to be able to do it in one UILabel.
Better Pivot Point Controls - Currently it's top left. If I change it it's messed up and it needs some love in the script to make it work again. It should just work.
Appear Delay - Very useful. Best implemented at function ShowText, so that each element may have its own delay. I've created a coroutine to handle this, which was fairly easy, but after each update of NGUI I must copy-paste my changes.

Just wanted to drop my thoughts.  :) Your GUI rocks! Cheers.

Pages: [1] 2