Hello! I’m new to Unity (but not to game engines…I used to write them). I downloaded and installed the free version of Unity3D 4.0.1f2 on my Windows 7 laptop, and tried to get assets to work with version control (in this case, Subversion).
The problem I encountered is that installing a second asset package in the presence of a first asset package seemed to cause changes in both packages that don’t happen if the packages are installed separately and then put into the assets directory!
Here’s my exact chain of events:
Install the C# Game Examples from here (Asset Store url is here)
Inside Unity3D’s Asset view, create a folder called “M2H C# Examples”
Inside Unity3D’s Asset view, move all the imported assets into “M2H C# Examples”
Commit that to version control
Install the Bootcamp demo from the asset store
At this point, there are several files in the “M2H C# Examples” directory that have been changed, but I hadn’t noticed yet, so I continued:
Inside Unity3D’s Asset view, create a folder called “BootcampPkg”
Inside Unity3D’s Asset view, move all the imported assets (i.e. everything except “BootcampPkg” and “M2H C# Examples”) into “BootcampPkg”
Inside Unity3D’s Asset view, rename “BootcampPkg” to “Bootcamp”
Commit that to version control
After noticing that several files in the “M2H C# Examples” directory had changed, I deleted all the imported assets, and installed the Bootcamp demo in an empty Assets directory (i.e. steps 5 through 8).
Enclosed is an archive with four files:
m2h-differences.txt - the output of “svn status”, showing changes to “M2H C# Examples” made by importing “Bootcamp”
m2h-patch.txt - the output of “svn diff” (as you can see, several files have been heavily modified)
bootcamp-differences.txt - the output of “svn status”, showing additional files that were installed when “M2H C# Examples” wasn’t installed first
bootcamp-patch.txt - the output of “svn diff” (in this case, only a few meta files are different, and it’s just guid changes…no big deal)
It would seem that Unity3D’s package-import somehow munges together imported assets if the filenames are the same, although it seems to make cross-asset changes in other cases too.
This would seem to be a serious data-corruption bug, unless I’m missing something. It seems like this would prevent a project from utilizing asset packages from different sources (which seems like it’d affect a lot of typical real-world projects).
I’m not sure exactly how it works internally, but I’ve noticed this problem as well. However, I don’t think the Unity guys see it as a bug, but rather as a feature. It seems that Unity does keep track (although I don’t know how) of where you move things after you import them, so that when you update that package in the future, it will magically place the updated versions wherever those files have gone to in your project.
On the surface this may seem like a nice idea, but it is problematic in the case that you have multiple different packages each supplying different versions of the same asset file. It is especially problematic when package developers include modifications to common files in the “/Standard Assets” folder, or even into your project root folder “/”. Some developers do prefix their asset files with some unique folder name like “/abctoolkit/myfolder/myfile.cs”, but unfortunately not all do.
Another huge problem with the current Unity functionality is when you want to modify a file provided in a package. When you update the package in the future it will overwrite your changes. So naturally most programmers would think to solve the problem by simply moving the file somewhere else, like into a “/CUSTOM” folder. But alas, Unity will still find it there and overwrite the changes anyway, much to my frustration.
What is needed is a way to keep imported packages in individual sandboxes. Perhaps Unity should automatically add a filename/folder prefix for every file in a package. Or even better, Unity could import each package into its own virtual library in your project, which you would access using the package prefix. Something like: NGUI::UILabel().
I’ve not really figured out how to deal with this yet, but for the moment I at least try not to allow any packages to import anything into “/Standard Assets”. If it’s needed, I’ll import it from the standard Unity package that contains it.
This happen to me as well and it’s driving me nuts!, I reuse files but place them in different packages that I want to be 100% independent from each other, yet when I import some of them, the files goes to places they shouldn’t.
I find the “feature” ok, but it’s not useful on every escenario and could be fixed so easy with a checkbox on each file in the import settings to set which files you want to update in your current project and which ones you want to duplicate in the package’s specified path. And an additional one to check/uncheck all of them.