Why are these Bugs not fixed yet? *angry face*

1.Duplicating or pasting game objects changes rectTransform x and y positions to weird decimal places
WHY?!

2. Pasting a selection of game objects rearranges their order
WTF?!

3. Adding new files to the project changes the folder I was in in the Project tab STAHP!
Example: I have 2 Project Tabs in my Editor layout, one for sprites and one for scenes. Sometimes when adding new files to my project, all Project Tabs would change to a random folder in my project.

4. Pasting prefabs into a canvas up-scales the prefab, even though both the prefab and canvas scale are set to 1 (this does not happen on run time) NO REASON TO SCALE UP!

These bugs drive me absolutely insane! I am using 5.4.1f1, so can anybody using the latest version confirm if these issues still occur? I cannot fathom how they still exist, surely this is affecting everyone? Where can I report these bugs or see if they are already reported?

/rant

 

Umm well, the "weird decimal places" part is just a floating point precision thing, the numbers have been converted to scientific notation, they still are really close to the actual value they were set at. That isn't really a glitch at all, but just how things are done in almost every engine or software that has to calculate huge decimal numbers.

I agree that the way duplicated objects are not pasted in the same order might be frustrating, but I never have really been bugged by it, just because I usually dupe one thing at a time.

The other two things you mention I am not familiar with or have never experienced, and I work with the UI a lot. Maybe you are using some UI scaling type components that are changing it for some reason?

 

If x = 0, then x should = 0 when duplicating. Simple.

And it does actually noticeably shifts things when those weird decimal numbers take over, and I need precision with what I am working on.

 

I can't say I've ever noticed unity changing things I've typed directly into the inspector when duplicating...

For me it always seem to stay where I had it put, and the only time I get the numbers becoming any different, is after doing some kind of transform using the handles (dragging the arrows in the scene view) or perhaps when sliding the values in the inspector (dragging left and right on x or y transform) but not when duplicating. Here I duplicate and the numbers stay the same:

 

This is what happens to me. Not to every single game object, but usually to more complex prefabs and its children. As you can see the scale is also affected if not set to 1.

What version of Unity are you using?

 

Ahh so you have your prefab deeply nested under other gameobjects? That might be the problem. I'm not sure why, but for some reason, the more parents each transform gets, the worse its precision gets, and although your entering 0, the engine has to remember 0 + 0.000 + 0.000 + ..... for a lot of transforms... and the deeper it is, the worse the precision becomes. At least that is my understanding. Or best guess

Maybe try just having it a more shallow nesting, remove a few things if you can somehow, and get it closer to the root object.

I am on 5.5.1p3 right now.

EDIT: Actually I can't prove that theory, because I made a really deeply nested object and it still keeps the numbers I had when I duplicate. Maybe try duplicating root objects and see if the same thing happens to you though?

 

What you see above IS the root/parent, so what you said wouldn't apply to it.

And besides, look at other applications where you can nest objects, they don't have this issue at all, example Maya...

 

Ok well scratch that idea. I have no idea off the top of my head why that happens to you all the time. Maybe somebody else will come along and have better answers

EDIT: Oh ya know what, @enchiridion - might be a bug, check this out:
https://forum.unity3d.com/threads/d...produces-slightly-different-transform.272908/

Or... might be "by design" according to the conversation on the fogbugz site:
https://fogbugz.unity3d.com/default.asp?726873_b6h64obkv0f8151e

 

Wow, just wow.

The developers see a flaw in their code and instead of owning up and fixing it they just sweep it under the rug.

 

Hello guys, well the development team decided it was a "floating point precision issue" when they responded the bug report when this issue was reported quite a while ago and instead of using an epsilon to determine if there is an actual and meaningful change to the transform they just update it.

You might also find interesting this report as well:

https://forum.unity3d.com/threads/d...produces-slightly-different-transform.272908/

They actually mark it as "No regression".

This is so funny! (Now after 1 year!)

 

Help->Report a bug

https://issuetracker.unity3d.com/

A quick google would've answered both questions.

 

True, but this thread was more to create awareness and I tacked on those questions to kill 2 birds with 1 stone.

 

I guess we just have to live with it, I guess...

https://xkcd.com/217/

 

I gotta say, there likely is more to "fix" here than just "copy x and y and z, duplicate, paste xyz..." and it's gotta be some kind of deeply rooted problem if they are ignoring it. Has to be right?

I wonder why it doesn't seem to ever cause me problems? Do you think the latest versions might have addressed this without any indication on those bug reports?

 

The actual question is "Why is not set up to just copy xyz when duplicating in the first place". Literally no calculation needs to happen, especially when it is only affecting the parent!

 

