0
Answered

Managing object variables across different objects for the same macro

André Ivankio Hauer Ploszaj 3 years ago updated by Daniel 1 year ago 4

I feel kinda silly asking this after all this time, but it's eating my insides out:

What would be a consistent way to guarantee I have all object variables a macro uses with default values when I attach it to a different object? (Assuming the variables are not fit for the graph scope - like a variable available to all states of a FSM)

Like in Unity, every object that I attach a script, they show in the inspector the public variables for that script. Is copying and pasting the variables component the prettiest way or did I miss something? Then should I just annotate which objects have each macro if I ever end updating the macro, or do checking for a variable existence is a common practice?

Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):

I made a super unit to default a variable if it doesn't exist on the object.  I wire it to Start/On Enter State so that all my variables are initialized before I do anything on the object.  If I want custom values for one of those, then the I make it on the object and the default variable macro does nothing.  Would this approach work?

So you have extra computation just on start/on enter state, not during updates, correct? Seems good, could you share a screenshot of your SuperUnit graph? It can handle any type, including no type and lists?

Despite that, I'm not seeing an advantage for unlinked variables. Is there a reason for that or do you think there's a feature suggestion here to make the Variables component dependent to the graphs?

+1

Sure!  It's an ugly graph, but it works:


That's my default variable graph, which will create the named variable on the object if it doesn't exist.  If it does exist, it does nothing, leaving the value as the custom value you have defined.

By unlinked, do you mean variables created on the fly?  I think they're too valuable, as Bolt allows accessing another objects variables, and other objects may need to inject variables.

+1
Answered

Just want to chime in here that this is a very core design concern for me, and it's not silly at all to inquire about it!

The real solution to this problem is OOP-like encapsulation (associating function with data), but that is a long-term research project that might not make its way into Bolt soon.

Therefore, I'm looking at potential workarounds in the mean time (e.g. a button that creates all variables used in the graph, or ideally something even better that would show up directly in the inspector). I'll keep everyone updated when I find a good solution!

In the mean time, the above macro is a pretty cool solution! ^