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

Pages: 1 2 [3] 4 5 ... 11
Very epic indeed - It's now full screen (see updated attachment) - I can't minimize/close it to see the error - I can't seem to use NGUI anymore :D - Since this keeps happening no matter what I do (remove/reimport NGUI, restart Unity etc)

Please tell me there's a way to make NGUI FORGETS - like it REMEMBERS.

Where is this memorizing data kept?

So after I upgraded to 3.0.6 - I "accidentally" opened an old atlas (created in 2.6.4) - Now I'm stuck with a broken atlas maker (See attachment), since now NGUI "remembers" stuff - Closing/Reopening Unity won't fix it - NOR does removing and re-importing NGUI!!

I'm now stuck with a broken atlas maker - I can't do anything.

What can be done about this? - Where does NGUI "remember" stuff? Is there a clear cache button or some cache some where that I could erase?

@Aren please this problem has been around for a while now and I know I'm not the first one to come across it.

(For the future: Please consider removing the atlas thing all together, or at least, make it transparent user-wise)


EDIT: Just read you patched it - well, it's still there it seems.

EDIT: Check out the attachment, for the latest full screen version of the bug :D - I can't minimize, nor do anything but stare at it. (Happens automatically when opening the AtlasMaker)

Thanks for your reply. But I don't think just resizing the parent sprite would work since I don't only rotate the item inside the bag, but also when it's held by the cursor - so I have pick where you click + rotate around where you picked. Please see this 45 secs video:

Can you think of something else? is setting a corner position hard?

In my inventory, I add and rotate items. But when I rotate and then add, things go wrong since the pivot hasn't been adjusted.

Adding - (in Item.cs):
  1. public void Notify_HasBeenAdded(Slot toSlot)
  2. {
  3.         // stuff
  4.         cachedTransform.localPosition = toSlot.cachedTransform.localPosition;
  5.         // stuff
  6. }

  1. public void RotateItem(RotationDirection rotDir)
  2. {
  3.         // stuff
  4.         var tween = TweenRotation.Begin(parent.gameObject, rotAnimTime, parent.localRotation * Quaternion.Euler(0, 0, (rotDir == RotationDirection.Clockwise) ? -90 : 90));
  5.         // stuff
  6. }

When I rotate and then add, here's how it looks - See attachment - It was originally topleft, I rotated 90 dgs clkwise, if you look at it, you wouldn't think the pivot is topleft, it would look like as if it was topright, right? but in fact, it's still topleft but rotated.

Using localCorners wouldn't work here cause it relies on getting the offset from the pivot, which is topleft, but looks like topright.

I solved this problem by writing a piece of code that adjusts the pivot according to the rotation.
But I don't wanna use that - it's just not very reusable. So I thought, why not write a method that sets a REAL corner in a widget to a certain position? Like: widget.SetCornerTo(Corners.TopLeft, pos); - That way I could always set the REAL top left corner, without having to worry about rotation, pivots, etc.

I tried, and came up with a formula that says:
  1. newPos = reqPos + (realPivotOffset X realDimensions)

  1. newPos: is the position where the widget will reside by its real pivot.
  2. reqPos:  is the position required to set a certain corner at.
  3. realPivotOffset: is the dist from the corner we're trying to set and the real pivot.
  4. realDimensions: is the real dimensions of the widget - taking rotation into consideration.

I'm having trouble getting it to work since I can't seem to find a way to get the realPivotOffset.

realDimensions is easy to find. Originally, the sprite was 150x100 - when I rotated 90 dgs the real dims are 100x150, rotate again back to 150x100, etc. So:

  1. if (widget.localRotation.x % 180 == 90) {
  2.     reaDim.width = widget.height;
  3.     reaDim.height = widget.width;
  4. } else {
  5.     reaDim.width = widget.width;
  6.     reaDim.height = widget.height;
  7. }

