Discrepancy between scenes with new anchoring system

[Seith]

Hello,

I'm seeing a strange discrepancy from one scene to another with the new anchoring system. I'm simply telling a UILabel to follow an object on-screen using:

1. objectUILabel.leftAnchor.target = objectLabelTarget;
2. objectUILabel.rightAnchor.target = objectLabelTarget;
3. objectUILabel.topAnchor.target = objectLabelTarget;
4. objectUILabel.bottomAnchor.target = objectLabelTarget;
5.  

The UI Root (2D) in both scenes points to the same prefab (and I made sure to click "Revert" so both are the identical, sitting at the world's origin).

Yet in one scene the UILabel is at the correct position on screen (ie: it appears right over the target transform), but in the other scene the label's position is completely offset on-screen (seemingly arbitrarily). I also checked that in both scenes the target transform is at the correct position in space.

So what could cause such a weird behavior if both the NGUI root objects are exactly the same and the target transform is in the correct position in both scenes? I'm a bit at a loss here...

The only difference between the scenes is that in the "correct" one the objects that the UILabel tracks are "in front" of the NGUI root, while in the "wrong" scene the objects are "behind". I don't think this should have any incidence though.

[ArenMook]

Prefabs currently cause issues, resolved by checking the "Offset" checkbox in UIPanel's advanced options. I believe I've addressed this properly in 3.0.8.

[Seith]

Thank you, so I did just that but since I have version 3.0.7f3 that didn't fix the problem of course. Is there a way to download 3.0.8 yet (it doesn't show in the Asset Store yet)?

Also another unrelated issue: when leaving "UI Root (2D)" as the default target for the anchors, and then at runtime substituting that for a "real" transform then the UILabel appears at a wrong position on screen. It only works if you manually assign a "real" transform (I mean other than the UI root) in the editor. Only then will the UILabel actually follow the anchor transform assigned through code...

[ArenMook]

When you specify the UIRoot, assuming it has a panel on it, your label's anchor points are going to be set up to anchor to a rectangle, and its absolute values will be affected by the rectangle's width and height. When anchoring to a transform, there is no rectangle, so there are no relative values, so absolute values are used as-is. If you change the anchor, you must also change the absolute anchor values, or it will be using wrong ones.

3.0.8 is available only to Professional users right now as it's still in beta, and I'm not yet done adding to it. I've redone how input works adding highlighting selection and caret, and am now in the process of revamping how text drawing is done, which is a tedious and lengthy process. I fully expect there to be some residual bugs after I'm done, so I'm going to keep it Pro-only for now as they have access to all versions and can revert to an earlier one if the latest is broken.

[Seith]

Thank you for your explanations ArenMook. I understand. So I guess I'll just have to be patient and wait for 3.0.8 to be released. Hopefully it'll take care of the main prefabs issue...

[andrew]

I don't think this is fixed, or something is wrong, or I don't know what I'm doing.  I have a UI Root (2D) saved to a prefab with 3.08.  Offset checked in UIPanel and I'm having a hell of a time trying to position text fields to corners of the screen.  I get it set perfectly.  Click apply on the prefab and it reverts back to some other position.  Overlflow *ALWAYS* resets to ShrinkContent.  I really don't understand what's going on with anchoring text labels now, and I've been using NGUI since 2.1 or so.  It used to be easy, now unfortunately, I'm finding it very unintuitive and frustrating. 

I should mention I'm using the unified anchors.  Switching back to UIAnchor allows me to position it, safe the prefab and retain the Overflow mode ResizeFreely

[ArenMook]

You can't have an Overflow setting other than ShrinkContent if the label is anchored in any way. Currently in the Pro version you can have ResizeHeight if top and bottom are not anchored, but that's it. Bottom line is, you can't resize the label from two sources -- anchors and label's content itself. Pick one.

[Seith]

@Andrew: I agree that anchoring text label has now become less intuitive but I guess there must have been very good reasons from a programming standpoint; it's just that as a simple user they elude me.

@ArenMook: I just updated today to 3.0.8, hoping that it would fix the problem with prefabs you mentioned last time but as Andrew pointed out it seems it still doesn't work: the text label does not appear at the correct position (it's supposed to appear over its target transform).

I did use the "Offset" checkbox as you advised but still I can't manage to get it to work properly. Is this still a bug or am I doing something wrong?

[Cabal]

Not sure if this is the same issue or a related issue, but I am having a similar problem with 3.0.8.

