Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Best practice for modifying asset store scripts

Discussion in 'Scripting' started by lpye, Apr 24, 2019.

  1. lpye

    lpye

    Joined:
    Aug 2, 2012
    Posts:
    30
    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)
     
  2. lpye

    lpye

    Joined:
    Aug 2, 2012
    Posts:
    30
    *bump*
    Any suggestions? Anyone want to discuss how *they* do it?
     
  3. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    If they don't abstract and virtualize their classes/methods then you're basically stuck with just modifying the code directly. This is only really a negative thing if there are large or regular updates expected from the asset that you are interested in taking.