Exception when casting a nullable value to a value in ProtoFlux

[jae1911]

Describe the bug?

When pulling out a nullable value, the Flux ribbon will get stuck to the end of the tooltip.

To Reproduce

1. Create empty object
2. Attach the OnlineStatistics component
3. Source any nullable value from it, for instance PublicSessions
4. Add a ValueAdd<int> Flux node
5. Try to connect the PublicSessions source to the ValueAdd<int>
6. Ribbon will be stuck at the end of tooltip

Expected behavior

Either:

• Ribbon should be discarded
• Node should be gracefully changed to accomodate type

Screenshots

Warning music

https://github.com/Yellow-Dog-Man/Resonite-Issues/assets/76598503/9b636d52-bc0c-45e1-bbf3-a54bc98db8f5

Resonite Version Number

2023.11.25.49

What Platforms does this occur on?

Windows

What headset if any do you use?

Valve Index; Desktop

Log Files

J4 - 2023.11.25.49 - 2023-11-25 07_36_02.log

Additional Context

Opening this issue since the original https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/766 was closed for no reason.

Reporters

j4 | j4.lc (Discord)

[Banane9]

I'd suggest changing the title to Temporary ribbons get stuck to ProtoFlux Tool when Exception occurs during connection attempt, to be more specific about the cause and which ribbons 🤔

7:37:36 AM.768 (105 FPS)    Exception Updating ActiveToolTip: Element: ID392A600, Type: FrooxEngine.ProtoFlux.ProtoFluxTool, World: Moutain Home 2.0, IsRemoved: False, IsDestroyed: False, IsDisposed: False, Enabled: True
Element: ID3929B00, Type: FrooxEngine.Slot, World: Moutain Home 2.0, IsRemoved: False, Slot name: ProtoFluxTip, T: [1.155479; -0.04514908; -1.276261], R: [-0.3697291; -0.2502555; 0.893611; 0.04617285], S: [1.100541; 1.100541; 1.100539], ActiveSelf: True, IsDestroyed: False
[...]
Element: ID0, Type: FrooxEngine.World, World: Moutain Home 2.0, IsRemoved: False
.

