Shared Preferred Types

NodeCanvas Forums General Discussion Shared Preferred Types

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #11908
    bglanzer
    Participant

    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.

    #11909
    Gavalakis
    Keymaster

    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

    #11910
    bglanzer
    Participant

    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

    #11915
    Gavalakis
    Keymaster

    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

    #11917
    bglanzer
    Participant

    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.

    #11925
    Gavalakis
    Keymaster

    Thanks for sharing the code πŸ™‚

    Join us on Discord: https://discord.gg/97q2Rjh

    #14583
    timv
    Participant

    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?

    #14586
    guyboots_thunderbro
    Participant

    – 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?).

    #14590
    Gavalakis
    Keymaster

    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

    #14594
    timv
    Participant

    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

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.