Unity crash: “type == kMetaAssetType && pathName.find (“library/metadata”) != 0″

Unity’s QA dept needs a smack up-side the head. If you get this bug, you’re a bit screwed – the only “fix” is to go into system settings and wipe Unity’s crud.

Error message:

type == kMetaAssetType && pathName.find (“library/metadata”) != 0

Thanks, Unity, that’s very human-readable and helpful. Not.

(appears to be an Assert written by a junior programmer – or a debug-only Assert that got left in the shipping version(!))\

Problem:

1. Unity’s tech team wrote Unity 3 so that it would open projects BEFORE checking if there was a new version available
2. Unity 4 is NOT backwards compatible; it corrupts projects so that they will NEVER load in Unity 3.x
3. …also: Unity 3.5 will FATAL CRASH if it tries to open a Unity 4 project
4. Unity (generally) is badly written and auto-opens the last project, even if you don’t want to, and EVEN IF ITS CORRUPT
5. Unity (generally) DOESN’T BOTHER to offer any way of starting “safely”

Solution (OS X):

1. Force-quit Unity (not only does it crash, but it hangs forever) – RMB on the icon, hold down alt/option, and the Force Quit option appears
2. run Finder, go to (your user)/Library, aka “~/Library”. If you don’t know how, then do ONE OF the following (either works):
   • EITHER: Start at your username folder (it’s the parent folder of your Desktop folder, parent of your Documents folder, etc), un-break OS X (Apple ships it as broken-by-default): google for “enable see Library folder in Finder”, follow the instructions
   • OR: In Finder’s “Go” menu, select “Go to folder”, and type “~/Library”
     • Inside Library, find “Preferences” folder
     • Find *everything* that begins “com.unity3d.” and delete it (there are approx 20 files, of 2 different file types)
     • Re-start Unity, and it will open the default project
     • …And this time, Unity will offer to upgrade to Unity 4

UPDATE

For bonus points, the Unity 4 “upgrade” isn’t an upgrade: it’s a replacement. I expected it to download “the bits that have changed”. Nuh-uh. One gigabyte download! (try getting that in a hurry, when your project has suddenly imploded in front of you, because of the non-existent backwards-compatibility :( ).

Some idle thoughts…

I’ve seen similar behaviour before when writing very simple OS X apps. There’s some massive bugs in Apple’s code that have been around for 5+ years (and Apple shows no intention of fixing), which cause “startup actions” to happen in a semi-random order, depending on the NAME and NUMBER of recently-opened projects.

It takes very little testing to discover this. If it’s the problem with the Unity software, then Unity needs to seriously improve their testing on OS X – they should have discovered this easily.

But also … why on earth are they using the NSDocument loading system? Apple never finished writing the docs for it, they seem to have never finished implementing it (major bits of the API seem to be missing) – in general, OS X authors don’t seem to use it any more. Probably because it doesn’t work?