But just to illustrate, in my attachment example (2nd picture) - (let's set the topleft corner) it would be:
  1. newPos = reqPos + ((1, 0) X (100, 150)) // the gun is actually 150x100, but since it's rotated, it's now 100x150
  2.                                   // the (1, 0) is the dist from the topleft corner, to the real pivot at the topright
  3. newPos = reqPos + (100, 0)
  4. newPos = reqPos + (width, 0)

If it wasn't for rotation, it would be as simple as:
  1. 0- cache the original pivot.
  2. 1- set the current pivot to the required corner.
  3. 2- set the widget's position to the required position.
  4. 3- rollback to the original pivot.

I also thought of multiplying the localCorners by a transformation (rotation) matrix - that rotates the corners by the rotation of the item - But no idea how to do that... Not even sure how it would help.

To recap, how can I set a widget's position by its corners regardless of its rotation or original pivot? - Something like widget.SetTopLeft(pos);

Thanks a lot!

PS: Had to write the question twice [very frustrating] since the site logged me out the first time I tried to submit.

Sir, your are one the best developers the world has ever known! (at least to me) :)

It's now 95% accurate - I still get about 148 and not 150 when I click on the right edge of the sprite. Any idea why? could it be related to the sprite, since it's sliced, or is it the UIRoot affecting this as well...?

Lastly, should I always avoid using position/localPosition? when is it safe to use them?

PS: I think it would be VERY COOL to write a "Don't do it like this, but this" or "NGUI Gotchas" post - keeping us away from doing things the wrong way - maintaining awareness. - Like for example not to deal with position/localPosition directly, etc. It would a super time saver for people like me.


NGUI 3 Documentation / Re: UIScrollView
« on: November 23, 2013, 12:00:59 PM »
I can't believe my eyes, you really made a nice doc following my suggestion! You are the best developer ever! Thanks.

About the scroll view - I've always found it a bit inconvenient to have it scroll by left/right clicking and dragging. What if I only wanted it to drag when I hold right click and drag? and not left click? I would have to modify the code - which is not very nice since my changes will get overwritten in the next update.

Another thing, is that if one would specify unrestricted movement and scroll with the mouse - it would scroll diagonally! which is very odd, as a user I would expect that scrolling with the mouse, will only scroll vertically - While holding the middle mouse button and moving the mouse left/right would scroll horizontally.

NGUI 3 Support / Sprite dimensions don't correspond to screen dimensions?
« on: November 23, 2013, 06:05:26 AM »
This is one of those weird things that I've always wanted to get rid of in NGUI.

I have a sliced sprite of 150x100 dimensions. Yet if I click on its right-most edge, I get an x value of around 125, and not 150! (See attachment)

  1. var screen = NGUITools.FindCameraForLayer(fromSlot.gameObject.layer).WorldToScreenPoint(Slot.background.cachedTransform.position);
  2. float x = (Input.mousePosition.x - screen.x);
  3. float y = (screen.y - Input.mousePosition.y);
  4. Debug.Log("x: " + x + "y: " + y);

I need this to figure our how many slots I'm clicking away from the top-left slot. After I get the difference, I divide by the slot's template size (50) to get the right number:

  1. // continuation from previous code...
  2. float colDif = x / Owner.SlotSize;
  3. float rowDif = y / Owner.SlotSize;
  4. Debug.Log("col: " + Mathf.FloorToInt(colDif) + " rowDif: " + Mathf.FloorToInt(rowDif) + " sSize: " + Owner.SlotSize);
  5. AddingOffset = new Index2D((int)rowDif, (int)colDif);

This will only work well, if I get a correct x and y. But since they're a bit lesser than the original values (~125 and not 150 for the width, and ~80 and not 100 for the height), my calculations all will go wrong.

Can somebody tell me why this is happening, and how to go about doing it the right way?

Thanks a lot!

NGUI 3 Support / Re: Can't get the right on-screen coords of a widget?
« on: November 23, 2013, 05:16:44 AM »
Solved by using the UI camera to do the thing - I could have sworn I tried it the first time and it didn't work... strange.

NGUI 3 Support / [SOLVED] Can't get the right on-screen coords of a widget?
« on: November 23, 2013, 03:46:52 AM »

WorldToScreenPoint is acting funny with me - as I'm not able to use it to calculate the right on-screen coords of the top left corner of my inventory slot. See my question if you so please:

I don't know why but, I think there's some NGUI factor related to the problem.



Sorry - My bad. Something else was affecting the item's scale - thus affecting the sprite. I just had to reset the main item's scale to sprite.ParentHasChanged(); works :)


