DOTS Visual Scripting Experimental Drop 9

"This" is great

Portals probably should have a way to be titled. Seems kind of confusing that every one would be named "Data Portal" and the only way to know which start and end point belong to each other is by hovering them. I like the typical way this is done, where you give a start portal a title, and then when you add an end point, you get a nice drop down with all the start portal titles to pick from and link too.

That and/or allow the start portal node color to be linked to the end portal node color

Then there is this:



I don't think that's supposed to be allowed! Event edges don't seem to break when other events are added - at least visually

Also parts of the UI is kinda hard to read atm!



Side note, i'm sure you're aware but getting some really bad GC spikes:

 

Hi you disabled connectors in this version? How do I enable them?

 

Thanks!

Also like the Data portals idea. Will play around with this more.

 

Yes exactly. Really cool.

 

No, I don't see connectors, but they work correctly, just invisible. Maybe it is a rendering bug in this window.

 

Ahh ok, cool

I'm guessing then any number of Events can trigger whatever they're hooked up to as well, or does all but one need to be disable for it to work?

 

Got some render issue.

Ports on disabled node are not displayed correctly.


Control points do not move with Placement.

 

Anyway to get enums to show up in the nodes? Or do you have to make separate nodes similar to your getaxis node?

I would like my 'space' variable to show up here:

Code (CSharp):

1. [Serializable]
2.     [WorkInProgress]
3.     [NodeDescription("Translate an Entity based on input and multiplier.")]
4.     public struct Translate : IFlowNode
5.     {
6.         [PortDescription("")]
7.         public InputTriggerPort Input;
8.         [PortDescription("")]
9.         public OutputTriggerPort Output;
10.  
11.         [PortDescription(ValueType.Entity, Description = "The GameObject that will change its position.")]
12.         public InputDataPort GameObject;
13.  
14.         [PortDescription(ValueType.Float3, Description = "Translation direction")]
15.         public InputDataPort Direction;
16.  
17.         [PortDescription(ValueType.Float, Description = "Speed of the translation")]
18.         public InputDataPort Multiplier;
19.  
20.         public enum Space { Self, World }
21.         public Space space;
22.  
23.         public void Execute<TCtx>(TCtx ctx, InputTriggerPort port)where TCtx : IGraphInstance
24.         {
25.             var entity = ctx.ReadEntity(GameObject);
26.             if (entity != Entity.Null)
27.             {
28.                 var t = ctx.EntityManager.GetComponentData<Translation>(entity);
29.                 var r = ctx.EntityManager.GetComponentData<Rotation>(entity);
30.  
31.                 var translation = math.normalizesafe(ctx.ReadFloat3(Direction)) * ctx.ReadFloat(Multiplier) * ctx.Time.DeltaTime;
32.  
33.                 if (space == Space.Self)
34.                     translation = math.mul(r.Value, translation);
35.  
36.                 t.Value += translation;
37.  
38.                 ctx.EntityManager.SetComponentData(entity, t);
39.             }
40.  
41.             ctx.Trigger(Output);
42.         }
43.     }

 

Windows 10, Unity 2020.1.0b8, 1 error:

Unable to find required resource at GraphView/GraphViewUIE.shader

UnityEditor.EditorGUIUtility:LoadRequired(String)

Unity.GraphToolsFoundations.Bridge.GraphViewBridge:OnEnterPanel() (at Library/PackageCache/com.unity.graphtools.foundation.overdrive@f688d1899a2a-1589291002000/Editor/InternalBridge/GraphViewStaticBridge.cs:435)

Unity.GraphElements.GraphView:OnEnterPanel(AttachToPanelEvent) (at Library/PackageCache/com.unity.graphtools.foundation.overdrive@f688d1899a2a-1589291002000/Editor/GraphElements/Views/GraphView.cs:778)

UnityEditor.VisualScripting.Editor.VseWindow:OnEnable()

UnityEditorInternal.InternalEditorUtility:LoadSerializedFileAndForget(String)

UnityEditor.WindowLayout:LoadDefaultWindowPreferences()

 

Nevermind....it appears off to the side. I don't know if I like that. Why not just put it right on the node? seems very off to me.

need to do this first in code:

Code (CSharp):

1. public struct Translate : IFlowNode, IHasExecutionType<Translate.Space>

