koobas.hobune.stream
Importing new versions of packages?
My team uses a set of tools we created -- and it's on version 1.71. People on my team import it into their different projects via a package. But just now I've added a super helpful, awesome tool that everyone using this package should use. In it, I've got some changes to old scripts, and some new stuff that needs to be linked into the old stuff.
The problem is this -- when they import the new version of the same package, it seems to import the new versions of the old scripts in addition to the old ones -- but I'd rather they just be replaced, as long as they're in the original toolset's folder structure. Is there a way to have this happen? Right now, whenever someone tries to update their version of the tools, it causes things to become unlinked, creates duplicate versions of files, etc etc. Does giving my package the same name as before do anything to change this? For example, if I try to import a file called "Tools v1" and then import "Tools v2" there will probably be an issue. But if I am always just importing a package named "Tools", then does that change anything?
So, I ran some experiments myself. For the purposes of this project, I created a package with one script, tool.cs. I attempted to import it into a project with different names (changing the contents of the cs file in the second version), and with the same names, and with variables assigned in the inspector, and putting the script in different folders.
My conclusion is that the name of the package itself is irrelevant. The important thing is the name of the files. There are a few gotchas, as I suspected:
If you replace a file of the same name, regardless of location, the variables are reset, even though there was no change in the prefab. This could be useful for resetting packages by reimporting them, but for updating existing packages (where the user customized the contents of the package), this could be dangerous. My suggestion is that there be a popup window that asks you if you want to retain your old values on scripts/prefabs x, y, and z seperately.
Instead of duplicating scripts in different locations, Unity will keep a folder structure, but replace a script of the same name in its original location, with no warning. So if you have a bunch of scripts in one folder, but then you move them to another folder in another package, they won't be in the new folder. They'll be modified in the original one.
So, this makes my plan of having a continually updating toolset more difficult, principally because any modification to a "module" in my toolset, or any use of any customizable tool by another user will be overridden by the default values, when the user re-imports the package. For me, this is a negative thing.
Here are the results of my experiments, by the way:
1) New project + tool_1.unitypackage
+ tool_2.unitypackage (script modified) = correctly replaced
tools.cs script.
2) New project + tool.unitypackage +
tool.unitypackage (script modified)
= correctly replaced tools.cs script.
3) New project + tools.unitypackage
(then assign a Texture2D in the
inspector) + tools.unitypackage
(modified variable name for texture)
= correctly replaced prefab and script, but the value texture
variable with the changed name gets
replaced with the value of the new
package.
4) New project + tools.unitypackage
(assign a Texture2D in the
inspector) + tools.unitypackage
(modified tools.cs and prefab placed
in a new folder) = No warning, but
the old files are replaced, and the
new folder (with the same scripts)
appears and is empty.
5) New project + tools.unitypackage
(assign a Texture2D in the
inspector) + the exact same package
= Texture value reset to original, even though there was no change to the script where the variable itself existed.
