Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do you intend to add Unity Visual Scripting support? #24

Open
Emilian5 opened this issue Aug 12, 2022 · 6 comments
Open

Do you intend to add Unity Visual Scripting support? #24

Emilian5 opened this issue Aug 12, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@Emilian5
Copy link

Hello.

I was preparing to refactor my own SO events system implementation, and during preparation I've look to see if someone shared their similar development. So here I am.
Your implementation is more, let's say evolved. Good job, and thanks for sharing.

During the development of my game, I found that it was hard to follow the Event Listeners on GO, especially when multiple Events Listeners were added besides other MonoBehaviours.
The solution (for me) was Unity Visual Scripting. I moved all the Event's to Unity Visual Scripting graphs, and now they are easier to follow, to trigger, etc., especially from the point of view of a designer.

Do you have any plans to add support for Unity Visual Scripting?
Or, if you receive a pull request with Unity Visual Scripting support will you consider accepting it?

Thank you.

@Edvinas01 Edvinas01 added the enhancement New feature or request label Aug 12, 2022
@Edvinas01
Copy link
Member

Hey, thank for taking interest in this package!

In regards to visual scripting (Bolt) I personally don't have that much experience and haven't used it at all. So most likely I wont investigate this personally.

However, I think this would be a good addition to the package depending on how this is done. If lets say integration would require a change in every event script I'd be a bit reluctant to add it as this would greatly increase maintenance. If its just a few scripts with some compiler directives (maybe there is a better way, unsure) I think that'd be fine.

Generally speaking the core idea of this package is staying simple to keep the maintenance as low as possible. However, I think integrations with other packages/tools is fine as that doesn't change the core functionality in major ways and moves the responsibility to other parties.

Anyway, if you'd like to take a shot at this go ahead!

@Emilian5
Copy link
Author

None of your existing code will be modified.
UVS nodes will be wrappers around current code.

Will allocate more time to better investigate, and will let you know.

Thank you.

@Edvinas01
Copy link
Member

Closing as I'm not planning to add this feature unless someone else decides to contribute - will re-open then.

@Emilian5
Copy link
Author

Emilian5 commented Jul 23, 2024

Hello.
Sorry for the long break, life had other plans for my free time.

I've opened a draft PR #33.

Before investing more time in this, I would like to know if you are still open to merge into your repo?
If yes, what aspects should I cover?

  • I know I need to write a proper documentation.
  • I know I need to add support for all event types.

If no, are you open to mention/link the package (that I will host on my repo) in your documentation?

Thank you.

@Edvinas01 Edvinas01 reopened this Jul 24, 2024
@Edvinas01
Copy link
Member

Hey @Emilian5,

Awesome that you're still interested in this!

Before investing more time in this, I would like to know if you are still open to merge into your repo?

I'd be glad to merge this in, though I'd need to spend some time testing and getting to know Visual Scripting to give good feedback on your PRs. This would probably take some time as I'm currently busy with some other projects and also I'm lazy 😅 If you're okay with waiting we can try this route, I'd spend some time looking into the PR & testing/note whats missing.

If no, are you open to mention/link the package (that I will host on my repo) in your documentation?

Personally I think this would be a better approach as I wouldn't block you and you could set up the repo in a convenient way for yourself. I could add an "Extensions" section in README.md and link your repository once you get it up and going. Additionally, perhaps linking this in the documentation would make sense as well in-case people miss it on the front-page of the repo.

@Emilian5
Copy link
Author

Let's leave it as a draft PR till the package will be mature enought to be an actual release. Will take the final decision then.

Please use this issue to add your input, and I will handle it.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants