Hi, this page comes up when searching the web for ways to stop Reset from doing stuff, so I want to share a very simple solution. I don’t use it for the same reasons than the OP, but there are many reasons for wanting to disable reset and this should work for most of them:
public abstract class MyScript : MonoBehaviour
{
[UnityEditor.MenuItem("CONTEXT/" + nameof(MyScript) + "/Reset", true)]
private static bool OnValidateReset() => false;
[UnityEditor.MenuItem("CONTEXT/" + nameof(MyScript) + "/Reset")]
private static void OnReset() => Debug.LogWarning("MyScript doesn't support Reset.");
}
This works for classes that inherit from MyScript. MyScript could be a ScriptableObject too.
It will completely disable the Reset menu item, so if you or people that use your code use it frequently, this solution might not be for you. Most people I know very rarely click Reset in the menu if at all, so they would probably not notice this anyway. Also, it’s usually not hard to reset things manually; one can usually just create another instance in the worst case. You can still use a Reset() method to set initial values in your scripts.
If you remove the OnValidateReset
method, the menu item won’t be disabled, but it will print a warning letting users know that Reset is not supported instead of resetting. And, if you really need a working Reset, you can do your own Reset implementation by doing something like this:
public abstract class MyScript : MonoBehaviour
{
[UnityEditor.MenuItem("CONTEXT/" + nameof(MyScript) + "/Reset")]
private static void OnReset(MenuCommand command)
{
var instanceToReset = command.context as MyScript;
// Do your own Resetting implementation with instanceToReset.
}
}
EDIT :
I haven’t tested it, but this should work with other menu items, like “Copy Component” or “Paste Component Values”. Just replace Reset with the relevant menu item in the MenuItem attributes.
Also, I feel like I should say this won’t prevent issues with duplicate ids when a whole Object is duplicated. A good solution is outside of the scope of this question, but some ideas involve storing the Object’s own GlobalObjectId when validating, or using Addressables.