Visual Scripting Product Feedback

Help us help you.

Sending Feedback

To ensure that Visual Scripting is worth it for any users, and to add weight to what is mostly needed, you can use this link, to send your feedback and to vote on features on the road map.
https://portal.productboard.com/xvo8kmgtx7tkv7desh8cyaj7/tabs/27-visual-scripting

If you can’t find anything related to your needs, simply click on the panel “Submit a new idea!

You can still start threads about feature requests so other users and devs can discuss about those features.

2 Likes

Beauty thanks for setting this up. woot!
and for not closing or discouraging other threads on the topic.
I’ll try not to spam it ^.^

2 Likes

Would be nice to see some roadmap updates. The roadmap hasn’t been updated in quite a while. Some work in progress items were added almost two years ago by a person who’s not part of the team anymore. And no stability and bug fix updates have been released in the past 8 months despite what roadmap claims.

4 Likes

Could possibly get some information during the unite event. Unite 2024: Conference for Game Devs & Creators | Unity

Doesn’t look like it looking at Agenda category.

This is the closest thing, but judging by the description, it’ll cover existing tech and workflows.

And I skimmed through Unity 2023 roadmap talk - 0 mentions of Visual Scripting. It’s pretty safe to expect that nothing will change in the next year in VS land.

Yay nothing announced today regarding UVS evolution and roadmap, so :

Unity Visual scripting evolution is way, way too slow and the high interpreter is more than urgent. I’m making a 100% UVS project and it’s been 3 years from now that I wait for bolt/UVS to bring a real optimization for the CPU. Once again, assets on the assets stores are doing way better, but I can’t afford so much dev time to remake everything with another visual scripting solution.

An advice to anyone here : don’t use UVS for production. It’s not ready. Use a finished solution on the asset store.

Same goes with shader graph, amplify shader is way better in every ways.

I see asset store items:
== like mods
no idea who make’s em.’ No idea if they ever get maintained and odds are they don’t work with your version. lol

Can anyone display this issue they’re having with “optimization”? I can’t seem to replicate any kind of lag on normal projects. and im in HDRP. youtube video or somthin’ like that

should be “noticeable” to be an issue right but I don’t notice anything over here
I dono… like I’m sayin’ maybe it’s how folks have setup the scenes or somthin?

If it’s a system requirements thing that only effects slow computers, traditionally all they do to solve this is put a system requirement warning on the box. IF<–

like Visual Scripting was an asset store item… and was bought out lol so at least it’s a little more official now but still not any more information or whatever. lol

just waiting for when we can ask AI to do all the work for us.
sure it’ll have to run on cloud-based quantum computing that requires a monthly fee but at least we won’t have anything to do anymore… :stuck_out_tongue:

UVS is not really maintained either. 8 months since last update. And UVS fails to run on IL2CPP platforms (which is most of them) with Cinemachine nodes in graphs as well other 1st party tooling nodes when they’re added via Node Library. The IL2CPP builds also fail for common middleware like FMOD and most asset store editor extensions if you want to use nodes from those. This issue has been known for nearly a year. The bug reports have been submitted and accepted, but nothing is being done about it.

FlowCanvas+NodeCanvas can actually deploy to IL2CPP platforms and the author is reachable on their support forums and responds in a timely manner. Project stopping bugs don’t persist for 8 months for these assets store products. You don’t have to buy unknown VS products. There are plenty with thousands of customers and a long, rich history of shipped products, something that Bolt/UVS doesn’t have.

1 Like

I’m sayin’ I would expect less of Visual Scripting if it was just an asset store item.
Would be like “woah loook at all this hard work some guy did to make this mod”
A slightly higher level if it was a paid thing but still would have to spend time looking at it before opening my wallet type a’ thing. Soon as i’m paying for it, it better be 100% quality. and I’m checking.

one of those “over promise, under deliver” … Or is it " under promise and over deliver" I never can remember. lol :stuck_out_tongue:

The only change I’ve actually noticed for bolt/vs since it came out was the graphical changes to the nodes whenever that happened. Think it was around the same time as the dark theme? OH and when it actually came pre-loaded into unity the first time… kept trying to install bolt over-top. that was dumb. They changed the names of the components too and that made it dumb to try and follow documentation.

seems on par with the kinds of things that happen for mods in games lol

i think folks are now expecting unity to actually develop it into a language but since it would impact the sales of other store items… they have to pump the breaks and lag behind. just a theory

This would be a safe assumption to make if one does not know VS history in Unity.

They’ve made just about the worst decisions for the past 6-8 years in relation to VS. From initially mocking it and considering visual scripting beneath them (at least according to some at the time leading developers of Unity who used to post on the forums), then starting to develop and cancelling multiple internal solutions - they never had a vision for any of it, just did something for the VS checkbox to make the engine more appealing to non-coders.

Unity then went to acquire Bolt, promised to finish Bolt 2, then cancelled it some months later and integrated the very outdated Bolt 1 which they’ve marginally improved in some respects like a bit better graph performance in the editor but also made it worse - lots of new IL2CPP compatibility issues that didn’t exist in Bolt times even though the tool hasn’t really changed in any meaningful way.

