|
Is there a method to list all instances of a 'Missing Script' after moving/deleting a file, My experiment with junction and a common library of scripts seems to have failed, and left me with quite a mess to clean up!
(comments are locked)
|
|
See the solution to your problem here: http://www.unifycommunity.com/wiki/index.php?title=FindMissingScripts Is there a way to determine the name of a missing script and replace it automatically (using an editor script)?
Jun 18 '12 at 04:02 PM
numberkruncher
AFAIK, that possibiliy got optimized away with 3.5. With <3.5, the referenced file would still be listed as a string in the binary asset (scene, material, prefab, ...) (which often helped us a lot if somebody deleted an asset at some point from the Asset Server, and you wanted to figure out which "Missing Script" was originally referenced. But since 3.5, they switched entirely to GUIDs, so assets are no longer referenced by path/name. There is AssetDatabase.GUIDToAssetPath(), but IIRC it returns null if the asset is no longer in the database. :-(
Jun 18 '12 at 08:03 PM
Wolfram
@Wolfram Would you mind demonstrating how to achieve this using GUIDs? I am not sure if you'll get this follow up comment. I certainly didn't get an e-mail notification of your comment...
Jun 28 '12 at 06:01 PM
numberkruncher
(comments are locked)
|
|
I just read in another post (search "Mass Set Materials") where the scriptor used: Undo.RegisterSceneUndo("Mass Set Materials"); This apparently allows you to Undo effect of your script. Now, regarding you're earlier problem, I too have had that problem, and don't have a solution. I do think using this Undo method might help your experiments though. It is placed in the Start(), I recall. Hope you find your answer - it will help a lot of us, I'm sure.
(comments are locked)
|
|
This is an old problem. I would start with the Component Copier in the Asset Store (a real bargain!), and see how it uses Reflection. The idea would be to look at what fields are on a script to try to match them up with existing scripts and see what fits best. But I don't think you can get at those fields once the script has gone missing (even though they still show up in the Inspector UI. Those are in the library/cache and we don't have (official anyway) API's to get at that. But then, you might look into the meta files and see what might be useful there.http://unity3d.com/support/documentation/Manual/ExternalVersionControlSystemSupport.html Nothing, just the GUID of that particular asset. But if a script got deleted, the .meta file gets deleted along with it, and there is no way to recover the original path from a merely referenced GUID.
Jun 18 '12 at 08:05 PM
Wolfram
Yeah just checked that myself, was gonna delete that suggestion from my post. I had started working on an 'asset vault' system that would catalog scripts for just such occasions as I was tired of running into this problem. Instead I got into the habit of exporting my scenes as packages and archiving them.
Jun 18 '12 at 08:08 PM
DaveA
That vault sounds like a good idea. I seem to remember we got inconsistencies when transfering assets from project A to B via packages in 3.5, since the GUIDs of identical assets were different between projects...(might be their file locations were different, so they got different GUIDs, but so far I didn't investigate this further).
Jun 18 '12 at 08:18 PM
Wolfram
(comments are locked)
|
|
Not sure if I'm following. If you know the name of the script but don't know which objects use it, you can create a script with that name and the following contents: function Start () { print("Script XYZ used by " + name); } Not it was more to find objects that have orphaned "Missing Script" entries.. IE: you have a bunch of objects that use script XYZ.cs, but then you delete that script file, but there are still entries on the objects that need to be 're-connected' EX: Renaming a file outside of the unity project window can break things. also cases where trying to Junction a set of standard scripts across multiple projects will cause the disconnection
Feb 28 '10 at 06:11 PM
davebuchhofer
(comments are locked)
|