edit: I guess I can understand if you have a huge monolithic node to have the execution types off to the side like that...but is there a way to put it right on the node if you want to?

 

How do you get non-object variables to show up in the inspector? Like "speed" for example.

 

Dear Team, I am an UX Specialist as well as part time Programmer & designer.
My challenge is to convert C# Code to VS (Visual Scripting) is it Possible? if not do you have any plan to do it. Because as per my knowledge there are so many people like me who need conversion in both sides(C# Code to VS & VS to C#).

This would be Really helpful and could be a Game Changer. Please do reply. Thanks!!

 

Only manually. I remember they specifically stated in the very first topic about VS that conversion will only be available from graph to code, not the other way around. I don't think it has changed since then.

If you have valuable and relevant statistics (I mean real, hard data) that a lot of people want to convert code to graph, I suggest to send it to them. They may revisit this idea after the release if they see that a ton of people has this use case (which I seriously doubt, but this is just me without any real backing data).

 

How can I use the On Event/Send Event nodes ?
Cannot find the nodes.. Is that something I should setup for them to appear
Is this the only way to communicate with C# script ?

Test code learn.unity Tutorial Events

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class EventManager : MonoBehaviour
5. {
6.     public delegate void ClickAction();
7.     public static event ClickAction OnClicked;
8.  
9.  
10.     void OnGUI()
11.     {
12.         if(GUI.Button(new Rect(Screen.width / 2 - 50, 5, 100, 30), "Click"))
13.         {
14.             if(OnClicked != null)
15.                 OnClicked();
16.         }
17.     }
18. }

 

WOAH WOAH.. I haven't looked at the VS editor in a while, when did the editor go from vertical logic flow to horizontal?? PLEASE tell me this isn't going to be how it works now?

 

what they said in previous drops is that it will be an option for the user, so you can do it both vertically and horizontally

 

This is really cool VS now, I just wanted to know if these portals work between another object's Visual scripts, (How to send events, or send data between them) I tried to do this but it went wrong.

but I'm enjoying working with him. has a very simple workflow.

 

As a coding teacher for 15 years, I think that's a huge mistake. Tutorials/docs/forums would be all separate and massively confusing.
Having logic vertical and data horizontal was perfect from a beginners standpoint. Much much better than BP's
I've taught C# and Blueprints to beginners and artists for many many years, I know exactly what is confusing to them (and it's not what programmers think would be confusing AT ALL). BP's are confusing for DIFFERENT reasons than text. You CAN combine the best of both and Drop 6 seemed to be getting close (BP's are horrible AND text code is horrible for many reasons). I'd love to lay it all out, if anyone is listening?

