Is Project Active and Package Support?

[jeffcampbellmakesgames]

Hi there, I was wondering if this project is still active and maintained? Many of the open issues are fairly old and/or or haven't been updated in several months.

If it is active, I'd like to make a couple of suggestions for making this library easier to be referenced as a dependency for other tools, both internal and open source.

• Adding AssemblyDefinitions for this library and UndoPro would enable other tools to explicitly reference it as a dependency and avoid its contents from polluting the main CSharp assembly and recompiling anytime a code change takes place. Note that I was looking at the main branch for this project and didn't see these anywhere, but its possible I was using the wrong branch for distro.
• Adding a package distribution source would also help enable other libraries to reference this as a dependency. For examples of this:
  • XNode serves as a good example of a similar purposed library available as a package.
  • OpenUPM is an open-source package registry for Unity and its developer is very responsive and willing to help developers add package support for their library.
  • My own library JCMG PackageTools highlights several workflows for adding package support for libraries and how it can make this process easy for developers to maintain (and itself also supports OpenUMP).

Thanks and hope to hear from you soon.

[Seneral]

Hi, Depends on what you consider active. I try to give support and advice for projects using the framework (see forum) as well as fix any breaking changes from unity or bugs in the framework. New features only if I can be really motivated to do it myself (see Undo integration, that was due for years), but I'd welcome PRs. The problem is I've kind of moved on from developing unity tools for now, and I don't have too much time to dedicate to it. But that kind of minimal support I'm confident I can continue for years if need be. I suppose I should make that clear, so maybe I'll release a LTS release.

As for packages, I'm not entirely sure if there's benefit for this project to be released as a package. Yes you could use it as a package, it has been designed to support multiple tools in one installation independently without each one modifying the source, but afaik most tools want to do at least a few changes here and there, and bigger tools do heavier changes like interface and stuff all the time, so there's little use for most projects. It looks easy though from a quick look at your tool so I might give it a go if you think theres benefit to it.

[jeffcampbellmakesgames]

Hi, Depends on what you consider active. I try to give support and advice for projects using the framework (see forum) as well as fix any breaking changes from unity or bugs in the framework. New features only if I can be really motivated to do it myself (see Undo integration, that was due for years), but I'd welcome PRs. The problem is I've kind of moved on from developing unity tools for now, and I don't have too much time to dedicate to it. But that kind of minimal support I'm confident I can continue for years if need be. I suppose I should make that clear, so maybe I'll release a LTS release.

Hi @Seneral , thanks for taking the time to clarify your commitment and interest in this project. I can certainly appreciate there being periods of time where you're not as able to be engaged. To contrast for myself, I tend to work on my own tools in short bursts or between projects where I can take the knowledge and experience from that work and find ways to make tools I support/use better or easier to use.

As for packages, I'm not entirely sure if there's benefit for this project to be released as a package. Yes you could use it as a package, it has been designed to support multiple tools in one installation independently without each one modifying the source, but afaik most tools want to do at least a few changes here and there, and bigger tools do heavier changes like interface and stuff all the time, so there's little use for most projects.

I can appreciate that there are some users who that may want to do some heavier customization of the node graph to fit their own specific usage or tools; my intent at the moment is that I have several tools I'd like to either revamp to be node graph based or add optional node graph integrations that would add features ontop of my existing APIs. For these reasons, its better that the node graph library itself is not embedded in those tools directly and can be referenced as a dependency instead via the package manager.

It looks easy though from a quick look at your tool so I might give it a go if you think theres benefit to it.

Its definitely very easy to add package support. I personally prefer using my own tool with a separate cloned repo of the library and orphaned branch because I like to keep a clean split/isolation between the Unity project I'm developing in (with example content and unit tests) and the distro branch with just the package contents, (more info here), but there are other ways.

[Seneral]

Ok so finally have enough time to do this. I'd like to add UndoPro as a separate package dependency since that would definitely benefit from being a package, as it should be used by mutliple editor tools (not sure if anyone actually uses it though). But in usage.md you say that dependencies are only supported in 2019.1 and up. Would you recommend me including it instead? Or is dependency support solid? I'd like to support as early versions as possible since the framework technically works down to 5.4 or lower afaik, Sorry, not used Package Manager at all before,

[Seneral]

Ok so I might need your help @jeffcampbellmakesgames since you seem to know quite a bit about package management. Trying to add UndoPro as a reference to the NEF package. Optimally it would be the UndoPro package git url but I can't seem to be able to get that to work. UndoPro package name is com.seneral.undopro, can successfully install it by adding package from git ("https://github.com/Seneral/UndoPro.git#release-pkg") or manually. How would I got about adding that dependency to the NEF package? Tried various formats of URL in the package name field derived from this post. I'd rather not require all users installing the NEF package to manually install the UndoPro package beforehand, without even having a chance to explain where to get it, they will just see a dependency error upon install. This also would apply to all packages relying on NEF in turn, of course.

[Baste-RainGames]

Unity doesn't support recursive third-party dependencies in packages. You can have your package depend on some Unity-feature being enabled, but you can't depend on a different git-based package.

I think that's done in order to avoid the kind of insane dependency graphs you get in the Javascript world, with eg. left-pad.