I create a UIWidget of size 1024x768 and add a UISprite to this widget anchored to the UIWidget top and left corner.
I want this sprite to end up in the absolute top left corner of the screen, regardless of the size of the screen (1024x768 or other)

In order to do that I try setting the anchor of the widget to match the top/left/bottom/right sides of the UIPanel that contains it.

This works fine as long as the prefab is in the scene. When I try to load it dynamically however, the anchor reverts to "None" for the prefab, most likely because the prefab doesn't have the connection to its UIPanel anymore.

Saving the UIPanel as the prefab is causing other problems so I was hoping the UIWidget solution would work. Not sure if there is a way to get the UIWidget to match the size of the screen when it gets loaded if the anchoring system doesn't do it.

Any thoughts?

[ArenMook]

@Cabal: Prefabs can't reference objects and components that are not a part of the prefab. It's a Unity, and one that makes perfect sense if you think about it. After you instantiate your prefab, you need to set the anchor target (widget.SetAnchor(panelTransform) for example).

@Seith: So what are you seeing and what steps are you following? What values does the prefab have, and what do you do after instantiating it?

[Seith]

Alright, here's exactly what I'm doing: first I'm not instantiating anything, the prefab is in the scene by default. My NGUI hierarchy is as follows:



And here are all the elements. First, the UI Root (2D):



Then the UI Camera:



Then the Panel:



And finally the label itself:



Now here's the code I use in my Update() function to position the label. The objectLabel_target transform is an empty transform that gets placed in the correct position in the world to make the label appear over certain items. There can only be one object name at a time (hence the need for just this label):

1.                         // Position the label.
2.                         objectUILabel.leftAnchor.target = objectLabelTarget;
3.                         objectUILabel.rightAnchor.target = objectLabelTarget;
4.                         objectUILabel.topAnchor.target = objectLabelTarget;
5.                         objectUILabel.bottomAnchor.target = objectLabelTarget;
6.                         objectUILabel.hideIfOffScreen = true;
7.  

The problem is that the label does not appear at the right place on the screen. It is arbitrarily offset too high and on the left (by about a quarter of a screen), although the target transform is exactly at the correct position in the world.

I hope this will help you pinpoint the problem...

[Cabal]

@Cabal: Prefabs can't reference objects and components that are not a part of the prefab. It's a Unity, and one that makes perfect sense if you think about it. After you instantiate your prefab, you need to set the anchor target (widget.SetAnchor(panelTransform) for example).

That makes perfect sense. What threw me off was that NGUI looks for some dependencies at runtime and I was wondering if the intent was for anchors to work the same way.
The function SetAnchor is exactly what I needed, I see this was added in 3.0.8 so thanks for adding that.

I had a workaround in 3.0.7 as well by encapsulating the UIWidget in a UIPanel and setting the anchor on the widget since the panel seems to get sized properly at runtime. I do like the SetAnchor solution better though, so thanks again

[ArenMook]

Seith, I suggest you fix the issue of you having all your panels sit on depth of 0. It's unrelated, but a warning is there for a reason. Why do you have so many panels there anyway? Why not just have one panel on the UIRoot?

Setting it in Update() is also not a good idea. Set it in Start(), not Update().

"Offset" should be off on your panel.

But your main problem lies in the fact that you've anchored the panel for some reason. Why are you doing this? Your clipping is not enabled, therefore the panel has no region, so instead it uses the screen's region. There is no point in anchoring the panel.

Remove its anchor, and clear its transform so that it's positioned at (0, 0, 0).

[Seith]

The reason why I have several panels is that each of them hold specific widgets linked to completely different topics. So I just use the alpha value of the panels to change the visibility of all the widgets within with one fell swoop. Do you suggest that I should manage the visibility/alpha channel of each element individually?

I followed your advice and put the anchor code in the Start() function, rather than the Update(). I also removed the anchoring of the panel and reset its translate values (0, 0, 0).

Alas that doesn't fix the issue. The label still appears in the wrong place. Again, the weird thing is that in one scene the label appears in the correct position on screen (following its target transform), but in another it appears completely offset. Both scenes are in the same project and use the exact same NGUI prefab. That's what I don't understand...

[ArenMook]

I investigated another issue and ran into something that likely caused your problem as well. It had to do with UIRect's OnValidate functionality. I've fixed it in 3.0.8 f3, so let me know if you still run into this after the update.