Problem with dynamic fonts and source control

[kruncher]

"Installed"? The TrueType font should be a part of your project.

Just in case that question was directed at me:

I only have the font installed for work in Photoshop. I would expect the Unity asset importer pipeline to deal with the font. Unity only breaks the font reference the first time it updates its asset database from a GIT repository.

Added: I am going to spend some time today trying to figure out why the scroll bar class is causing this problem by stripping it back.

[kruncher]

Okay, I have traced this problem to its root with a lot of trial-and-error. The problem is caused within one of the parent classes of `UIScrollBar` which is the `UIProgressBar` script.

The following is the bare minimal representation of the script which causes this issue to occur. I didn't bother inlining `ForceUpdate` since I figured that retaining the structure would help you to see where it came from. This is the bare bones implementation of the `UIProgressBar` class which leads to the problem occurring:

1. using UnityEngine;
2.  
3. public class UIProgressBar : MonoBehaviour
4. {
5.        
6.         [HideInInspector][SerializeField] protected UIWidget mFG;
7.        
8.         protected void OnValidate ()
9.         {
10.                 ForceUpdate();
11.         }
12.        
13.         public virtual void ForceUpdate ()
14.         {
15.                 if (mFG != null)
16.                 {
17.                         mFG.drawRegion = new Vector4(0f, 0f, 1f, 0);
18.                 }
19.         }
20.        
21. }
22.  

I have spent some time minimizing the number of scripts in the NGUI assets folder. My GIT commits (made whilst minimizing the repro project) might be useful for you. I will send you the updated GIT project in a moment.

I hope that this helps to reduce the problem further for you

[ArenMook]

I only have the font installed for work in Photoshop. I would expect the Unity asset importer pipeline to deal with the font.

The font must be in your Assets folder. That's the only way it's ever going to work. If it's not there, then there isn't going to be any .meta file alongside it. No meta file means it won't be stored in the repository. Not being stored in the repository means no references to keep.

[kruncher]

The font must be in your Assets folder. That's the only way it's ever going to work. If it's not there, then there isn't going to be any .meta file alongside it. No meta file means it won't be stored in the repository. Not being stored in the repository means no references to keep.

As you will see in the video and the demonstration projects which I have sent you, the font assets are in the project folder. I also have them installed into the Fonts folder on Windows and Mac for use in Photoshop

Clarification on former wording: I only installed the fonts into the OS's so that I could use them in Photoshop. Unity naturally requires the font as an asset in the project.

[kruncher]

If "mFG.drawRegion = new Vector4(0f, 0f, 1f, 0);" is removed from the minimal version, the issue does not occur. So it seems to be related to this...

The problem seems to be caused by ExecuteInEditMode in the other NGUI scripts. I have removed that attribute from the bare-bones repro case of `UIProgressBar` (as you can see above).

For the purposes of testing I have:
1. Removed all references of "ExecuteInEditMode" from the NGUI scripts.
2. Naturally this does not preview in edit-mode anymore.
3. Problem no longer occurs when testing using play-mode. The former problem occurs in edit-mode and play-mode since Unity damages the asset.

So it looks like ExecuteInEditMode is causing an issue when Unity is regenerating its asset database. I haven't used this attribute in my own asset and do not really understand its quirks. Hopefully this will help.

[kruncher]

Okay, I have found the troublesome lines of code in NGUI source:

UIWidget.cs : MarkAsChanged
Occurrences of:

1. UnityEditor.EditorUtility.SetDirty

Removing these fixes the problem.

[ArenMook]

SetDirty should be there. I'm not sure if it was you I emailed back or not, but the root of the issue seems to be the fact that Unity executes OnValidate function in scripts on prefabs, even if prefabs are not instantiated, or selected. 3.0.9 f3 should have this resolved by exiting out of OnValidates early if the game object is disabled.

[kruncher]

SetDirty should be there. I'm not sure if it was you I emailed back or not, but the root of the issue seems to be the fact that Unity executes OnValidate function in scripts on prefabs, even if prefabs are not instantiated, or selected. 3.0.9 f3 should have this resolved by exiting out of OnValidates early if the game object is disabled.

Yes, it was me you e-mailed!

It seems that usage of SetDirty within the context of OnValidate is the cause of the problem when importing the project for the first time. The early-exit strategy seems to work perfectly in my trials today. It hasn't failed once.

