I can’t think of why there wouldn’t be many many threads about this unless it was only affecting our project, but the weird bit is that we have two projects running separately and they are both having the issue.
No one on my team that has upgraded to 4.6.1 can save prefabs anymore (i.e. the changes don’t show up in Git at all) and neither can they change the Scale option in the model import settings for a .FBX. It’s locked to 0.01 (not greyed out, but just reverts immediately after defocusing the float field).
Is anyone else having this issue or know of a workaround? I’m concerned that Unity won’t release a patch fix for it if we’re the only ones experiencing this.
I submitted a bug just now using the built-in reporting tool, but it didn’t spit out a bug number. Would it already be in the Issue Tracker for me to find?
We have the same problems, except we can save prefabs. The import settings can’t be changed at all, and the scene saving doesn’t work. Other older projects work normal in 4.6.1
This is not a Unity bug. This happens because UT fix OnWillSaveAssets method. This means that before you can declare it with Void return type and it will save all assets, now it should return paths that should be saved. So if you have this method that have viod return type or this method returns null Unity will not save your assets. To fix it just look for this method and fix it like that:
static string[] OnWillSaveAssets(string[] paths) //Should return string[]
{
//your code here
return paths; // return filepaths that should be saved
}
this behaviour detected form 4.6.0p1 and you can see in release notes:
(638865) - Editor: Fixed AssetModificationProcessor.OnWillSaveAssets checking out files that were not Saved and OnWillDeleteAssets always marking assets for delete.
Hm, my underlying tools framework may be using something like that. I’m not seeing any references to that specific function in our project; do you know if there are other functions that perform something similar?
This happenns because Unity doesn’t verify method signature when calling methods like this. In docs this method declarad with string[ ] return type and guys that use this method with wrong signature now fails, but it would be better if Unity can check method signature before calling method and throw an error.
Or you probably should use explicit method declaration regardles to unpredicable reflection method invocations
We actually do check the signature of the methods in AssetModificationProcessor, but in the case of OnWillSaveAssets the return type is ignored. I don’t exactly remember why I chose to ignore the return type on this, but probably becuase some asset store packages broke.
Even if we did add a check for the return type that would still not prevent the user from returning null and we should handled that gracefully at least with a warning that your scene was not saved.
But in some cases the user does not have to source code of the plugin but only a compiled DLL, so even if the user gets the warning he can’t fix it and the only way for him to save a scene again would be to remove the plugin.
I mean that you should do that long time ago, so that guys who don’t want to do things proper or read docs should get a lot of warning messages in console. You probably should expose thing like that in different way. In this example user have very big error prone. If you can make AssetModificationProcessor abstract with methods that user can override, you will force them to do it right. And on invocation you just instantiate all classes that derived from AssetModificationProcessor cache them at some list and invoke method directly without any reflection that 5 times slower than direct virtual method call.