Prefabs are difficult/annoying to work with

[JulienTrue]

The problem is that prefabs are always linked to each other and can't be changed individually.
To work around that it can be put inside another node which can then be edited, or with the use of the ComponentGraphFilter, but that doesn't fix it always.

Here is an example where I struggled with prefabs:
I had a scene with a bunch of box prefabs.
Each prefab consists of an outer-invisible hitbox, which may never be rotated so it fits on the grid, and an inner box visual and hitbox which may be rotated.
I wanted every inner box to be randomly rotated, but doing that would rotate all prefabs the same.
When adding the ComponentGraphFilter and setting it to active, I was then able to rotate all boxes individually.


The issue is now they don't function as prefabs anymore, because due to the ComponentGraphFilter, their other components aren't synched anymore, and if I want to add a new script to all boxes, I either have to add it to all boxes individually, or disable the ComponentGraphFilter, which resets all individual rotations.

This is my possible solution:
I would prefer if the prefabs only link components, but can have their values changed individually in the scene, similar to how unity prefabs work, OR that the component graph filter allows values to change but still adds/removes new graphs when they change.

[JirkaDellOro]

I'm not too happy with the graph filter, it's more like a workaround. GraphInstances basically become graphs and clutter the project file.

The actual idea was to have two different behaviors when manipulating a graph instance. Doing so using the mutation system, as the editor does, synchronizes the graph and all other instances. Directly manipulating properties of graph instances at runtime, not using mutate, at runtime, doesn't alter the original graph or other instances.

Your specific problem can thus be solved using a small ComponentScript that rotates the inner cube when a graph is instantiated. See the example (also shows in the editor, just for demonstration).

It's still desirable to be able to have more control for each individual graph instance, when random changes are not sufficient. Hard to implement a system like Unitys, but maybe a graph instance could own an individual and variable set of properties that can be processed by a script.
RotateGraphInstances.zip

[plojo]

After reading Unitys documentation on instance overrides i am thinking about whether we could harness the mutators like the animation system does to at least allow individual property value overrides:

• A GraphInstance could keep track of every individual Component in its hierarchy by mapping the component to a sparse Mutator containing the overrides.
• The sychronization could work like this: changes on the Graph are applied to all its GraphInstances but NOT vice versa. After a change to the graph the individual graph instances could reapply their own overrrides.
• At serialization we could serialize the path from the graph instance down to each component and serialize the sparse mutator.
• A sparse Mutator would only contain the properies that are overridden.

The problem with this is that we could only implement property mutations but not structural changes like this. If we want to allow adding/removing components or adding child nodes like Unity does we may we need some sort of sparse serialization.

[JirkaDellOro]

plus: there are components which are not singletons, changes to one requires some identification to serialize/deserialize