- Home /
Importing assets breaks my game
Hi all, I'm really having troubles when importing assets from the asset store, because it sometimes just breaks everything I was doing.
Example: I had imported the sample assets, and then imported the Big Environment Pack 1.5, and then suddenly I get tons of errors because apparently this lead to conflicts between scripts with the same name.
Now because this was an import, there is no way to undo the operation. So all I can do is to delete all the conflicting assets from my project and re-import them.
Why on earth would scripts in different packages end up conflicting? Is this a design flaw in Unity, or is there a way to circumvent this?
$$anonymous$$ost possibly same "Common" asset is being included in each of the asset pack.. If they are at different paths, it could just be "duplicated". Usually what i do is to import the asset in a clean project, and only take whatever i want out of it..
unselect files that are common in the asset importer. It is not a design flaw. People who upload assets to store gives you all required scripts necessary for their package. One guy doesn't know what other guy uploads with his/her package.
It is up to us to unselect all duplicates
Unselecting is fine, but an asset like the big environment pack is just huge. It would take ages to deter$$anonymous$$e which are the duplicates. At least a small message, or an icon, or something to warn you in the import window would be welcome. And if unselecting duplicates is a common workflow, then an "unselect duplicates" button would at least make sense.
Still, I can't believe things are called "packages" and they don't use their own namespace. From an OO perspective, that's a design flaw.
If you consider this as design flaw, I will tell you in a real-world scenario, A project that I am working which has like around 300+ scripts with more than 4000+ sprites and a guy specifically who manages the project(knows what should actually be imported in to the project). Consider importing a project will just have to go through each and every script to check[this will take time ages, if the you want your feature]. On top of it, A class name can be different to a file name. Whenever you import asset you should be solely responsible for what assets you have in your project.
In you case sample assets have scripts which are also available in BigEnvironmentPack.
If unity keeps checking for duplicates, how will a guy in asset-store can update his package to next version. Unity will check for duplicates only to see for an updated asset.
Answer by cmonroy · Nov 17, 2014 at 08:35 PM
For what I've seen is a common isue and at such most asset providers ask you to import their stuff into a fresh new project. But it gets even worst:
Say you have worked out lots of animations, but the imported asset contains animation clips with the same name. In this case, your animator will use the most recent animations (the ones you just imported) and no the ones you setted up earlier. If the file that contains the animations have the same name, the newest one is not imported -which may cause its own problems when using the new asset.
Call it a bug or unwanted feature, but this is how Unity3D works :)
Indeed. Overwriting the file in explorer rather than reimporting seems to have better results with regard to animation and retains existing references/setup. It is only required then, to add the animations to the Import tab. If you import to a different location you can still access the animations and In $$anonymous$$ecanim Animator window, by clicking a state you can drag and drop whichever animation you wish, even one from a different model. Of course, as it's an asset, a fresh project is the best way to avoid unexpected problems.
I'm not sure if I understand the workflow. If I import into a fresh project, the asset will only be available from that one project won't it?
Let's say I'm working on project A, and I need an asset. I create a new fresh project (let's call it B) and import my asset into this.
Now how do I access assets in project B from within project A?
Assets usually come with lots of superfluous things to show off what it looks like. For instance, demo scenes with objects and scripts that you probably don't need.
Once you have identified whatever you really need in your project, create a new folder inside the asset you are testing, move the things you want there and export it. Then open your project and import the needed stuff... The principle of "if you don't use it, you don't need it" applies here. Besides, those extra things take space and resources.
Once you have an ongoing project, you never ever import a new asset directly to your project or risk breaking what used to work with what is somebody else's demo. Even though version 4 introduced the concept of "namespaces" to alleviate this, the hard truth is that some asset producers don't care about how their asset are going to work along with somebody else's.