Messages

1

NGUI 3 Support / Re: Another 'Shader wants normals' Question

« on: May 28, 2016, 09:19:10 AM »

Took another shot at it today and as you have said, everything works fine until I search for something and then it goes crazy. Strange, but I'm glad to know everything is actually working.

2

NGUI 3 Support / Another 'Shader wants normals' Question

« on: May 26, 2016, 08:21:43 AM »

Going off what I've seen before, here is some info up front:

-I've checked and re-checked and all UI in the scene comes from Atlases that use a "Unlit/Transparent Colored" shader. There is no real lighting in the scene, just a lightmap. The warnings also only show up when I've got a UIPanel Inspector window open in the editor.

-I've turned off almost everything in my UI except for one UISprite box collider than when clicked on shows a single Simple type UISprite, and I still get the warning....I don't know what else to do at this point other than just enable normals for the UIPanel, but I'd like to know why this is actually happening.

3

NGUI 3 Documentation / Re: UILabel

« on: January 02, 2016, 06:25:23 AM »

"Why are you doing the replace at all? Just have "\n" there to begin with. It's always like that with text."

I could swear I tried that (since as you say, this is a common behavior). But I did try it again and it worked, really don't know what I was doing wrong when I was trying this before but everything is fine now. Thank you for your time.

4

NGUI 3 Documentation / Re: UILabel

« on: December 30, 2015, 08:18:09 AM »

I've got a question about creating multiple line breaks through code, say if I wanted something like:
Some Text
[blank line]
More Text

The only way I've found to accomplish this is to do:

1.         void SomeMethod()
2.         {
3.                 //show popup that lets the user know we are validating their internet connection:
4.                 failureString = "Could not verify internet connection, make sure you have access to a network and are connected to it. Please wait 10 seconds after fixing your connection before trying again.@@(Tap to Clear)";
5.                 failureString = failureString.Replace ("@", "\n");
6.  
7.                 //or could use: failureString = "Could not verify internet connection, make sure you have access to a network and are connected to it. Please wait 10 seconds after fixing your connection before trying again." + "\n" + "\n" + "(Tap to Clear)";
8.  
9.                 label.text = failureString;
10.         }

Where the text for the string is added later in the script after the declaration of the string. Declaring the string with the text, then running Replace() doesn't work (and running Replace() on label.text also has issues), and everything else I've tried results in:
Some Text
More Text

Any ideas are appreciated.

5

NGUI 3 Support / Re: Question on "Jittering Edges" when Moving Sprites (Anti-Aliasing Issue?)

« on: February 24, 2015, 11:59:33 PM »

What version of NGUI are you using?
-> 3.7.4

Basically what I'm doing is calling UIScrollView.MoveRelative(my offset), so substituting a mouse drag with code. I figured that was the "safest" way of doing it since it uses methods NGUI already implemented.

My hierarchy for doing this:
Panel[UIPanel, UIScrolView]
-WrappedObjectsParent[UIWrapContent]
--Sprite1
--2
--etc.

6

NGUI 3 Support / Question on "Jittering Edges" when Moving Sprites (Anti-Aliasing Issue?)

« on: February 24, 2015, 06:06:49 AM »

Hello everyone, I'm working on making a "looping scroll" background that scrolls and eventually loops back to the first image, which is straight forward enough. However, I'm coming across a problem where, when moving the widgets, the edges of the widgets shake/jitter a bit as they move across the screen.

I made a quick video that hopefully shows this clearly enough:
https://www.youtube.com/watch?v=CanCkPDuxJY

Obviously, the rotated sprite has aliasing issues, and I'm guessing that even the "aligned" sprites issue is still from aliasing? I guess I've just never noticed it happen on "aligned" textures before, just looking for someone to confirm or deny that conclusion.

Any ideas appreciated, thank you for reading.

7

NGUI 3 Support / Re: Question on Anchor Setups vs. Screen Ratios Scaling Issue

« on: February 13, 2015, 05:22:04 AM »

"Sounds like it's an issue with how you had them set up."
-> Seems to be, as you say, your example happens instantly.

8

NGUI 3 Support / Re: Question on Anchor Setups vs. Screen Ratios Scaling Issue

« on: February 11, 2015, 04:33:12 AM »

That said, the "second or two" delay after hitting Play has nothing to do with NGUI, and is due to Unity unloading/loading things. Transitioning from Edit mode to Play mode takes time.

->Just to be clear, I didn't mean that "Unity Editor dead time", I was referring to (after doing something like changing screen ratios), the NGUI elements will "crawl" across the screen until they settle in their new location. That being said I have tried using the different update anchor modes, and they all seem to be behaving the same way (Am I using them incorrectly?). I also tried "ImmediatelyCreateDrawCalls" which didn't seem to make any difference (although, again, its probably me misusing the method).

9

NGUI 3 Support / Re: Question on Anchor Setups vs. Screen Ratios Scaling Issue

« on: February 06, 2015, 10:59:34 PM »