With other open source projects for Unity where I've extracted some subset into it's own package, I've either just kept the subset embedded in the main project, or added a note in the install instructions that you need to install both.

[jeffcampbellmakesgames]

Hi @Seneral, I’m on vacation for a few days, but will be able to help give some more detailed help when I’m back

[Seneral]

No problem, have basically finished package support (revamped how GUI skin is handled on the way so GUI can be changed by tools without any access to code or resources in the package). Packages should now easily be able to create custom windows with custom look on top of the package with minimal effort and be able to run in parallel without interfering. As for distribution, have thought about using OpenUPM, but will add manual instructions (installing both packages individually) as well. Might also adapt the TextureComposer example for package use and with custom window just for demonstration purposes if I have time, although that has to wait.

[Seneral]

Ok hitting a problem where I might need your opinion. I've prepared the package and everything only to realise that when a package is properly installed through git, their folder becomes immutable - this did not happen in a local package install. The problem is I used "Packages/com.seneral.nodeeditorframework" - the package path - as the location to store the temporary files curSession and lastSession. they are essential in restoring the last session and stuff like Undo, and are saved using Assetdatabase. Now immutable means this doesn't work anymore, so now I have to think of another place to store them. Temp doesn't work either, because you can't save to it using AssetDatabase. So what is left? Assets. Meaning even with a package, to save temporary assets that SHOULD be hidden, we need to clutter the users Asset folder anyway. Any ideas how to handle this? I need a way to save assets using AssetDatabase that are hidden from the user, e.g. in a place where they don't clutter the users project.

[jeffcampbellmakesgames]

EditorPrefs might work well for you. In this situation I’ve used them in a similar way for per user preference and editor session info.

I’m not sure for this library how often they are read from/written to, but generally as a practice I’d read them from EditorPrefs into memory on first load from disk and from then on only update the versions in memory until the editor window or tool is closed and then write them to disk.

_{Sent with GitHawk}

[Seneral]

Unfortunately EditorPrefs doesn't allow for storing assets (ScriptableObjects). Also in this case, curSession is the canvas currently being worked on - in other words it has to be in memory at all times, but at the same time on the disk saved, with exactly the same GUIDs so references don't break. This is required to have undo records persist over script reloads. So I guess it really has to be in the asset folder, most likely at the top level because that is usually not used anyway - and is not another folder showing up in the project view. Then maybe allowing to change their path somehow. Alternative; Only allow install over local files so Packages/ can be written to. Disadvantages: We're at the mercy of Unity deciding to make that folder immutable as well and each time you update using the package manager these files get deleted. I'll try creating a new folder in Packages/ and see if that is immutable

[jeffcampbellmakesgames]

Unfortunately EditorPrefs doesn't allow for storing assets (ScriptableObjects). Also in this case, curSession is the canvas currently being worked on - in other words it has to be in memory at all times, but at the same time on the disk saved, with exactly the same GUIDs so references don't break. This is required to have undo records persist over script reloads. So I guess it really has to be in the asset folder, most likely at the top level because that is usually not used anyway - and is not another folder showing up in the project view. Then maybe allowing to change their path somehow.

I would recommend going for the first option of creating and updating those temp files in the Assets folder over restricting the package usage to local ref only. For the files' location, a fair number of studios like to place all of their third-party plugins/assets into a subfolder of Assets so making this location configurable by a user can be really desirable. The default location could just be something like Assets/Node_Editor_Framework/ though with the option of allowing a user to modify that folder path to an alternate location in the Assets folder.

[Seneral]

Yeah I thought of just putting them in the Assets root so as to not make a new folder and making the user aware, and then let the user move the folder by just moving these files (will just have to adjust each init, probably easy because Instill have a reference to it). Maybe try to add a file saying "move me" or smth to make the user aware that is an option haha.

[Baste-RainGames]

The first time you try to use Text Mesh Pro in a project, you get a popup window that's all "hi, we need to put some folders in your Assets/ to work properly", and then you click a button to do that.

You could do something like that, and also let the user enter the path to put the things (with a sensible default).

If curSession and lastSession are not files that are supposed to be in version control, a good default location is the magic folder EditorDefaultResources, since that's for things that are used by editor scripts and are not included in builds.

[Seneral]

Ok finally got around to implementing the fix. I went with a new idea, I now have a marker which always has a fixed GUID. Makes it very easy to check the path since you can search assets by GUID, all without using EditorPrefs (which would be shared over multiple projects...).

Quite happy with how it works. There are minor issues, e.g. if you move the cache folder / the marker and directly delete the curSession/lastSession files without clicking on the window first to let it update the path, then results might be undesireable.

Still I would like to make sure it works first before I create the LTS release proper. You can install the package through Unity Package Manager / Install through git with the following URL: https://github.com/Seneral/Node_Editor_Framework.git#release-pkg (of course, first install UndoPro https://github.com/Seneral/UndoPro.git#release-pkg

Then you can download the examples from the develop branch as usual. Btw also added an example that shows how partial class feature of C# can still be used with the new Assembly Definitions in 3rd party tools.

[Seneral]

After another fix I released it today. https://github.com/Seneral/Node_Editor_Framework/releases/tag/v1.0.2-lts Also updated the dialogue example to work with it, needed a few lines (and also made use of a new feature)