I upgraded one of my project folders from 4.2 to 4.3 (running it in 4.3 now). Now, when I try to build my game I’m getting these three errors in my console (and the game does not build successfully):
6 of "An asset is marked as dont save, but is included in the build: UnityEditor.HostView:OnGUI() "
1 of “Building - Failed to write file: sharedassets0.assets
UnityEditor.HostView:OnGUI()”
1 of “Error building Player: Couldn’t build player because of unsupported data on target platform.”
As far as I know, I did not change anything from 4.2 to 4.3. I could build the game just fine in the previous version. Any idea what might be causing these errors?
Not sure what upgrading from 4.2 to 4.3 might’ve done to your project to suddenly invalidate the build, but it sounds like maybe you are referencing editor resources that are not supposed to be saved in an object that Unity is attempting to serialize - do you have any editor types like GUIStyle or… well, anything prefixed GUI I guess, being referenced by a MonoBehaviour derived class? Maybe something that’s only being used for custom editor/property drawer purposes?
If so, then try encapsulating them between #if UNITY_EDITOR … #endif directives and see if that doesn’t clear the errors.
Update: Thank you very much Roland, that worked! And I’m able to at least build my game now. I had two variables set in two of my scripts that used the GUISkin type like this:
//Set another GUI skin in the inspector for the OnGUI() function in this particular script
#if UNITY_EDITOR
public var setGUISkin2 : GUISkin;
#endif
So I had to wrap the directives around it as well as the code in my OnGUI() function like this:
function OnGUI(){
//Set the GUI skin
//Note: The GUI skin is also set in the "Unitmanager" script, but apparently wherever you have the OnGUI() function, the
//GUI skin needs to be re-defined.
#if UNITY_EDITOR
GUI.skin = setGUISkin2;
#endif
}
If I change my GUISkin type variables to private, instead of public, I noticed that I don’t need the directives anymore in order for the game to build. However, even if I assign the variables the GUI skin I want, I still can’t use them unless I can GUI.skin = xxxx in the OnGUI() function. Which it won’t let me do without the directives now.
Now my question is, since I have to have the directives around my variables and code in order for the game to build, now when the game runs, my GUI Skins don’t get applied. How might I apply my GUI skins now in a way that Unity approves of?
Overall, I don’t understand why the directives are needed now, whereas they were not in 4.2? I don’t understand what the directives are doing. Could anyone elaborate on what exactly they’re doing – I guess I don’t really understand serialization either.
Anyways, posting this so that if anyone else has this problem, it might help them.
As far as directives go: They’re just ways of telling the compiler what to do with blocks of code. In this case the #if UNITY_EDITOR … #endif directives are telling the compiler to only include that block of code for builds we make that are defined as being for the editor (somewhere Unity defines the UNITY_EDITOR symbol when building for the editor). Deployment builds will have that code excluded from the build, which will break any code that’s being included which was referencing it, so be careful (like you mentioned you also had to exclude the assignment in your OnGUI function).
Serialization/deserialization in general is the process by which we translate data from a specifically typed form to a general stream that we can save/load or transmit and get back into our typed form. So an integer that you can do math with might be serialized into a string that you can store on disk, then later load and deserialize back into an integer that you can do math with. Unity uses this type of mechanic to preserve your data between sessions (when saving/loading a scene), assembly changes (when modifying code that requires a recompile), entering/exiting playmode from the editor, etc.
Now - more to your issue: It would appear that, for whatever reason, Unity has specifically marked the GUISkin type to fail serialization in the latest version. The variable not failing when marked as private makes sense because private members are by default ignored in the serialization process (unless marked with the @SerializeField attribute). So let’s try and play ball with this new constraint.
If you are only using that GUISkin member for editor purposes and don’t need it to be deployed, then the directive path to exclude them is the most appropriate. If for some reason you need it to be deployed, then we just need to get around the serialization issue: you can mark it as private and expose it via a public getter, making sure that it’s initialized properly before doing so, or you can have it public and decorate it with the @System.NonSerialized attribute - the outstanding issue being that you won’t be able to preserve its data when serializing so will still have to initialize it properly in runtime somehow.
Could you elaborate on your scenario? Is the setGUISkin2 member defined in a custom editor that you are referencing in a MonoBehaviour.OnGUI function?
Excellent information Roland, thank you, that helps me understand it a little bit better.
So, I’m not quite sure if I can explain it correctly, but I can elaborate a little more on the issue. As far as I know, the setGUISkin2 member is not defined in a custom editor – however I’m not quite sure what a custom editor would be? The variable is defined in a javascript script named “Buildbuilding”, which I think makes it a member of the “Buildbuilding” class correct?
I made setGUISkin2 public so that I could assign it a “myGUISkin1.guiskin” object/asset via the inspector. The GUI skin is a normal Unity gui skin that you can create, like you would create a new material or prefab or script. As far as I know, they are not “custom” gui skins (but I could be wrong). They are simply normal gui skins, although I do have 2 or 3 of them now. And they are located in the following folder path: Assets/Editor/Editor/EditorAssets. Don’t ask me why I have an “Editor” folder inside another editor folder, but I do lol.
I would like my gui skins to be deployed, not just in the editor, but in a deployment build. So I see that you said:
So, I think I’m wanting to try marking the variable as private and then exposing it via a public getter, like you mentioned. How exactly would that work? Specifically, I’m not sure how to expose it via a public getter. I don’t care if it’s not exposed in the inspector, as long as I can assign it properly somewhere and then use it in my OnGUI() function. The goal is to be able to use it in a deployment build as stated above. I’m not sure what not being able to preserve its data when serializing will mean in practice, but I’d like to try to work around it.
Just an object you define that determines how a script shows up in the inspector - if you didn’t explicitly implement one yourself then its not an issue.
Ah - not very familiar with Javascript, but I think you are correct.
That may be the source of your issue right there! There are a few special folder names that Unity looks out for which determine how Unity handles their contents. Anything included in any folder named “Editor” will be compiled in a separate assembly referencing the Editor API, which I’m fairly certain gets excluded from deployment builds. It could be that referencing a resource contained in an Editor folder is what is breaking your build. Try moving the referenced GUISkins into a folder not named (or contained by a folder named) Editor and see if that doesn’t solve things.
I’m just seeing that GUISkin derives from ScriptableObject. I don’t have alot of experience using ScriptableObjects but my understanding is that Unity will only serialize the references to them, not the actual data, so… well, I think/hope moving them out of the Editor folder scope will solve things.
Getters and setters are just functions that you use to wrap around… getting and setting a private variable. Their benefit is that you don’t expose a variable to direct modification and can introduce your own logic if it needs special handling (like validating data before setting or checking for null and initializing before getting). Since I don’t really speak Javascript I’ll just point you to this guy’s blog for more info.
Let me know if moving those files solved the issue!
Just a quick update. Unfortunately moving the GUI skin objects out of the Editor folder and into a different folder did not fix the problem. I tried putting them in a completely new folder underneath “Assets”, and I also tried placing them in the Resources folder on the off chance that that might work. Neither of the locations worked unfortunately.
So, I guess I’m left with trying to implement getters and setters (which I havn’t attempted yet). The journey continues lol.
Well, I’ve tried recreating your issue both in C# and JS but I don’t see any errors and everything seems to work just fine. I’d really like to get to the bottom of this though - would you be willing/able to send me a copy of your project? Or if that’s too much then maybe just the script that seems to be the issue and the GUISkin that it references?
I don’t know why I didn’t think of testing this before now, but I simply created a brand new Gui Skin, and assigned that to my exposed variable in the inspector. Then I tested building the game again and it worked! It didn’t throw any errors when using the new gui skin asset.
Now granted, I have to redo all of my button and text settings in the new gui skin, which is a pain in the neck – but it’s doable I suppose. I don’t think I should have to make a new gui skin just because of the upgrade, but I guess the old ones either got corrupted somehow with the version upgrade to 4.3 or 4.3 just has a thing against old gui skins for me.
As of right now, my problem seems to be solved, as I’m able and willing to simply re-do all my settings in the new gui skin. If for some reason this doesn’t end up working Roland, I’ll post here again. I appreciate you being willing to look at it for me though I know it doesn’t really solve the problem (and I’m curious what’s actually causing it to fail), but if I can do an easy workaround like simply creating a new gui skin, then I will. I’m going to chalk this up as solved for now (at least until tomorrow when I can test it more fully lol).
I’d be willing to send you the script and the gui skin if you really want me to? But to be honest, I wouldn’t be comfortable sending you most of my project, as I have assets that are not legal to share, and I’d have to sift through and remove all of the ones that aren’t before sending you the project, and that would take quite a bit of work. No offense But I will do it, if necessary.
No worries, it sounds like you’ve found what the source of the issue probably is. I do see the release notes for 4.3 mentioning work that was done on GUISkin, although nothing particularly stands that sounds like it would’ve ended up invalidating GUISkin objects serialized in the last version.
So that was interesting. I’d still be a bit concerned about having deployed resources residing in an Editor folder, but you’d know what to do now if that becomes a problem.
But I will do it, if necessary.