With your help, I think I've got it working now using 2 set anchors (left/bottom anchors), because I want the sides a set distance from the edges of the screen and Relative would end up putting it in the wrong position when the ratio changes. And 1 Relative (the right anchor).

I could swear I tried this before, but I'm guessing that in my frustration, I probably forgot to hit "Play" and let NGUI adjust the elements. Is there any way to avoid that (the second or two NGUI takes to adjust elements after a screen change)? Or am I better off just hiding it with a loading screen or something similar?

Thank you again, I always appreciate the help.

10

NGUI 3 Support / Re: Question on Anchor Setups vs. Screen Ratios Scaling Issue

« on: February 06, 2015, 04:10:49 AM »

I should have explained this better:

What I'm looking for is a behavior where compressing a "wide screen" ratio to a more standard ratio, in which each sub-element maintains its own shape, but becomes relatively smaller because your are loosing horizontal width (and I've tried "Fit" but that will not allow the elements to shrink).

You can see this happen on the other "To Battle" element. It also only has 2 anchors, but when the screen ratio changes, it becomes smaller (but still holds its shape). This is what I'm trying to get out of the "Options" element, but I can't get it to work.

11

NGUI 3 Support / Question on Anchor Setups vs. Screen Ratios Scaling Issue

« on: February 05, 2015, 05:37:03 AM »

Hello everyone, I'm having some trouble understanding why in my case, two different elements with the same type of Anchor setup are being adjusted dramatically differently (see below).

In Detail:
I'm working with a Constrained UI Root set to 960x640 with both "Fit" boxes set to false. I've got 2 elements (To Battle, and Options) that use the same style of anchoring to anchor them to an element that encompasses the viewable screen. What I'm seeing when a change to a different screen setup (in this case from a iphone screen to an ipad screen), the To Battle element behaves as expected, but the Options element becomes very small, and I can't figure out why.

The Images:
Before and After simply show how the screen is setup, then what it looks like after the screen switch has been made (notice To Battle slightly adjusting as expected, but Options becoming very small even though it anchors itself as To Battle does).

Additionally, I'm noticing that it seems NGUI needs "some time" to adjust the elements (updating after "Play" is pressed after changing screen size/ratio. What I'm seeing this that after Play is stopped, some elements seem to move back towards where they started, and I have to press Play 3 or 4 times to get the elements to stay in their proper new position. If there is anything I can do to avoid this, please let me know.

As always, any ideas are appreciated, thank you for reading.

12

NGUI 3 Support / Re: Trouble with TweenAlpha Duration Parameter

« on: January 28, 2015, 11:53:37 PM »

True, I'm just afraid of causing some error by doing that, guess I'll give it a try and see what happens.

13

NGUI 3 Support / Re: Trouble with TweenAlpha Duration Parameter

« on: January 28, 2015, 05:53:18 AM »

I think if you uncheck "Ignore timescale" on the tween object, it won't "jump" to the end.
-Yep, I just read the class docs and indeed, it states that having Ignore timescale checked will make it run through a game pause. Any idea why that is the default behavior? I'm sure there is a good reason for it, but off the top of my head I don't know why someone would want that behavior by default.

14

NGUI 3 Support / Re: Trouble with TweenAlpha Duration Parameter

« on: January 27, 2015, 11:16:33 PM »

Is that something that happens when you hit Play?
-No, unfortunately. In this case, when the last NPC/Player is "eliminated", the "game over sequence" starts which adds a TweenAlpha(Script) to the object in question (at which point the fade happens almost instantly).

I've also tried leaving the script on the object (stopping the sequence at that point), and have observed that changing the parameters to go back from 0 -> 1 and running the script also happens more/less instantly (but loop and ping pong seem about right).

UPDATE:
I believe I've figured out why this is happening, see original post for info if you are interested (and thank you for the help as always)...

15

NGUI 3 Support / Trouble with TweenAlpha Duration Parameter

« on: January 26, 2015, 11:42:10 PM »

Hello everyone, I'm having an issue with using TweenAlpha.Begin(), where the Duration parameter does not seem to apply correctly.

What I'm doing in code:

1. TweenAlpha.Begin(playerUIControlParent.gameObject, fadePlayerUIControls, 0f);

Description of Issue:
Pretty simple, I have a UI Widget that starts with a alpha of 1, and should fade to 0 over time. The problem is that this "transition" happens almost instantly (a few frames) even when the Duration is multiple seconds. I've tried changing the type of "Play Style" from "Once" to "Ping Pong" / "Loop" and everything seems fine as far as the duration is concerned, but as soon as I try it with "Once" again, it happens more/less instantly again.

Any ideas on what I'm doing wrong is appreciated, thank you for reading.

UPDATE:
It seems the issue was related to pausing the editor before the TweenAlpha script was finished running (in this case I was Breaking() one line after TweenAlpha.Begin() was called). As helped to be confirmed by r.pedra, Tween calculates time while the Editor is paused if Ignore timescale is checked. Once the Break() was removed, TweenAlpha's time duration worked correctly.