When using third party assets from the asset store that include scripts, it seems not unusual to need to modify the source code (when it is provided) because you want to take the asset in a direction the author did not originally envision.
Ideally it would be possible in all cases to simply derive from their classes and make use of them but at times the architecture will not allow for this.
In my case I am making use of an asset which has (correctly) placed their scripts into an assembly definition and also need to a) create a new class but b) need to modify one of their existing classes to reference my new class.
At present, I have done the following:
- Created a subfolder within their scripts folder called something like ‘MyOverrides’
- Due to the folder structure they set up, this ensures the ‘MyOverrides’ folder is included in their assembly
- Within that subfolder, create any new classes within ‘MyOverrides’
- Also within that subfolder, copy any modified versions of the original classes, removing them from the original location
My reasoning is that it at least attempts to very clearly indicate (to me) which files have been modified or added, and to separate that from the imported code as much as possible while still keeping it within the same assembly.
But… I really dislike this. I would much prefer to have any scripts I need to maintain be in a completely separate folder, entirely outside of their folder structure, but still be able to have it appear within their assembly.
My question… what is considered best practice when it comes to modifying asset store scripts? In particular, knowing that I:
- Want to maintain as clean a separation between my code and theirs as possible
- Want to minimize headaches when updating their asset to pick up updates and bug fixes
- Want to allow my code to exist within their assembly (because the design of the package disallows other options)