NGUI and [ExecuteInEditMode]

[sebas]

Hi,

We are having a weird problem that we are currently putting down to the [ExecuteInMode] tag of the NGUI classes.

We are extensively using NGUI inside a prefab that is shared between several levels. All the levels are assetbundled, but before to assetbundle them we extract the shared prefab using the PushAssetDependencies/PopAssetDependencies feature.

However even doing so, the prefab is always different between the scenes, like if each scene has is own copy of the original prefab. Since we are not touching it (it happens even if we just revert it and save the scene), we are guessing that allegedly NGUI keeps on changing the prefab, even if nothing is touched.

This doubt is strengthen by the fact that once we start using NGUI, the * symbol that indicates that one scene has been changed and not saved never disappear, is always there, even if we just saved the scene.

Any advice?

[ArenMook]

I am not familiar with PushAssetDependencies/PopAssetDependencies. You might be on your own with this one. Try using NGUI in a brand-new project. The scenes should be saveable just fine and the * goes away (if not after the first save then after the second).

[ExecuteInEditMode] flag simply means that the scripts run while in the editor if they are attached to an object in the scene's hierarchy. It's how NGUI is able to display the UI in edit mode.

[sebas]

I must find the time to test it, but don't you think that setting the value of a parameter, even without changing it, would anyway make the star appear?

[sebas]

yes I verified, with the following monobehaviour the star never disappears.

1. using UnityEngine;
2. using System.Collections;
3. [ExecuteInEditMode]
4. public class UpdateTest : MonoBehaviour {
5.  
6.         // Use this for initialization
7.         void Start () {
8.        
9.         }
10.        
11.         // Update is called once per frame
12.         void Update () {
13.                 Vector3 v3NewPos = new Vector3(0.1f, 0f, 0f);
14.                 transform.position = v3NewPos;
15.         }
16. }
17.  
18.  

Now what I suspect is that if an ExecuteInEditMode is inside a Prefab, the prefab will never coincide to the original one, even if I just revert and save.

[ArenMook]

Yes it would, which is why NGUI checks to see if it actually changed first.

[sebas]

sorry could you add some info? What do you mean with "checks to see if it actually changed first."?

edit: you mean this:

// Wrapped in an 'if' so the scene doesn't get marked as 'edited' every frame
if (mTrans.position != v) mTrans.position = v;

ok it is interesting, because all the investigation still lead to this class...I will double triple check

[ArenMook]

Yes, precisely.

[sebas]

ok the code is faulty, first I am not sure if

mTrans.position != v

checks the reference instead of the actual xyz values, but even if it checks the actual values, there is a problem of roundness. The if is ALWAYS true because of floating point errors. The class is UIAnchor.cs, I will investigate even more.

Edit: == is overridden, so the semantic of the code is correct, but anyway the problem lies on the floating point error roundness

Edit2: something like this works already

if ((mTrans.position - v).sqrMagnitude > 0.000001)
  mTrans.position = v;

Edit3: another thing I just noticed is that I Run and stop, without touching anything at all, the star reappars. Tomorrow I will investigate more.

[sebas]

So this is a new update, I am not done yet though:

I can confirm that the code in UIAnchor.cs:

1.         if (mTrans.position != v) mTrans.position = v;

should be changed in something similar to:

1.         if ((mTrans.position - v).sqrMagnitude > 1E-08f)
2.                 mTrans.position = v;

or even something like

1.        
2. Vector3 ps = mTrans.position;
3.  
4.                 // Wrapped in an 'if' so the scene doesn't get marked as 'edited' every frame
5.                         if (!Mathf.Approximately(ps.x, v.x) ||
6.                                 !Mathf.Approximately(ps.y, v.y) ||
7.                                 !Mathf.Approximately(ps.z, v.z))
8.                                 mTrans.position = v;
9.  

that you already used elsewhere.

this at least stop the scenes to be modified continuously.

However I noticed another very annoying inconvenient, many (too many to be fixed by me) scripts use to change serialized values inside Start, Awake or OnEnable. This make the scene be modified (the star appears) once I stop the game execution from the editor.
I noticed that occasionally a check to avoid to assign the same value again is present, while other times it is not.

Anyway the question is: does this introduce major troubles? If as I suspect this behavior break the prefab connections, this could be a major problem. My next experiment will be to verify if the prefabs connections are actually broken when a serializable value changes without being applied.

Edit:incredibly Mathf.approximately is not effective enough since it seems that the error is greater than the smallest tolerance.
Edit2: do you think my problem has nothing to do with NGUI and should be found somewhere else?

[ArenMook]

As I mentioned, my scenes get saved just fine and the star goes away. My guess is, the problem is elsewhere. For example, your game window size may have odd dimensions such as 899x771. Change that to 900x770 so it's divisable by two.

You may also have more than one anchor in the hierarchy. Check for that -- you should only have one.

[sebas]

I don't know, I mean how can I control the window size while editing? It can be anything.
While for the UIAnchor, yes it is true that we use to put many in the hierarchy. How come it is not a good practice?

[ArenMook]

Nested anchors are a bad idea because each one alters their position, which propagates changes to its children (if a UIPanel happens to be at or above the lowest anchor). If you have them nested, then they will conflict with each other, and may indeed result in your scene always being marked as edited.

[sebas]

should not NGUI warn me about it? Or it does already?

[ArenMook]

No, it doesn't warn you. I might add a warning later on though.