System.ArgumentException: Invalid generic arguments
Parameter name: typeArguments
  at (wrapper managed-to-native) System.RuntimeType.MakeGenericType(System.Type,System.Type[])
  at System.RuntimeType.MakeGenericType (System.Type[] instantiation) [0x000cd] in <9577ac7a62ef43179789031239ba8798>:0 
  at ProtoFlux.Core.OverloadSearchContext.InstanceType (System.Type type, System.Type currentType) [0x000f3] in <f9731d1dd27e4ff7bf744a035902d2bc>:0 
  at ProtoFlux.Core.NodeOverloadHelper.FindOverload (System.String name, System.Type currentType, ProtoFlux.Core.OverloadSearchContext context) [0x0005c] in <f9731d1dd27e4ff7bf744a035902d2bc>:0 
  at ProtoFlux.Core.NodeOverloadContext.TryOverload (ProtoFlux.Core.INode node, ProtoFlux.Core.NodeConnections connections, System.Boolean allowMergingGroups) [0x0001a] in <f9731d1dd27e4ff7bf744a035902d2bc>:0 
  at ProtoFlux.Core.NodeRuntime`1[N].ConnectInput (ProtoFlux.Core.INode node, ProtoFlux.Core.ElementRef input, ProtoFlux.Core.IOutput source, System.Boolean overload, System.Boolean explicitCast, System.Boolean allowMergingGroups) [0x00213] in <f9731d1dd27e4ff7bf744a035902d2bc>:0 
  at FrooxEngine.ProtoFlux.ProtoFluxNodeGroup.TryConnectInput (FrooxEngine.ProtoFlux.ProtoFluxNode node, FrooxEngine.ISyncRef input, FrooxEngine.ProtoFlux.INodeOutput output, System.Boolean allowExplicitCast, System.Boolean undoable) [0x00040] in <3c72a9c6024048039c442b0d4dfaad8c>:0 
  at FrooxEngine.ProtoFlux.ProtoFluxNode.TryConnectInput (FrooxEngine.ISyncRef input, FrooxEngine.ProtoFlux.INodeOutput output, System.Boolean allowExplicitCast, System.Boolean undoable) [0x00053] in <3c72a9c6024048039c442b0d4dfaad8c>:0 
  at FrooxEngine.ProtoFlux.ProtoFluxTool.TryConnect (FrooxEngine.ProtoFlux.ProtoFluxNode node, FrooxEngine.ISyncRef input, FrooxEngine.ProtoFlux.INodeOutput output) [0x00022] in <3c72a9c6024048039c442b0d4dfaad8c>:0 
  at FrooxEngine.ProtoFlux.ProtoFluxTool.TryConnect (FrooxEngine.ProtoFlux.ProtoFluxInputProxy input, FrooxEngine.ProtoFlux.ProtoFluxOutputProxy output) [0x00022] in <3c72a9c6024048039c442b0d4dfaad8c>:0 
  at FrooxEngine.ProtoFlux.ProtoFluxTool.OnPrimaryRelease () [0x0015d] in <3c72a9c6024048039c442b0d4dfaad8c>:0 
  at FrooxEngine.InteractionHandler.RunToolRelease () [0x00015] in <3c72a9c6024048039c442b0d4dfaad8c>:0 

[shiftyscales]

The ribbon getting stuck is intended- when exceptions are thrown- components are disabled so they do not continue to throw exceptions. This also serves as a good visual indicator for when an issue has occurred.

As such I am updating the issue of this title to be more indicative of the underlying issue (an exception being thrown when attempting to cast a nullable value to a value).

[Nytra]

You should be using the UnpackNullable node to get the proper int value from the nullable. It doesn't connect to the Add node by default because they are incompatible types.

The wire getting stuck is a different problem.

[JackTheFoxOtter]

I've encountered this in another context today, and was looking for if there is already a bug report for this. First of all - as Nytra pointed out, UnpackNullable<int> can be used before doing arithmetic with nullable types, and it works as expected.

That said, I think the exception gets thrown because node overloading for nullable types doesn't work at all.

If you take a generic object node, let's say an ObjectWrite<T>, and try to overload it to a nullable type, the overload fails and an the wire gets stuck to the tool. Creating an ObjectWrite<Nullable<T>> manually through the node browser works though, and can be connected. Same goes for other types of generic nodes, like locals and stores.

The ribbon getting stuck is intended- when exceptions are thrown- components are disabled so they do not continue to throw exceptions. This also serves as a good visual indicator for when an issue has occurred.

I think "intended" is a strong word for this. It's understandable why it happens, but surely not the intended way to communicate to the user what happened, that's just what currently happens when an exception occurs.

I'd suggest changing the title to Temporary ribbons get stuck to ProtoFlux Tool when Exception occurs during connection attempt, to be more specific about the cause and which ribbons 🤔

Disagree, that's a separate issue. The wire visual bugging out is a consequence of an exception, but that doesn't invalidate the bug report of the underlying issue that caused the exception, as that should be fixed.

[Banane9]

Creating an ObjectWrite<Nullable<T>> manually through the node browser works though, and can be connected. Same goes for other types of generic nodes, like locals and stores.

They can be created, but you can't assign them as the target - at least for field Source ones :C

[JackTheFoxOtter]

Creating an ObjectWrite<Nullable<T>> manually through the node browser works though, and can be connected. Same goes for other types of generic nodes, like locals and stores.

They can be created, but you can't assign them as the target - at least for field Source ones :C

What exactly doesn't work? The only thing I've found not working was the overloading. Once created manually, they could without issues be used and functioned as expected in my testing.

[Banane9]

What exactly doesn't work? The only thing I've found not working was the overloading. Once created manually, they could without issues be used and functioned as expected in my testing.

I showed you last month in a session - when you create a Source for a Nullable<> field and try to assign it as the target of a WriteObject<Nullable<>>, the target stays null. Driving works though.

[JackTheFoxOtter]

Did some more testing just now. Write and Indirect Write throws an exception when attempting to connect to any nullable data model field / store, but works with locals and stores. You can circumvent that by using dynamic variable writes to write to nullable value variables (or fields) on the DataModel, which works as expected.