NodeCanvas Forums › General Discussion › Shared Preferred Types
Others may have a better work around for this and if you do please let me know.
I often hear the complaint that Preferred Types are stored within Unity’s Editor Preferences and editor preferences are not something commonly shared within a projects repository. One work around I have made is to edit the PreferedTypesEditorWindow and load/save Preferred Types to a file, which is stored in an Editor Resources folder, before Node Canvas does. This file is checked into the repo and unknown types no longer becomes an issue for other members of the team working from the repo. The problem is that every time we update Node Canvas I need to go in and make those changes.
It would be nice if this functionality was at least an option within the Preferred Types folder.
Hello,
There is already the ability to export/import the PreferredTypes list to a preset file (basically a json). Of course this is not automatically read, and it has to be manually imported back, but it can be part of a repository and shared with other users of that repository.
Have you tried this export/import preset ability?
Let me know π
Thanks.
Join us on Discord: https://discord.gg/97q2Rjh
Yes, the exporting/importing works fine and I think that’s what our workflow was before. I added the automation because developers would often times forget to export when they added new types. It also removed the need to always have to import when new types were added. It seems to be pretty popular with other teams that use node canvas as well, when they hear about it they often times ask for the code to implement it themselves.
I actually use the same functionality for the automation, just before I the typeList is created in OnEnable I load in the shared file and add the types. I then just added a function to export types to the file when save is called.
I think a useful option be be auto export/import and you can specify the directory/filename, which could be saved to editor prefs, that way its a one time setup for useful automation option.
Thanks
Hey,
Thanks for the further explanation. I think it makes sense, I agree.
I will handle this differently than it now is done in the next version. Probably similar to your suggestion here π
Thanks again.
Join us on Discord: https://discord.gg/97q2Rjh
That would be awesome. Here is the code to how I’m implementing it. I’m assuming you would want to have some sort of UI input for the directory/filename you want to save.
1 2 3 4 5 6 7 8 9 10 11 12 |
//Loading void OnEnable(){ #if UNITY_5 titleContent = new GUIContent("Preferred Types"); #else title = "Preferred Types"; #endif LoadSharedPreferedTypes(); typeList = UserTypePrefs.GetPreferedTypesList(typeof(object)); search = null; } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
//Saving void Save(){ UserTypePrefs.SetPreferedTypesList(typeList); SaveSharedPreferedTypes(); } #region Change const string NodeCanvasTypeDir = @"Assets/Editor Default Resources/NodeCanvasPreferedTypes.typePrefs"; void SaveSharedPreferedTypes() { System.IO.File.WriteAllText(NodeCanvasTypeDir, JSONSerializer.Serialize(typeof(List<System.Type>), typeList, true)); } void LoadSharedPreferedTypes() { var json = System.IO.File.ReadAllText(NodeCanvasTypeDir); typeList = JSONSerializer.Deserialize<List<System.Type>>(json); Save(); } #endregion |
Thanks for sharing the code π
Join us on Discord: https://discord.gg/97q2Rjh
I see this thread is pretty old (2,5 years), but I would like to bring up this issue once more. (hope you don’t mind me reviving such an old thread for this purpose)
We’re experiencing the same workflow issue described here. I think it makes sense to auto import/export or auto save/load these typePrefs in such a way that they are part of the project. This way no one can forget about exporting and other people don’t need to run import after pulling the latest changes from their repo. Could you reconsider adding something like this?
On top of this I wanted to ask two more things regarding these preferred types:
– Would it be possible to move the generation of AOTClasses.cs and link.xml to an automated build step, so you don’t have to manually trigger this?
– Would it even be possible to automatically detect which types are needed? What would it take to do that?
β Would it be possible to move the generation of AOTClasses.cs and link.xml to an automated build step, so you donβt have to manually trigger this?
β Would it even be possible to automatically detect which types are needed? What would it take to do that?
I can get behind both of these suggestions!
Weβre experiencing the same workflow issue described here. I think it makes sense to auto import/export or auto save/load these typePrefs in such a way that they are part of the project.
I also agree that this would be great, but it could cause some annoying merge conflicts if two people add different types — unless the type format is something amendable to version control (.yaml?).
Hey,
The way I am going to handle this for the next version is to automatically read the first “.typePrefs” file found in any “Resources” folder and automatically load the types in that file. Also changes you make will automatically be written in that file (if it exists) as well.
As such you will only need to export the types list once and save that file into a “Resources” folder. From that point and forward, it will be used automatically.
Regarding making the generation automatic as part of the build process, I am not sure about this yet. I will have to see whether there is a suitable unity callback I can use for that first.
Regarding automatically detecting the types that are needed, one way for that that I was thinking about, is to add a function in the graph editor toolbar, which will scan the graph for types used and add them in the preferred types list. This will of course need to be done per-graph, but it’s still better than manually searching through the graph π
Let me know what you think.
Thanks!
Join us on Discord: https://discord.gg/97q2Rjh
Hi Gavalakis,
If the file must be in a Resources folder, that would mean it will be included in your builds. That sounds a bit strange to me. If you have some way of preventing that, than this sounds awesome. Otherwise I think I’d prefer a fixed path over the Resources solution.
About the callback, maybe this could work: https://docs.unity3d.com/ScriptReference/Build.IPreprocessBuildWithReport.OnPreprocessBuild.html
I don’t know if you could add code/.cs files in that step. I haven’t tried.
Your suggestion of scanning the graph automatically would already help a lot! I was wondering if it would also be possible somehow to find all graphs in the project.
Thanks,
Tim