Strongly typed graph variables

Hi,

You can use the Assign unit for this. This is the equivalent of the old "Flow" variables.

There is no equivalent to legacy "Graph" variables, but you can make any class variable private to avoid exposing it elsewhere.

Hello. I guess "Assign" unit will do the work. 

But it is not the same as local variables and could be better at least.

There will be many potential bugs with renaming.

Private variables are whole class visible. Thery are not the same as local variable of function. and has different usecase.

(there will be name collisions, misleading in class access and settings, and general polluting of variables)

I realy think that it could be better to have local graph variables. What is the reason to not have them? Not having them is better than having?

Out of interest, why would there be bugs with renaming? You assign the local variable once and then reuse it via proxies. So if you rename the local var, that change propogates throughout the script. 

In generated C# Assign unit not only looks like a local variable, it is a local variable. 

Lets say you have a complex function. If you assign variable with the same name in different places lets say 5

and than use proxy of each assign unit (you most likly will drag from nearest assign unit in order to use that variable) you will need to rename all the assign units. And if you miss one you will end up with some kind of silent bug. 

And more over "Assign" unit name is kind of unusual for programmer. 

I would expect something cohesive with "variable" in name.

It also looks misleading ( in c# you have variables with different names but in graph they has the same name).

It can and will produce bugs.

in above example in false branch someone will expect 33 to be printed first but in fact it will be 22.

To deal with above usecases you could:

1. Intorduce some kind of "Assign mass rename tools" and force "Assign" to have different names if they were assigned in different branches. And possibly other for now unknown usecases.

2. Or just Add local graph variables.

Flows of concept of "Assign" 

- Name is confusing for programmer

- Not fully refactored

- Error prone. Especially for none programmer. ( varialbe can be assigned in different places with same name, but in fact it will be different varialbe with different name).

There is no thoss downside for local graph variables.

There is a place for local variables to exist in c#, java and unreal blueprints and possibly in many other languages.

And I really think they should exists here. 

(especialy since you moved to concept of "class" in bolt 2.0)

Hi Textus,

Thanks for giving more information about your rationale.

Here is my reasoning for the Assign unit, or rather, for deprecating graph variables:

• Variable Scopes were too complex. You should always be able to create and find them from the same place. In Bolt 1, there were 5 possible scopes, which was extremely confusing for new users. The new class variable system simplifies that. 
• Graph Variables used to make sense when graphs were used directly on game objects via machines. They were the only way to bind variables to a graph. Now, graphs are never disconnected from a class. And binding variables to graphs is easily done via classes. Importantly, this means, there is nothing you could do with graph variables in Bolt 1 that you cannot do better with private class variables in Bolt 2.
• Function parameters or macro inputs are often enough when you need external inputs. 

Now, I do see your point about refactoring. I think we did an insane leap in ease of refactoring between Bolt 1 and Bolt 2, but there's always room for improvement.

It's not true however that there is "no downside" or rather "no cost" for graph variables. We have to consider:

• New actions and editors to create, display and modify graph variables, from both the Explorer and the Graph Inspector
• New units to get and set graph variables
• New concept and "layer" to introduce and document to new users
• Overhead of choice given to users when creating a variable ("should this be on the class or on the graph?"). This is not trivial when designing tools made for non-programmers.
• And to alleviate the previous point, new tools to move a graph variable to a class variable or vice versa, without breaking any unit or connection in any graph in the project, or breaking connections when the accessibility modifier no longer allows referencing the variable.
• Explore the design implications of state graphs. Can state graphs have graph variables? Are they accessible from their child states? How deep in the hierarchy? Or through their sibling states? Etc.

In summary, I do see value in reintroducing a better, strongly-typed graph variable system, but it's a lot of design and implementation work, so I'll retag this as a Feature Request. And it definitely won't make it into the 2.0 release, unfortunately.

Thank for explaining. I guess if using right "Assign" unit will just do the work of local variables.

However It could be split

into 3 units (whose will be in one group in fuzzy finder "local var")

- "Define" ("Var", "Local") this will have inputs for string name, type and starting value( and possibly with output of itself). The purpose of it to define a local variable like you do it in code. It should not allow to have variables with same name. and will have button in inspector for renaming.

- "Assign" ("set var") This will contain input for Enum drop-down Of already defined variable names, input for setting value of respective type. If name Enum was not assigned it will throw warning, if name no longer exists (was not properly renamed) or type changed it should through error.

- "Obtain" ("get", "access", "fetch"). This will have Enum drop down of defined variable names  and output of value of respective type. 

This could be a compromise between graph variables and just assign unit. And it will fix several possible issues.

Good luck. :)