Pack ProtoFlux into a static asset

[Frooxius]

Is your feature request related to a problem? Please describe.

Currently ProtoFlux setups are represented by a hierarchy of Slots and Components int he scene. This is good for flexibility, but adds some overhead. It also makes it easier for anyone to open and view the node setup, which might not be desirable in some cases.

Describe the solution you'd like

We plan to add ability to pack ProtoFlux setup into a static asset and instance the nodes from it in the scene. This would remove some of the overhead and also provide certain level of obfuscation.

If some ProtoFlux code is frequently re-used as well, this will allow the same setup to be re-used across many objects and worlds.

An important thing to consider is also long term node compatibility. The node upgrade mechanism will need to be implemented at the ProtoFlux/asset level, so when nodes are changed/update, they can be updated even within already compiled assets.

Describe alternatives you've considered

It would also be possible to "monopack" the ProtoFlux setup for some level of obfuscation, but would not provide any other benefits.

Additional Context

To make this usable, we will need to first implement nested nodes. The static asset setup will contain node definitions, with node instances referring to those: https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/564

[gameboycjp]

Maybe there can additionally be an asset type that has the slot based representation, that only gets loaded on the client when unpacking? That would allow people to optimize their objects without losing the ability to modify and maintain their code.

[Frooxius]

@gameboycjp They should just keep the slot based representation for that - that's already handling that - you can already save that form into an item/asset, we don't need another format that essentially does the same thing.

The general idea is you build your ProtoFlux used the dynamic slot based representation in the world.

If you want to distribute it and optimize, you then "pack" that into the asset.

This is analogous to having source files for your application and then building a binary - you keep the source codes if you want to make modifications and another build.

[lxw404]

While this is an absolutely excellent feature, I worry that it can be abused in ways where seemingly innocuous compiled code can be snuck into larger projects that end up either causing intentional or unintentional damage to other users. Right now to find out if protoflux is malicious or un-performant, you can just unpack it and see what it's doing in an isolated environment. I'd hope prior to implementing this, there would be a way for assets to be tagged & tracked via something like hard permissions, or alternatively some way of opting into compiled code execution, or giving the user insight into the creator(s) + reasons for execution.

[Frooxius]

I don't think that problem is necessarily specific to this feature - you can sneak in problematic code into normal projects too and make it hard to find it - or even mono pack it to obscure it.

That said, we'll definitely want to implement harder permissions and systems to limit what the code can do in what context. This system wouldn't be specific to this - it needs to work both for code on slots as well as for these equally.

[lxw404]

You're correct this isn't the only context in which problematic code can be snuck in, however the observability is arguably much less in this case. Even in a monopacked instance, you could still unpack and disentangle the flux/components to understand what it's doing and you can additionally get a sense of how much is there. In a compiled instance however, there is the potential to hide considerably and arbitrarily more code. Possibly something like an indicator for the "size" of this or some other cursory metric could be useful from an end user standpoint.

I'm glad though that multiple contexts are being considered for permissions equally.

[Frooxius]

I don't think that's the case, because the amount of data in monopacked and static asset instances is effectively the same - you just get the raw list of nodes and their connections, without the transforms of individual nodes. The asset one will just be more efficient representation, but overall you could get the same from them.

[lxw404]

To clarify, this would just be monopacking but in an efficient component representation, but still unpackable ultimately?

If that is the case then I had misunderstood the premise as being a one way transform to compiled executable code.

[Frooxius]

You could possibly extract the nodes from it, which would be at the same level.

Essentially the asset would be just list of the nodes, packed into a file. Similarly monopack is list of nodes on a Slot.

[Nytra]

Would it be possible to create custom UI for the static asset component? This would be so we could change inputs of the ProtoFlux running inside.

[Frooxius]

Possible, yes.

Would we do it? No.

We already have UI for editing ProtoFlux, there is not a reason to make another and duplicate efforts.

[TisFoolish]

I can't see how having a UI in the component would be useful as any even slightly complex flux would have dozens of inputs, from refs to numbers to dynamic variables. Without first unpacking the flux to read and understand the code, you'd have no idea what input is for what and would have to make guesses. At that point you might as well make your adjustments on the unpacked flux.

[Nytra]

I was thinking it would be similar to how you can expose properties in the inspector in Unity. You could expose a specific set of inputs with names so that they would usable via the component UI. It would be a bit like dynamic variables except you wouldn't need to create extra components and it would all be self-contained within the protoflux static asset. Basically just so you can change the input values/refs without unpacking all the nodes.

[TisFoolish]

You mean like how public variables show up in unity's inspector? I think the problem with that is that there is no way to "mark" inputs as public in Flux and Res. Not to mention names.

There would be quite a lot of engineering needed to be done when dynamic variables would fill the same role

[Nytra]

It would probably need a new node similar to Dynamic Variable Input which allows typing in a name and then you can pull a output wire from it.

[Frooxius]

Like I mentioned above, we are not planning to add another UI for ProtoFlux.

If you want to edit the node setup, you'll just use the existing UI and then pack it into an asset.

If you really wanted to see the asser, you'd extract it onto a slot, so it would be essentially monopacked list of ProtoFlux components - you'd use existing UI for this also.

[ProtogenDelta]

Would it be possible to create custom UI for the static asset component? This would be so we could change inputs of the ProtoFlux running inside.

Realistically, if you were to have a case where this is a desired feature, a more reasonable choice would be to use Dynamic Variables, and their related Components, e.g. on a Parent or Adjacent Slot in the same space.

[shiftyscales]

Marking this issue as blocked by #564.