+1
Not a Bug

The cache unit gives an error

sumibi-yakitori 3 years ago updated by Lazlo Bonin (Lead Developer) 3 years ago 6

I'm using Unity 2017.4.6f1 and Bolt v.1.4.0 (.NET 3.x).


But, I can avoid this bug by using variables in this flow.


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

I second that. Code that used to work on 1.3 now gives an error.

Bolt 1.4 .NET 3.x from 13/07, Unity 2017.4.6f1


"Drag" event always happens after "DragStart".

InvalidOperationException: The value of 'output' on 'Cache#02369...' cannot be fetched dynamically, it must be assigned.
Bolt.Flow.GetValue (Bolt.ValueOutput output)
Bolt.Flow.GetValue (Bolt.ValueInput input)
Bolt.Flow.GetValue (Bolt.ValueInput input, System.Type type)
Bolt.MemberUnit.UpdateTarget (Bolt.Flow flow)
Bolt.InvokeMember.UpdateTarget (Bolt.Flow flow)
Bolt.InvokeMember.Enter (Bolt.Flow flow)
Bolt.Flow.InvokeDelegate (Bolt.ControlInput input)


+1

And similar to that, the AddListItem bellow also produces "cannot be fetched dynamically" when it used to work on 1.3. This code is a frankenstein garbage and already fixed, but I'm just reporting that this mess used to work somehow.


InvalidOperationException: The value of 'listOutput' on 'AddListItem#79516...' cannot be fetched dynamically, it must be assigned.
Bolt.Flow.GetValue (Bolt.ValueOutput output)
Bolt.Flow.GetValue (Bolt.ValueInput input)
Bolt.Flow.GetValue (Bolt.ValueInput input, System.Type type)
Bolt.Flow.GetValue[IEnumerable] (Bolt.ValueInput input)
Bolt.CountItems.Count (Bolt.Flow flow)
Bolt.Unit+<>c__DisplayClass84_0`1[System.Int32].<ValueOutput>b__0 (Bolt.Flow recursion)
Bolt.Flow.GetValueDelegate (Bolt.ValueOutput output)
+1

I didn't understand why at first, till I started thinking about how programming works. What's happening, is Flow is now an individual instance. The equivalent to MyClass.MethodCall(). in code, I can't get a local methods variable outside of the method itself, (what your essentially doing) but I can set the class variables (graph variables) and retrieve from that. So essentially I think this particular error is completely intentional, and especially good when it comes to generating scripts down the line.

So events are now closer then ever to being like a c# method in execution style. Must abide by most of those rules. 

+1

I think I follow your thought, but not for the Cache node. Isn't it's purpose to store a value without the visual disconnection of set/get nodes? A local variable for the whole graph.
If it turns local only to the event chain, it does seem more like c#, but I don't see the advantage over the previous functionality in the graphs, it's not like we would conflict names with Cache nodes. Unless... this is preparation for c# compilation. :D

+1

It definitely is part of the preparation. I mostly don't use cache often, but if it truly follows the conventions, then no, you couldn't pull a cache from one flow to another. All units would have to obey the same rules, or you'd be breaking rules. But as for the original poster connecting on the same flow line and getting an error, that definitely throws up a red flag. You should always be able to retrieve anything from the same executed flow, as long as it comes prior to it.

Definitely love to know a bit more from Lazlo on this myself. Have to wait till next week though.

+1
Not a Bug

You both nailed it exactly in your discussion: this is intentional, and it's in preparation for C# code generation.

The cache node is now local to the current flow, it is no longer local to the entire graph.