Now they’ve once again abandoned their current VS efforts - cancelled version 1.8 with the high performance interpreter and no updates for IL2CPP issues are in sight and no communication, if even that is something they’re looking to address. Last update was 8 months ago. An asset store product with these kind of issues and response times would get promptly review bombed, and they’d likely go out of business.

To be fair, their current plan of all graph based tool UI/UX unification is solid on paper. It would’ve been really nice if they formed that plan before acquiring Bolt, cancelling Bolt 2 and rebranding Bolt 1 to UVS, which is once again abandoned like all their previous VS efforts.

There really was no need to ship Bolt 1 with the engine, which the community knew and told them more than two years ago. They did it anyway and promised to backport or reimplement Bolt 2 features. UVS never got any of those promised features, it’s still effectively Bolt 1 from 2018, which is when it got feature locked so the original developer could invest time in developing Bolt 2. Who ever is making these decisions needs to find a role elsewhere because this is not how it’s done, albeit UVS product manager did change at the height of drama two years ago.

While Unity are unable to develop a production ready VS solution, Flow Canvas/Node Canvas and Playmaker have many shipped, commercially successful products in the wild with consistent support throughout the years. As much as I don’t like being dependent on 3rd party assets, I trust Flow/Node Canvas and Playmaker a lot more than I trust UVS, which I don’t. Bolt/UVS still has no known shipped titles, some solo developed mobile games and some indie adventure games that are light on functionality.

2 Likes

Interesting to note the series of events and good to keep track and keep the context intact. Am I wrong to assume that it was internal issues in relation to vision of the final product? Afterall this is the most common issue when working in groups, getting folks on the same page.

Sort of reminds me of the “new” input system or the “new” UI maker canvas thing, reading it like that. kinda working on it but not really sure what to do. Gotta’ build functionality for everything - but not doing one thing well.

Would think this sort of project would be better handled by a single person making the decisions rather than a comity. Just having an idea written in stone makes it superior to the best theoretical one that has not been executed yet.

I empathise with how many things Unity programmers have to work on and probably not enough time in the day. Also compatibility between those many things. I also empathise with what was probably a big user base who love using Bolt and then cant use it due to bugs. The aot issue was not the best place to leave it, at least fix this bug so users dont drop and look elsewhere. But then i dont know that.

I should think making a perfect visual scripting solution is a complex task, hence why godot dropped theirs. It did come across basic and simple and inflexible. Probably a mammoth task to make useable over bigger priorities like the main engine and editor.

Personally i always hoped for a kind of codegraph. But then that means creating an ide that works in a visual scripting environment.

1 Like

Personally, I fully support and actively use visual scripting thanks to my past Unreal Engine experience. I want UVS to look more like Unreal Engine blueprint. There is everything we are looking for visual script, you can take an example.

What I can suggest:

- The colors of the events should be the same. There is no need for different events to come out in different colors. It is enough for us to understand that it is an event at a glance. Different icons, different colors can be confusing. Colors have a distinctive place in visual memory, but only if you use them correctly.
- Having exec in pure variables is confusing for me.
- The movement of canvas is controlled via MOUSE2 (HOLDING). However, the movement controlled via MOUSE3 (HOLDING) in visual scripting. Regarding UX, this place bothered me. Both should be the same.
- There should be a grouping option in Blackboard. It can be confusing when there are too many variables.
- I found the navigation a bit inconvenient. Being fluid like Unreal Engine speeds up our workflow.
- A system similar to Event Dispatchers (Unreal Engine) should be introduced. It’s ridiculous that Unity requires a custom plugin for this.
- An Event Pre-Construct (Unreal Engine) style node should be brought in for use in UI design.
- Another wish is that when a new plugin is added to the project, it should be automatically added to Visual Scripting from the project settings. Why bother with adding it manually?
- IL2CPP support required
- More efficient and optimized UVS. Closer to the C# performance wise.

I hope we see these developments. Good work.

1 Like

They do have plans for implementing high-level nodes which Blueprints effectively is - a collection of curated high level nodes. Current Unity Visual Scripting only has low level nodes - automatically generated nodes where each node corresponds to one Unity C# scripting API entry. For every public C# property, method and struct there is a UVS node, with extra nodes for each of the method overloads.

But Blueprints is the main way of scripting in Unreal, it’s deeply integrated all throughout its systems. Unity Visual Scripting is and will remain optional, it won’t ever reach feature parity with C# like having inheritance and polymorphic graphs Blueprints style. I wouldn’t expect UVS approach the power and scalability of Blueprints, Unity don’t have plans for that.

There once existed a community implementation of it but it’s not supported anymore. And I vaguely recall Unity folks discussing it as possibility. Time will tell.

IL2CPP is supported (on paper at least).

They’re working on a new runtime, per November 2022 update , it’ll take another 2-3 years for them to release.

1 Like