
0
Under Review
Strongly typed graph variables
I think graph should have its own local variables.
Imagine you are writing flow function there you need to use some local(unused in other places) variables.
Are they planned?
Bolt Version:
2.a.6
Unity Version:
2019.3
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):
Customer support service by UserEcho
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:
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:
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. :)