Adding new functions (actions) in any event (via GUI) of script doesn't reflect in the instances of a prefab

Unity Engine
, , ,
1

I’m using Unity 6.0 LTS. This is a prefab (Food1) with 3 functions already added to it in On Interact Event (). I’m using the scripts provided by Unity. (PFA image in the end, so these paragraphs will make sense)

I created an instance of the prefab (named Food1Instance), and added another action to the instance (related to gameobject named Objective1.5 Image). (I did not Apply overrides for this instance because objects are only available in main scene and they show missing in the prefab if I apply. Otherwise I would keep all functions inside the prefab only).

Now, you never know if you need to do changes inside prefab. So later I planned I need more gameobjects and functions inside prefab. I did so without any issues:

But the problem is, it does not reflect in the instance:

I don’t know if this is an expected behavior or some glitch/issue.

Note: This problem occurs only when I have added extra functions to the instances, e.g., the Objective1.5 Image related function. Otherwise I can add functions to the prefab and they reflect in the instance.

If I needed just one instance, I could just update my prefab as needed, create a new instance again and add the extra functions needed in the instance later. But I need multiple instances. So it would be tedious to duplicate them again and arrange where I had already placed them in the space.

My goal is, to keep as many functions/actions as possible inside the prefab only, so I don’t need to update things on muliple instances later. But I’m limited by the fact that most of the gameobjects are not part of prefab, so I can’t put all of them in the prefab.

So ultimately, it lead to me this solution only, but it has the problem I described.

Is there any better workflow to this? Or can this problem be solved? (Without using custom scripts or editing/writing any code).

Untitled
Untitled1920×3563 584 KB

2

There are definitely better workflows. :wink:

Prefabs synchronize only properties, not elements inside a list - just the list itself. Which means the override is for the entire OnInteractEvent list.
You could split that OnInteractEvent into two events - a shared and a customizable version which both do the same to gain more flexibility.

As to “better workflow” I can only offer advice not to rely heavily on Inspector-assigned UnityEvent. It’s handy for the SetActive for sure, but as the UI complexity grows, your nightmare begins. If anything doesn’t work properly you’ll now have to check and verify all events on possibly many objects, and both their prefab and in-scene variants.

Hooking up simple events in code is much, much easier and far less brittle.

And for UGUI prefabs you practically can’t avoid writing event-handling code due to the way the system works. Say you need to “pass down” an event to the canvas-based controller … you just can’t do that since that target is outside the prefab, hence no serializable reference and thus no serializable event connection.

The golden rule is to have a “UI Controller” at the root - both on the prefab level and on the canvas level. These orchestrate the event flow, and at runtime they do the GetComponentInParents to find the root UIController, register itself with the controller and/or hook into UIController events (often relayed events from other parts of the UI hierarchy).

Even if you switch to UI Toolkit you won’t be able to design the entire UI without writing all that glue code, event routing, and so forth.

You can defer much of those boilerplate implementations to AI however.

3

May I know why you’ve used the word “UI” here, for example “UI complexity”. I’m a little confused. Do you mean the UI of a game? Like buttons, menu, mission list, graphics settings list etc.

I’m using this inspector event approach for both UI elements as well as regular objects of the game, e.g., food items, a rock, a door etc. So it’s not just UI elements.

OR do you mean something else?

4

Oh my, that’s even worse. Don’t go there! You’re setting your project up for failure, those UnityEvent will become a nuisance rather quickly even at a small scale. Since you have to write code anyway, adding a C# event Action is dead simple, and more reliable to hook up.

While those Inspector-driven events … well they may or may not fire, and when they don’t, it’s really painful to figure out why. And it’s really easy to break them - cut an object, paste it elsewhere - looks fine but all events are gone. You’ll be constantly checking and re-checking all those event connections, whereas in code you can safeguard them, add null checks and immediately get notified if something is not according to expectations.

Yes I meant UI because that’s where UnityEvent is largely being used. For anything else it should only be used where it really makes sense - and I’ve yet to see such a case.