DOTS Visual Scripting 3rd experimental drop

Oh, that's slightly disappointing. IMHO, conversion workflows feel weird. Something like an "editing friendly" projection of the actual ECS data sounds more natural.

About monobehaviours, I thought you would use this opportunity to get rid of the old architecture and engineer a more streamlined solution for those parts of our games that are better suited for OOP.

Thanks for the reply, anyways!

 

Hoping that prefab-instances system will be kept in representing gameObjects, could removal of the boiler plate mean that I can drag and drop MonoBehaviour(Material,Sound or any asset) in the graph, or even better hand coded ECS script, and conversion code and node will be autogenerated???

 

Can you demonstrate how to creat a NativeArray in this visual scripting tool ?

 

I Know That This is Still in the Prototype phase but Including A robust Save system will be paramount considering that this will be geared towards artists and non-coders for the most part, and the ability add
save folders to the game directory without code wold be an excelent USP compared to the astableshed visual scripting languages.
Do you have any plans for such a system?

 

The question is a little off topic.
About visual programming in C #.
Now the store already has the perfect solution for this: Nottorus.
https://assetstore.unity.com/packages/tools/visual-scripting/nottorus-59656.

It works with reflection and automatically creates a library of nodes, and can do this with any connected libraries and classes. It also already has support for state machines. It is not as clear as a Playmaker or Bolt, because it does not take programming to a higher level. But it does not have their limitations, and does not require additional extensions for each new library. And it uses a lot of "famous" solutions in the interface. It generates very clean code and can generate a node network from scripts. And, accordingly, it has support for visual code and visual code. And by the way, maybe it can automatically generate nodes for working with DOTS, providing an interesting alternative.

But for unknown reasons, it is no longer supported. And while the need for visual programming for the traditional system of components and objects will not disappear. I think that this solution is ideal for transferring to Unity, of course, in a more traditional interface, and possibly with the cosmetic processing of some parts to increase productivity and stability. Yes, I understand how stupid it is to offer this at the current stage. But you can’t forbid me to dream) I think such a large-scale and flexible system should not just die.

And my question on the topic:
Have you considered the possibility of using complete good solutions from the asset store?

 

It's not possible, ever. The technology has to be written in DOTS from scratch. The conversation should instead be "it should be this easy" or "can it behave like that"

But there is no buying a mono C# based asset and using it. I get you like that visual scripting solution but the technology that drives it is 100% incompatible.

 

1. Will it be possible to access all of Unity API in Visual Scripting? The particular thing I am interested in is mesh data. I want to procedurally generate mesh.
2. Also, are we able to write our custom nodes and components in C# without vs? [it's important because sometimes developers want to be able to write code in C# but make high level custom nodes out of it], and how will the process look like?
3. Is there a possibility that we could write custom nodes with data for things like [example] Dialogue graph that supports branching on conditions, executes different actions... etc. Or should we aim to write our own graph solutions based on UIElements and GraphView to support this kind of behaviour?

 

I'm locking this thread in favor of the new drop 4 that was released last week
see: https://forum.unity.com/threads/dots-visual-scripting-4th-experimental-drop.749273/

thanks for the feedback so far everyone!