Thanks for the fix! My client will be so happy now that they don't have to perform odd fixes each time they pull from the repo

[kruncher]

The previous fix has been working great! I haven't updated to the latest version of NGUI yet, but adding those early-outs has made the GIT workflow a breeze

[col000r]

Hm. Not working at Unity anymore? So what should we all do now? I was under the impression that uGUI would more or less naturally replace NGUI down the line and that you had some kind of deal worked out with them for that. (This was based on no evidence whatsoever, just plain guessing on my part...)

So the new uGUI is just another new GUI-System to compete in the market then it seems. Should I give the new uGUI a try or stick to NGUI? Will you continue to develop NGUI?

[ArenMook]

Well, brief history... uGUI started as NGUI. That is, I took NGUI in its entirety and branched off from it to create uGUI. There was no deal or compensation, I just felt that Unity deserved a solid foundation to start with. That was around April last year. From that point up until mid-June I was on it mostly by myself and had full control of what was being changed.

Eventually other people jumped onto the project and things started getting pulled in other directions. Rendering/batching pipeline, complete inspector re-design, scene view handling, text system, anchoring system... Some changes I liked, others -- not so much. In the end I felt like I was also pulled in different directions. On one hand I wanted to finish uGUI, but on the other hand I felt that I had less and less control over the overall polish, and I found it frustrating.

I also wanted to do game dev because I passionately believe that in order to make great tools, the people making them have to use them as others use them. Unreal has Gears of War. CryEngine has Crysis. idTech had Doom and RAGE. Even Unigine had Oil Rush. Unity... has nothing. And it shows as a bunch of half-finished systems that devs have to work-around.

Cloth crashes Unity if included in prefabs, doesn't respect rigidbody interpolation and can't be disabled without breaking. WindZone not being available to scripting at all. ParticleSystem not having most of its properties exposed to scripting... Those are just the ones I encountered in the past week alone.

I hate hacks. I hate them with a passion. Seeing things come apart as others started changing them, and become visibly worse with the excuse of "oh, I'm just going to get it working for now, make it pretty later" wore at my resolve. I believe that if something is worth doing, it's worth doing properly, and from the start. Because let's face it, most of the time there will never be a "later". Once a feature is in, devs will move on to the next thing. Polishing, and more importantly -- using those features is never a priority.

In the end, I realized that I was spending a lot of time idling, and very little time actually doing something. My "mojo" was gone, and I wasn't going to stick around for the paycheck. And so I left.

Curiously enough, my mojo returned within a week. I was back at it doing dev work, and the week after my last week at Unity was the most productive NGUI-dev week I've had to date, with me adding many of the features people were asking about.

Now it's a new year, and I am focusing more and more on game dev, which is what inspires me in the first place.

[ArenMook]

Since some people started linking this post and interpreting it as "ArenMook hates Unity!", I feel the need to clarify some obvious points.

One dev parting ways from a 300+ person company does not make or break anything.

uGUI started as NGUI with the simple goal of "take something that works, and make it better". That much has been communicated on many occasions, and I talked about it at Unite. After months of development it became a quite different system. Even by Unite 2013 it was very different. Now -- much more so. If by the time it gets released you won't recognize any similarities anymore, I won't be surprised.

As everyone knows, people rarely leave for just "one reason", and that was also true in my case. There were some creative differences, certainly -- but show me a project that doesn't? I'm a perfectionist, and me getting irritated over lack of immediate polish is nothing new. I wasn't keen on some changes, but it doesn't mean that I think the changes were wrong. It just means that they were simply not what I am used to or what I personally deemed as a priority. Note the emphasis. I didn't drive the GUI development. I contributed to it, and my priorities are different than most people's. That too is nothing new.

The most important fact you have to remember is that I've been doing NGUI since 2011, and GUI systems since long before that, and I was simply put -- burned out from doing the same thing. Add to that the fact that I was overworked with a full time job and still had to support NGUI, and all that time I wanted to do game dev instead. Two full time jobs left no time for that, and something had to go. I don't have the luxury of "quitting" NGUI, but I was able to part ways with the other job. Fortunately by the time I lost my mojo the system was in a solid enough state and there were quite a few capable developers doing great things that continue to improve it daily. I have full faith that it will be a solid system when they deem it ready.

I'm sure all of us will use it, myself included.

And for the record, Unity Tech is the single best company I've ever worked at. Great variety of extremely smart people, unrivalled freedom and openness with execs make it second to none.