Updating Unity stuff is overwriting scripts I've previously edited?

OK, I don’t really get how to work around this: I have various asset packages and stuff in my game that I was told to add when setting it up for VR and stuff, such as an Oculus Player Controller and a normal Player Controller, and I’ve edited a couple of the scripts that came in the Oculus assets package and Standard Assets package to get some stuff working the way I wanted (don’t remember what ones), but now I’m being told I need to update the Oculus Packages and the like to get VR working again in my game (it broke with the latest build), which is overwriting those scripts I’d changed.

So how to I update things like the Oculus Utilities and Standard Assets when I’m told I need to get the latest version for to make VR work properly with the latest Unity builds and whatever but not overwrite the scripts in there that I’ve already changed for my game?

Just don’t edit anything from an external package. The folders are called Standard Assets for a reason. Assets receive a unique assetID when they are created for the first time. This asset id identifies that asset anytime no matter where it is moved within your project as long as the meta file moves with it. When the meta file is lost or you duplicate an asset, the newly imported asset will get a new assetID.

Of course if you changed an asset that you didn’t create and replace the files with updated files from the original source, your changes will be gone.

If you want to change / extend / alter an asset from a package you usually have two options:

  • Create a copy of the asset in your own assets. That way it will get a new asset ID and from now on is seperate from the original asset. Of course updates to that particular asset won’t affect your copy (but that’s what you wanted anyways)
  • The second option, if we talk about scripts, is to create a derived class in your normal assets that has the script from the package as base class. Now you can extend / alter your derived class as you wish. Since it’s a seperate asset it’s safe from any package imports. However not every class can be changed the way you want since the original author didn’t think about extendability so you might need to copy large parts from the original script to actually change the behaviour. This solution also has another issue: If the original author did some “breaking changes” to the original script you may need to adjust / fix those issues in your derived class.

So the most reliable way is to duplicate the asset you want to change / modify. Though even then when it depends on other assets the functionality can break when you update those dependencies. So it’s never a guarantee that you don’t have to do some adjustments.