Keep in mind the industry standard is vertical nodes (deliberately to match text code). Look at Nuke, Houdini, even Scratch (millions of kids learn to code in this, don't underestimate its influence in the coming years).
The editor should at least flow and snap the same way as code/scratch and Drop 6 seemed to start doing this.
I honestly felt a bit sick to see BP style being copied, almost like they gave up.

 

I understand your point of view

it really divides opinion, but if it really becomes a user option, people will choose their best work flow. there are people who do not like BP and there are people who love it, so it is something that is really interesting if it is to choose.

 

Wait, I wasn't being combatitive, I haven't been following the threads at all, so I didn't know if devs are listening. From my perspective that's just what it looked like. Very happy to see that it's not.
I think my teaching experience could be useful to you as you seem to be aiming at that level of user, so I'd be happy to give genuine feedback.
For the 'multiple flow' problem I'm sure there's a way to visualise it. I've used node systems in lots of domains for about 25 years so I'd be happy to help.
First I think VS should have it's own sub-forum, it's too important to hide away with ECS stuff.
Second I'd love to see failed attempts at vertical visualisation and other upcoming editor specific stuff, so we can have a go mocking up solutions and general brain storming.

ps "Like it or not, horizontal flow is common". OOP is common, so why make ECS? Joking aside, text coding is common, so why make visual scripting? What is it about visual scripting that makes it need to exist?

 

How do you get variables to appear in the inspector for these visual scripts?

https://imgur.com/a/L4ygm5m

 

I think I've have tried everything now.. and I can really not find it.

"What’s new?

• Send and receive events to/from the code from/to visual scripts using On Event/Send Event nodes."

Please someone help! is driving me crazy

 

The second/Alternative way script don't work please help !
Assets\test\DispatchEventSystem2.cs(19,64): error CS1503: Argument 2: cannot convert from 'Runtime.VisualScriptingEventSystem' to 'Unity.Jobs.JobHandle'

Sadly I can't use the first script..but it works for one parameter

 

This sounds super limited. Why is the scope so small? I don't understand the logic here because you know people will want to use it for all these use cases.

Flow is fundamental to visual scripting, what higher priorities do you have? Now is the time to get this right.

Overall it sounds like Unity wants to rush this out the door

 

I don't think the scope is small, it's focused. If your tool does everything, it's great at nothing.

 

Still testing drop9, I really liked the portals, it helps a lot in the organization of the code.

This looks bad, because I hoped I could create something big using only VS (without codes) ...

Just looking at other solutions, I know very well what can be done and what cannot be done, assets like playmaker or bolt still need some line of code here or there, but at least there is a wide range of possibilities without need traditional programming.
I know that Visual Script DOTs is still in development and has a long way to go, but can we hope that at some point it will follow the same path?

What are your plans (roadmap) for VS DOTs for the future?


sorry about my English

 

Great, let's just continue to ignore the feedback from these threads and respond with snarky comments.

 

I think you are being a little hostile for no reason... We are still far away from the 1.0 and it was made clear that those flow issues will be revised before the 1.0 release. It is very clear to me that they are not ignoring feedbacks, you can't demand Unity to just shift priorities because you think they should and hope that they will do it because you said so.

 

That's always interesting to me. A lot of people separate VS, scripting and code as distinct things. I see VS as a different editor for coding the same stuff, most don't. It seems when VS comes up, there's actually 3 or 4 things that are lumped together with the 'Visual' part that aren't necessarily related.


I'd be interested what people think which ones below are fundamental to VS or Code.

- Is it the wires that define what visual scripting is? If so, does that mean it's the non-visual JUMPING ABOUT that is the core problem for people when coding?

- If the jumping about IS the core problem, could a text based editor address that? Could you add WIRES to text code?

- If you look at Scratch, the editor is laid out exactly as pure code does, with no wires. Does this count as visual scripting? If yes, why?

- In Scratch and BPs you CAN'T make a syntax error. The blocks are unbreakable, unlike structures in typed code. If this is fundamental to VS, could unbreakable code structures be added to an IDE like Rider? Could Rider 'blockify' their editor, so turn it into something like Scratch and still be called 'real' coding? Is free text the main difference?

- Is the ability of text to allow non-visual ordering of data flow a problem? You COULD use lots of lines with temp variables to build up data for a method parameter, in a more visual way, but most don't.
Could the IDE show this in a more verbose way similar to VS?

- Could you make a VS editor that is also capable of mostly keyboard input like text? Is the mouse fundamental?

- Is it simplifying code down to chunky concepts that are hard to patch together in code? If so, could something like Rider add a visual element to text code?

- Freely placing blocks of code visually in a workspace is in all VS editors. Could TEXT editors also allow this? Why is text automatically assumed to be a single list of vertical lines when VS isn't?

- If program FLOW is a big problem, then visualising the WHOLE program isn't addressed in any editor I know. Is it feasible to zoom out past single scripts and visualise data between objects/entities/managers etc?

I'm interested to know what fundamentally the 'visual' part IS for different people, as from reading these threads, there doesn't seem to be a clear definition.

 

@theor-unity
Did you ever use playmaker in a project?

You know that the actions that you use in the state machiche are just pieces of c# code right?

 

I agree with your point, in the end VS is just a syntax-error-free way of coding, based on nodes and wires instead of text, braces and newlines, but as the engine was not built purely on top of VS everything that you want to see in the VS world needs to be coded in text first, thus to have a "complete replacement for text code" would require a lot more work than first focusing on a high-level solution for non-programmers.

This is also true for BP btw, there is a lot of "basic stuff" that wasn't available on day one (like knowing if the code is running in the editor or in a build). A lot of playmaker actions and bolt functionalities were also only introduced after day one too.

In would guess that in the future there will be enough functionalities (from both the community and built-in) to make any sort of game from scratch with DOTS-VS only, just like with BP today, but we can easily understand why this is not the team goal for 1.0.