I'm still working on my inventory system - I keep finding better ways of doing stuff.

My items in the scene are just gameObjects, with a hierarchy of:

Item: (Has Item script)
-- Model
-- Sprite (Has UISprite)

Of course, one should add widgets to a panel otherwise it wouldn't look right - I was wondering if there's a way to create a sprite just like that (outside a panel) - And then when the item is picked, it gets added to my inventory (which has a panel) - I was hoping I could do that, and the sprite would correct itself- Since the item's parent now is a slot in the inventory - But it didn't seem to correct itself too well.

I tried:
  1. sprite.ParentHasChanged();

  1. sprite.panel.Refresh();

But none worked :(

Again, I'm creating the sprite in a gameObject (the item) outside any panel - and then adding the item to the inventory which has a panel. How can I tell the item's sprite to correct itself?

If I can't do that, what's the right approach?

Thanks! :)

PS: Currently, I have an ItemTemplate reference in my inventory, whenever I add an item, I instantiate that template and add it as a child to the item and then set the atlas and sprite accordingly all in code. But I found that to be a bit of a hassle - I'm really hoping to get it working the way I want (ie create the sprite outside)

NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion
« on: November 19, 2013, 01:48:41 AM »
One more thing I'd like to add - Is to make NGUI code follow the O in SOLID - Open for extension and closed for modification. Sometimes I need to create a custom type of UIInput, some of the stuff is private - why not make them protected? - I have to come in and edit your code - 'open it to modify it' - to be able to extend it.

Just a thing to keep in mind.


NGUI 3 Support / Re: (!!!) Improving NGUI: Voice your opinion
« on: November 18, 2013, 04:14:12 AM »
I read this thread when it had 0 replies - But didn't have to write my opinion.

1- @Aren: you said it in Unite 13 "Atlases suck!" - And they do suck, hard! - They break a lot! - And, what if you wanted to change your atlas for your UI? - You'd have to go to each widget that used the previous atlas and change to the new atlas instead, ahhhh.........
I really wish to see atlases removed - And provide us a better/easier way to manage sprites with good performance and number of draw calls.

2- Better clipping - and an effective and easy way to create a modular clipping panel (

3- Advanced UIInput (I would really love to see this) - Supports putting the mouse caret where user clicks and highlighting text. (

4- Letting the UI event type, detect colliders on disabled widgets? That would be nice me thinks.

5- An easier way to create modular UIs?

6- An easier, less pain in the butt workflow in general :D

7- Less painful migration operation in major upgrades - (Unlike 2.x to 3.x - where I had thousands of code depending on the old system - I had to recreate the UI from almost scratch to keep up with the new stuff, please make it less painful next time...)

8- More "advanced stuff" (mainly coding-related) NGUI tutorial videos?

9- Lastly, the thing that really sucks about NGUI from the beginning: THE DOCUMENTATION! - It's always been known that NGUI documentation is the worst thing in it, it's a lot more developer-oriented than user-oriented - Very little info on it, barely the name of the methods and their parameters... ahhh come on! - Please make it better, add more details, examples, etc. I really think that if the docs where better, you would have a lot less pressure on you in the Forums.

Thanks! :)

By major you mean 3.1 or 3.0.6?

Thanks for your input, and sorry for my late reply.

Yes, you are correct, a panel do resize correctly thus it can be made modular - Done the same by using a combo of UIAnchor and UIStretch scripts.

And no, the container isn't a child of the panel.
  1. Items Window
  2. --- Inner - Background (This is the container of the clipped panel)
  3. --- Inner - Glow
  4. (Panel) - Clipped
  5. --- Items

However, when I use an anchor on the panel, I can't seem to scroll my items correctly, very strange behavior! - The scrolling acts naturally back if I disable the Anchor script on the panel, but if I do so, it won't resize correctly when resizing its container... :(

So I thought, oh well it must be because that the items is a child of the panel, so if I put the items somewhere else, this should solve it... I was wrong, it didn't.

I wanted to make a small video about this, but as I was making it, I ran into other very strange issues as well, for the first time...
Please have a look, as it might give you more things to consider in your next release:

Your reply is very appreciated. Thanks.

Pages: 1 2 [3] 4 5 ... 11