Except that is not a correct statement. There's a layout engine behind the UI that has to run every UI component through a set of calculations based on screen size, anchors, parent anchors, layout components, and on and on. When you do single precision floating point math you get around 7 significant digits. When running numbers through all of those calculations you're going to get precision issues. For your issue, 0.00000000007 is not materially different from 0. Unity says it's a floating point precision issue because that is in fact the case. If you really don't like seeing the scientific notation then manually change it back to 0. Is it annoying? Sure. But calling it a bug is incorrect.

 

Again, it shouldn't even be doing calculations, just duplicating what's already there, you know, mirror image, replica, exact double.

When duplicating, the UI should not be going "ok copy object -> parent the object in the canvas -> check canvas settings/scales etc -> position newly pasted object with corresponding values", and instead be going "ok copy object -> paste object with exact values of original object".

 

Just curious; what happens if you duplicate the duplicate? Does it get worse every time?

edit: or does it "float" around the original values?

 

Duplicated 4 times, stops changing after the 3rd time.

 

That's not how UI layout systems work. Unity has no idea what particular combination of custom UI components live on the objects you just copied. What if these objects live in a vertical layout container? They all have to be laid out again after you paste them. It would not be practical to examine the objects you're pasting to determine which ones may or may not need to be laid out, especially when you can create your own custom layout components. The only practical way of dealing with this is to run everything through the layout engine every time there's a change.

 

I think I have figured out what's causing the weird numbers:



The canvas has to be 2208x1242, but for some arbitrary reason it sets the rectTransforms Height to 1242.121 and the scale to a weird float.

I would expect the x and y to be 0, width 2208, height 1242 and scale all at 1.

Am I doing something wrong with my setup or is this another issue?

 

Your UI Scale Mode is set to Scale With Screen Size, so the entire UI will change scale as the screen size changes. When running the game in the editor the screen size is the size of your game window. You can manually resize that and see the scale change. There's also a dropdown so you can select various aspect ratios to see how your UI fits in order to tweak things. Refer to the Canvas Scaler documentation for more info.

 

You're seeing floating point rounding. You cannot fix this. Stop trying.

The Canvas self manages scale to make it look right at different resolutions.

 

My guess is, because:

from: https://fogbugz.unity3d.com/default.asp?726873_b6h64obkv0f8151e

@LaneFox I think that's too much to be just a floating point error.

 

In all practicality the Canvas scale is correct. It doesn't look like there is any evidence of real issues other than annoying the user. Some images he's posted are literally just floating point issues which cannot be fixed - and apparently aren't even causing him any real problems anyway.

 

You might be right about that (edit: do you really know that wouldn't cause any problems?). I was just pointing out that it's too much to be floating point error and more likely because of matrix magic.

 

David, you do not necessarily have to check in every function or class, let me explain, for instance, lets assume we have a class Transform which has a member m_x:

Code (CSharp):

1. float floatEpsilon = 0.00001f;
2.  
3. setValue(float newX)
4. {
5.     if(Mathf.Abs(x-newX) > floatEpsilon)
6.     {
7.         m_x = newX;
8.     }
9. }

and viola! there you go! Easy peasy!

Further more, you can have matrix assignments, but the assignment has to be calculated so.. it can be validated like in the code, before the assignment.

There are plenty other more cool solutions than this raw example.

 

I know!!! This is hilarious!!!

 

And then wonder why my x value isn't changing when adding very small values to it, causing my object to not move at all. Unity did something similar when comparing two vectors using the equality operator, causing two vectors that you *know* are not equal to compare as equal. These sorts of hidden hacks break expectations and can make certain scenarios very difficult to debug. When I set a value to x it had better be the x when I read it back, or as close as can be approximated by floating point precision. Non-exact floating point values are a feature, not a bug.

Regardless, it's not even the issue OP was having. OP's canvas scaler scaled based on screen size. When doing that you'll only get integer results if the actual screen size matches the reference screen size.

 

Yes man, this is the same, all calculations are being made by the same core functions which is also causing the transform values to spin like crazy when you make any transform operation.

On the other matter, one thing is to make the precise comparison in the code, and another whole different thing is to show it in the interface when you edit it using "eye precision". I already suggested that to Unity, many programs do that already, including Maya. So yo do not need to remove IEEE float precision from the code, just show it properly and humanly readable.

 

this gives me hell too. Don't care much for precision, but when my OCD sees that scale 1 turned into 0.9999 makes me stop what I do and edit the damn transform. I wish it would work at least for the default values (scale 1 rotate 0).

might look into the custom duplicate script, just to stop the nightmare

 

Hahaha this is hilarious and I totally agree!! I honestly might use some good old C# reflection on their Editor script for Transforms or something and put a duplicate button... oh joys.

 

I wouldn't say I'm bothered by it, and I do know why it is occurring and that it doesn't actually matter, but I do edit the transform every time I notice it.