Has anyone fixed Nested Prefabs yet or could the Unity Community just fix them?
How hard would it be to fix nested Prefabs from this side of the Unity fence?
On the face of it you have a branching set of data with nodes or groups of nodes as prefabs.
The concept is that if you change a root prefab all of it’s children are updated.
From a code perspective this is just basic Object Oriented Programming and Instances of a Class with adaptations using Inheretence to extend unique features from the root or base class.
Could we adopt an OOP approach to Nested prefabs.
It just seems silly that this feature which is so similar in domain to OOP’s Inheritance and class system is still at the bottom of the Unity R&D barrel.
I’m sure like OOP there will be ways to make Prefabs that won’t work or are too complex, but as OOP has already addressed these issues and problems surely this is the way to go?
For instance compilers tell programmers off for trying to make crazy inheritance trees, maybe it’s just the technology we need to use for prefabs?
What if we use the existing prefab system as a bare bones skeleton (single transforms only), create a prefab class or classes that assemble the bones when Instantiated.
The prefab system would need to work in editor mode to store the offset and hierarchy and data of the ‘bones’ in an appropriate data format (ScriptableObject?).
So we would end up needing a Prefab class, scriptable objects as data templates and existing prefabs as bones.
I don’t need nested prefabs. They’re basically just a nice idea more than a truly useful thing IMO. A large % of people will end up nesting all the things then deleting something far back in the chain and then coming to Unity screaming in tears with pitchforks through their own negligence and stupidity.
The other % will make great use of them.
If they don’t change my development times, why would I care? Really, are they going to stop me procrastinating on forums and generally developing games incredibly badly?
So maybe we need to consider a backup or prefab history system.
In theory nested prefabs should allow you to make changes to single elements that update all users of that element, so it depends on how complex your prefabs are and how many types you have. E.g. changing the Attack value of all short swords across every type of soldier that carries them.
Don’t be so tuff on yourself we all procrastinate and have bad days and not everyone can be a John Carmack game programming genius. Just keep plugging away at it!
Either the swords are separate prefabs, so each sword already has its own attack value. Or the sword is part of the character’s prefab, in which case you don’t want other swords’ values messing with your character’s values.
Ok I get it now, because with nested prefabs, you could have the sword prefab already come linked with your character prefab, by default.
But the advantage of that is minimal, because if you’re going to program an entire system in which you change weapons, drop, pick up things, you don’t have much benefit from character’s prefab having a sword by default … you’re better off the character spawning hands free, and then spawning in his hand the item he’s carrying, maybe it’s a sword, or a lance, or a carrot!
I’ve always thought nested prefabs would be well suited for ugui as a perfect complement to the feature … but that’s been out for years and nested prefabs has been something asked about for years (with various third party assets tackling it, something like that which is so core to the editor you expect official support on and for it to be done right… I mean perfectly )…perhaps they should just do a proper theming system and other improvements for ugui components and gui layout tab stuff instead of whatever it is they can’t seem to get done for the prefab improvements because its obviously not easy for them given the time they’ve had to try figure it out.
Again, this isn’t a job for prefabs. You can build an in-engine character customisation system in an afternoon, and that’s including getting fancy and making it so it automatically handles new models being imported. You’re inventing problems.
… for both good and evil. In other words, it would let you wreck a ton of stuff at once as well.
Pretty much feel exactly the same. I think they would be nice to have, but, frankly, I don’t need them. And given the complexity of the feature, I… (tries to find a non harsh way to put it…) … think there could be challenges if not 100% bug free on release. Minor problems could wreck a lot of work. And lets be honest, the same folks that would heavily lean into/depend on something like this, are probably the same ones not using a vcs.
I have built a few solutions for this over the years, but the best one built was effectively a style sheet system for uGUI(and nGUI). Rather that prefabs, it allows to store/subscribe/override attribute collections on UI elements. So you can fully define a type of “button” for example with a couple of styles, and then update it project wide. It works with anything really, but most useful for UI. TMP uses style-like predefined materials, I would love so see more things in that direction. Shared style elements are great for UI… nested prefabs, just to don’t see much of use for it, beyond ruining noobs fun by giving them the power to trash their whole project.
Agreed. This is something you want to do programmaticly/data driven, not with prefabs. Prefabbing it would add extra steps and editor/multiple dependencies.
UI is probably the place where I’d use nested prefabs the most. It’s easy to want a button prefab and a window prefab and a UI prefab in a simple project.
When I do find myself wanting this I tend to make all to the prefabs then join them together at runtime via code. It works after a fashion, but it’s not amazing.
Feel free. I’d be happy to. I can’t share the code, but can answer any questions.
Part of was also using/having the styles (extended a bit) used in part for templates. Minor, but rather than duping element from somewhere else, I could spawn an element from a “template” like a “confirm button” or whatever. It worked great when you have your style pretty much sorted out already. Most of the challenges with it were user related. (bad naming of styles, etc…). It was also most effective if used primarily for visual aspects, and not too much with wiring or references. The last work I did on it was to add the ability for multiple element styles, so that a single style could encompass say, text, images, layout, etc. But it quickly became more work than it would save for that aspect.
Seems weird that all characters would share the same hair.
Sure … you could have hair as nested prefabs (to conveniently control some of the hair properties globally). And then have each character have a script to modify the hair properties locally (color, size, what
But seems like similarly complex way to have each character have its own hair, part of same prefab … and make a script that modifies some hair properties globally if needed.
Most supposed use cases for nested prefabs do seem like solutions artists and designers would have to come up with, but aren’t solutions any programmer would use.
case in point:
Now you could skip the UI prefab and make it a scene. Then you create generic window systems, and suddenly the thought of managing a hundred prefabs comes down to ten.
Nested prefabs usually look way more like a stopgap measure to what people think is Unity’s workflow, rather than getting a proper workflow built.
But consider something like a cannon in a naval combat game. All of the ships have cannons of a similar design. Now let’s say we give the player multiple ships to choose from. So there are now two ‘natural’ prefabs levels, the cannon and the ship. Unity only let’s you build one of them by default.
If you think through it, it’s fairly easy to come up with dozens of use cases for nested prefabs.
For the record, nested prefabs sound like a better idea then they probably are. There are so many edge cases that I’m not sure it could be implemented smoothly. It’s easy enough if you don’t do any customising. But that’s one of the strengths of the prefab system.
Same logic as the character and sword. Cannons don’t need to be a nested prefab, just a different prefab. If you’re going to make a script to control what cannon the ship will have either way, nested prefabs only get in the way. Just have a ship prefab, then add all the cannon prefabs you need with your customizable cannon system.
This is all not to say nested prefabs are a bad thing. If Unity already had them, I’d say keep them. But also seems like there has been a of of fuzz about it, too much.
I think nested prefab symbolizes something, it symbolizes our fears and desires, and deep down we all need to have our own nested prefabs, that thing that’s missing, that last piece of the puzzle, the holy grail that keeps us going.
I miss nested prefabs a lot when rigging my UIs if my canvases needs to be a prefab, or even if I need a panel to be a prefab and some other thing nested on it also needs to be a prefab (or even the 3. But then we would need something to pin values by instance so if I apply the changes I made to a button, their onClick listeners won’t get cleared… But I guess all of these was addressed in the official feedback thread for the nested prefabs.
Doing Arowx’s way we would have a visual representation of that character, if this character is instantiated on the scene (not in playmode, but a character on the scene) you wouldn’t need to click on him and look through its mono behaviors to find which weapon he is going to be using when the game awakes.
It’s funny how you guys don’t want something to be implemented just because you won’t use, “I can do this by code so we don’t need it so it shouldn’t be implemented”. For me the more way of doing the same thing the best.
)…perhaps they should just do a proper theming system and other improvements for ugui components and gui layout tab stuff instead of whatever it is they can’t seem to get done for the prefab improvements because its obviously not easy for them given the time they’ve had to try figure it out.
