koobas.hobune.stream
Are all ScriptableObject assets included in the build?
Hi There
I'm thinking of storing some editor data in some ScriptableObject assets but as this data is not required by the game itself, will Unity know that this asset isn't used. On the flip side, can I load an asset manually that DOES need including and will Unity know to include this asset - would it need to be in the resources folder?
Thanks H
If I use AssetDatabase.CreateAsset() in my EditorWindow to create an asset based on a ScriptableObject subclass I think I'll have no choice but to load it from the Resources directory in actual fact, so I think that, with the answers below answers my question!
Well, your question is not that clear what assets you're talking about. The ScriptableObject classes are all included like i said in my answer. Serialized instances that are stored in .asset-files are something different. They behave like any other "data"-asset like NOAA_Julien explained.
The asset doesn't need to be stored in a Ressources folder, you can assign it to a reference variable of another script in the scene.
public class $$anonymous$$yDataObject : ScriptableObject
{
public string myString;
}
public class $$anonymous$$yScript : $$anonymous$$onoBehaviour
{
public $$anonymous$$yDataObject myData;
}
In this case when you drag&drop the serialized asset onto myData of an object in a scene the scriptable object instance is referenced and will be included.
@Bunny83 sorry if the question wasn't clear. I want to have some Configuration Data for an Editor or EditorWindow - I have not yet decided which - that will persist from load to load and scene to scene, but I don't want to have this data in my game. $$anonymous$$y understanding is that if I subclass ScriptableObject I can then use an instance of that to create an asset from my Editor/EditorWindow and load it if it exists when the Editor appears.
The Editor/EditorWindow I create will generate assets itself, and I was thinking I'd have to load these manually, but of course - as you point out - I can dop them onto members of that type where I need to use them, which is $$anonymous$$UCH nicer :)
Thanks.
If no scene objects reference a script, Unity is pretty good about cleaning those up when compiling - they won't be included in your game. If a gameObject or any script in a gameObject references an asset, it will be included in the game. The Resources folders are only for if you want to reference an asset with Resources.Load at runtime. If you're ever in doubt about whether a needed asset is there, just compile (it takes about 30 seconds) and run the game.
And to be clear, all Resource folder assets are included, regardless of reference.
Sure, this was why I initially thought I'd need to store any asset created with AssetDatabase.CreateAsset() in the Resources folder, but as Bunny83 points out, the Asset can be dragged and dropped just like any other asset!
In normal Unity builds (Standalone, Web) all (runtime) classes are included in the build. Unity compiles all scripts into a .NET / Mono DLL. There is a DLL for each compiling group (Standard Assets / editor / normal script) and for each language you're using. If you're mixing Unityscript and C# and have some scripts in Standard Assets and also some editor scripts written in C# and UnityScript you will end up with 6 DLL files. only 4 will go into the build since the editor DLLs only work in the editor.
Assembly-CSharp-firstpass.dll
Assembly-CSharp.dll
Assembly-UnityScript-firstpass.dll
Assembly-UnityScript.dll
You can find those dlls in the standalone build here : $ProjectName$_Data/Managed/
Unity have to include all scripts since you can use reflection or string based functions to access classes. Just think of Addcomponent("MyClass")
Mobile builds have the special option to strip unused code from the build but when you use reflection to access stripped classes it will crash. As far as i know the string based function calls will work as long as you call it with a string literal. It you build the string at runtime Unity can't detect that you use the class and would strip the class. That's why it's an optional feature in pro and "can" be enabled ;)
Maybe i'm wrong how the codestripping exactly works but i guess it works like that ;)
ps. in webbuild the dlls are within the compressed package. As far as i can remember someone managed to "decompress / disassemble" such a package, so your stuff is not "safe" especially the code.
Just for the record:
To create an instance of a ScriptableObject at runtime you normally use:
// C#
ScriptableObject.CreateInstance<$$anonymous$$yScriptableObject>();
// or
ScriptableObject.CreateInstance("$$anonymous$$yScriptableObject");
// or
ScriptableObject.CreateInstance(typeof($$anonymous$$yScriptableObject));
This will create a new instance of that class similar to AddComponent() but since ScriptableObjects can't be attached to GameObjects you have to create it that way.
If you have a serialized instance (created in the editor, saved as asset) you would use Instantiate() to clone the initialized instance. If you use Instantiate on a $$anonymous$$onoBehaviour the GameObject it's attached to is also cloned.
Sure, but the assets used in my EditorWindow I imagine I'll be using AssetDatabase.LoadAssetAtPath(). Of course if there's a better place to store settings required by editor windows then please shout loudly! :)
Well, it depends on what "settings" you want to store. If you have settings that are valid for your EditorWindow itself and not just for a specific instance you're editing with it, use EditorPrefs. But if you want to store data for a specific object in the scene or a prefab you have to use something like a ScriptableObject and store it as a seperate asset.
@Bunny83 Sorry, I maybe should have put the use-case for this. For our RPG we are working on, many of the items follow a pattern which allows me to construct a range of items based on some predefined characteristics. We're doing it like this because we can then know the range of stat modifications up front for play balance and because there's only two of us and a modest item set generates around 3000 items, not countting specials or rares.
This means there are several structures we iterate over to build the real item data. This data doesn't need to be loaded in the game although I could generate the item data on game startup but I think that might cause problems for the quest system, so I want the data to persist in the editor so I can edit it and then recreate all the generated game items at the click of a button.
As of this evening I've been tinkering with an EditorWindow that loads or creates an asset from a ScriptableObject that contains the generation information. It seems to work fine - though I do wish the Editor GUi had a list control!!
I looked briefly at EditorPrefs but the data is limited so a ScriptableObject and EditorWindow is the direction I've gone with this. We did have the generation outside of Unity but I had to duplicate some structures and it was getting rather cumbersome to update - this will be much better!
This is the EditorWindow I've ended up with...
http://www.bovine-software.co.uk/Images/item_generation_window.png
But it feels like a lot of work to get there!
If they are being referenced from the scenes or if they exist in Resources folder, then yes, I think so. Otherwise I am unsure. I wouldn't expect them to be included since they can't be used if they aren't referencable. I guess you could do a quick test project/scene and export the game without a scriptable object, then add a scriptable object and compare the exported games?
You can use this script to see if any objects in your game actually use it and if not clear up your project.
http://forum.unity3d.com/threads/100399-How-can-I-find-what-objects-are-using-another-object
Be warned there is no progress bar on it yet so you just have to be patient and wait for it finish.
