Feature Request Name missing Scripts, PLEASE!!!

What year are we in?

How hard is it to create a mechanism that provides the name/class of a missing Script component?

It's your editor, Unity, that drops these references, seemingly randomly, during user "upgrades".

So the least you could do is provide a message that says: Missing Script named: myMissingScript

PLEASE!!!

So frequent, so painful, so unfunny, so annoying.

 

Really really hard. This means that EVERY asset, including assets baked into Addressables, uploaded on websites, content delivery systems, exported packages, every single item would need to be touched to update this information when you decide to rename your class, organize your namespaces, etc.

Classes and namespaces get renamed all the time. It is part of Good Code Gardening(tm).

That's why Unity uses a GUID that is intended never to change.

The only other alternative is what we use every day: source control.

When a file goes missing, track down the GUID (easy with source diffs) and then find it in your history.

--------------

SCRIPTS OR ASSETS ARE MISSING OR BLANK

Some info about Missing script warnings, broken prefabs, GUIDs, renaming GUIDs, etc:

https://forum.unity.com/threads/problem-with-git-and-missing-scripts.1090876/#post-7024801
https://forum.unity.com/threads/scr...ead-after-loading-editor.998413/#post-6487297
https://forum.unity.com/threads/scr...ead-after-loading-editor.998413/#post-6488230

EVERYTHING in Unity is connected to the above GUID, which is stored ONLY in the metafile, and hence why the metafiles ALWAYS MUST be source-controlled.

When Renaming: It is super-easy to inadvertently change the GUID by renaming outside of Unity. Don't do that. Instead:

- close Visual Studio (important!)
- rename the file(s) in Unity
- in Unity do Assets -> Open C# Project to reopen Visual Studio
- now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!

If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.

--------------

PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL

Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

https://forum.unity.com/threads/prefab-links-keep-getting-dumped-on-git-pull.646600/#post-7142306

I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.

Here is how I use git in one of my games, Jetpack Kurt:

https://forum.unity.com/threads/2-steps-backwards.965048/#post-6282497

Using fine-grained source control as you work to refine your engineering:

https://forum.unity.com/threads/whe...grammer-example-in-text.1048739/#post-6783740

Share/Sharing source code between projects:

https://forum.unity.com/threads/your-techniques-to-share-code-between-projects.575959/#post-3835837

Setting up an appropriate .gitignore file for Unity3D:

https://forum.unity.com/threads/removing-il2cpp_cache-from-project.1084607/#post-6997067

Generally the ONLY folders you should ever source control are:

Assets/
ProjectSettings/
Packages/

NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)

Setting git up with Unity (includes above .gitignore concepts):

https://thoughtbot.com/blog/how-to-git-with-unity

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It's simply ridiculous not to back up.

If you plan on joining the software industry, you will be required and expected to know how to use source control.

"Use source control or you will be really sad sooner or later." - StarManta on the Unity3D forum boards

 

If Rider can do refactoring throughout a project in less than a second, I think Unity can manage it.

Associate the GUID with the name of the Class, in a separate Dictionary that serves ONLY this purpose. Update only incrementally, when changes are made. This isn't that hard. Surely!!!

This is unacceptable user pain and inconvenience.

We shouldn't need to go through gits or versioning systems to make amends for balls that Unity frequently drops, all too frequently, too.

 

I don't mean to sound trite, but this is on Unity to fix this, and thousands of other things.

We've all made excuses for their tardiness over the last 6 years, waiting patiently for the nothing burger that's DOTS.

That time is over. Joachim's on sabbatical, Acton has gone.

it's time Unity cleaned up its act and got back to the basics, and finished off whatever it is they plan to do with DOTS.

They must learn to walk and chew gum, like the rest of us.

 

What exactly is the "upgrade"?
Is it reproducible? If you have old version, and do the update, and the script goes missing => submit a bug report.
I mean that is common sense. If I were to do such an update and it broke my project I WANT TO KNOW WHY!

That's another reason why we use source control. You can check in all changes before the "update". Then do the "update". Then check what files have changed and even what lines. Then you can reason about why this or that change happened and what could possibly cause the script to go missing.

If you do that, but don't understand why this happened, you can come here with a proper problem statement and ask why this happens and how to fix it.

If it's your job to be a developer, no matter which technology and how much it bugs you out, you should always be on the look out for a solution. That's just going to repeat the problem in the future, resulting in more frustration and anger.

As they say: the problem sits right in front of the screen.

 

Again, I'm not on the QA team.

This has happened to me (and many others judging by google results) dozens of times, across dozens of upgrades.

It's never the same objects that it happens upon. So there's no consistency to it.

I'm not here asking for a solution, this is a quite explicit request that Unity, seemingly unable to fix this problem, find a way to make this consistently inconsistent problem less onerous on us users.

I hope you understand that's why I've tagged this with a Feature Request rather than as a Question.

 

Yeah, but it's your job to be a Unity developer, isn't it?

To that end, it's your job to analyze issues and come up with a solution or work around. You can keep complaining, and there are good reasons to do so when there really isn't a solution. But here, the solution is entirely in your hands.

Every instance of a "missing reference" I had was due to a user issue. Meta files out of sync, refactoring broke it, making changes to assets outside of Unity, copying assets from another project, scripts were changed while there were (unrelated) compile errors.

Most pervasive where .meta sync issues (GUID keeps changing). I'd watch out for those first. Source control quickly reveals those.

 

No, don't. Unity just refuses to reproduce stuff these days. Even if QA does reproduce the issue, then a developer comes, says he can't repro and they close the bug report. Bug reports are a waste of time.

https://issuetracker.unity3d.com/is...g-the-opened-scene-with-unity-version-control

 

I reported a dozen bugs in the past couple months and about 25% are fixed (one crash bug), 50% are still being looked into with some marked as "reproduced", and the rest were my fault or closed as won't fix (understandable).