Feedback wanted: Custom build where default overrides can be applied/reverted (good for UI)

Have you been missing being able to have UI Prefab instances inherit their size (and/or other properties) from the Prefab Asset? Then read on.

Prefabs in Unity have a concept of "default overrides" that ensured you could for example use Revert All on a Prefab instance but still have the instance stay at its unique position in the world. This was always the case in Unity, and the 2018.3 Prefab improvement didn't change that so far. From the manual:

However, it is sometimes problematic that these properties can't be reverted at all. Particularly for UI Prefabs, many people have found it bad for their workflows that the size of UI Prefabs instances cannot inherit from the Asset.

We now have an experimental build that addresses this that we'd like you to try and tell us what you think:

DOWNLOAD:
https://beta.unity3d.com/download/0bc89d8a1870/public_download.html

Changes in this build:

• Scale is now a default override too (it was the only property on root Transforms that weren't a default override before). More on that below.
• Default overrides can now be applied or reverted via right clicking on the property or using the component context menu. They will still not be affected by Revert All and Apply All in the Overrides dropdown.
  
• Default overrides are now marked in bold again (like they were prior to 2018.3). This is necessary since it needs to be possible to see if they are overridden or not.

All root Transform properties are still overrides by default when instantiating a Prefab. It's up to you to revert those of them that you want to be synced with the Prefab Asset. (We know there has been requests to be able to customize which properties are default overrides out of the box, but this is too big a change to consider for now.)

So for example, for a UI Prefab instance which has a fixed size that doesn't stretch with its parent, you may want to revert the Width and Height properties to they will receive updates from changes to the Width and Height of the Prefab Asset. While for a UI Prefab instance that does stretch with its parent, you may not want to revert positional fields if the instance is setup to be placed and stretch in a way that's unique to that instance.

Why is scale a default override too in this build?

It was always a bit subjective which properties should be default overrides. For vehicles you might expect that Revert All should also revert scale, while when placing trees of various sizes, it's less convenient. We've certainly heard requests that scale should be a default override too from some people, but that alone is not the reason.

Rather, it's to avoid confusion that could otherwise arise with the new changes. Currently in 2018.3 (not in this experimental build) the root Transform would show up in the Overrides dropdown if its scale was changed but not if any other root Transform property was changed. This was probably ok, since only the scale was bold, so it was not too confusing that only scale would be reverted. However, now that default overrides are bold again, it would be very confusing if for example rotation and scale are both marked bold, but pressing Revert All only reverts scale, and not rotation. By making scale be a default override as well we avoid this problem, since the root Transform will never show up in the Overrides dropdown at all (since changes to default overrides does not cause the component to show up there).

The change to make scale a default override is the most disruptive change our of the changes made to default overrides, but we believe it's needed for the other changes to be viable usability wise.

Please try out the build and let us know what you think!

 

Thoughts:

Its' really nice to be able to revert position/rotation/scale from the context menu. I didn't realize that feature had been removed from the new prefab stuff. There's plenty of cases (especially with rect transforms) where I'll want to adjust some of those values back to what the prefab has.
Being able to apply those things from a right-click menu is also an improvement.


That being said, it's really not nice that the default overrides goes into a "not overridden" mode. If I revert the position of a prefab instance, and then change the position of the prefab in the prefab view, the instance moves.
This matches how other properties work, but feels really wrong. I don't think I ever want all my objects to move. Was this an intended change, or a side-effect of cobbling together this preview? I believe we should keep the behavior where default overrides are considered as always overridden.
Isn't that why they're named "default overrides" in the first place?

All in all, I'm very positive about change 2 and 3.

Scale being a default override is... I wrote a bunch of stuff, but then I started thinking about how it'd actually impact our development. Here's a screenshot from our last game:


You see those trees in the background, and the grass patches? Each of those are prefabs. There were quite a few of those in a lot of levels - possibly 100-200 trees and 50-100 grass patches, from a set of 5-6 different variants for each. There was something like... 50-60 overground levels?
Which means that with a conservative estimate, changing the scale of only the trees with this build would have required 50,000 manual scale reverts. If we managed to revert the scale of one object per 5 seconds, that's (5 * 50,000 / 3600) ~= 70 hours of work.
When we were developing the game it was 1 second. Click prefab, change scale. So that's a 250,000X slowdown.

If it was possible to mass-revert the scale of all selected prefabs in one go, we'd still have to find all of them in all of the scenes, and revert. So even by tooling around it, so it'd still cost us a ton of time, as well as being a major pain.

How do you solve this? I can see two approaches I like:
Approach 1: Don't make prefabs into default overrides.
I don't think this means that you can't make change 2 and 3. The worry you have here:

This is exactly the behavior Unity has had for every version before 2018.3. I have never once been confused by it.



So I don't really see why it's suddenly become a large enough problem that you have to make scale not be a default override?

Approach 2:
Allow us to define this on a per-instance basis. Essentially, allow us to select "I want position, rotation and/or scale to be a default override" on every prefab. As an added bonus, you could do the same thing with all properties.
If the defaults is what they are now (all transform properties except scale are default overrides by default, all others are not), this doesn't incur a large cost in scene/prefab file size.
You could indicate this with a clickable icon next to the property if it had a non-standard value? I'm not quite sure how this feature would work, but I know that there's been a ton of instances where I've wanted script values to behave like Position, and not be touched by "revert all".


A final possible approach is to just not do any of this, and keep things as they are in the standard 2018.3 beta. I think Approach 1 is a much better solution than that - after all, it's a smaller change from 2018.2 than what the current beta is.

 

Right. This is the same as how it worked prior to 2018.3. (I have previously said this didn't work prior to 2018.3 but that was mistaken.)

This was one of the main points of this feature, which is to address the issue raised here and here: That you can't have default override properties in instances sync with the Prefab Asset. Several people have requested that changes in UI Prefab Assets automatically update the instances and Variants of those Prefabs. That wouldn't be possible if the properties can't get un-overridden.

When you say that it's really not nice that the default overrides goes into a "not overridden" mode after explicitly reverting them, did you have this issue prior to 2018.3 too then where it also worked that way?

Right, you'd have to explicitly revert it on a lot of instances. That's the same problem others have with UI properties. Meanwhile, others have told us they don't want the scale of instances to be synced with the asset, just like you just said you don't want it for position. The problem here is that there's no objective logic for which properties should or shouldn't be default overrides. Traditionally it has been all root Transform properties except scale, which didn't suit everyone; and now we're trying all root Transform properties including scale, which also doesn't suit everyone. But for sure, the more conservative approach would be not to make any change here.

I assume you mean to not make scale a default override. And thanks, it's a good data point to know you've never been confused by it.

One thing that could potentially make it less confusing too would be to make default overrides be bold when overridden (like before 2018.3) but not have the blue line in the margin, so signal they're not overrides in the same way. There's then a relationship that only if you have those blue lines will something show up in the Overrides dropdown.

That would indeed be nice and something we've thought about as well, but it's out of scope for now.

 

Yup, whoops.

It doesn't work that way before 2018.3. I think we're talking about different things, let me make a short video to show what I mean.

 

@Baste You are not talking about this? (Recorded in 2017.2)

 

I am, but you're missing a step. Here's the video explaining it:

 

All right, thanks. The fact that you had to choose revert twice before it was fully reverted was actually a bug. It's not just default overrides that acted that way but all overrides (though not entirely consistently).

I don't think we should reintroduce the behavior that reverting the second time works differently than reverting the first time, but perhaps we could introduce "Set to Prefab Value" which would set a property to the value of the Prefab but not remove the override status? So you'd have a choice between reverting or just setting the value.

Also, did you use to use reverting (half-reverting) default overrides a lot in your workflows (prior to 2018.3) and have been missing it in 2018.3?

 

We haven't been able to fully switch to 2018.3. bug 1096124 destroys a lot of very important data that's necessary for our game to work. It also seems to crash a bunch, though getting a repro case for crashes is always a nightmare.

So all in all I haven't been able to use it enough that I've gotten a feel for it how this difference affects the work flow.

What I do know is that I've always personally assumed that the half-reverting behavior was intended. As I alluded to in the video, I didn't realize how this worked - I've never double-reverted a position before.

I also see that the double-reverting is necessary when you right-click and revert, but not when you hit the revert button. Thinking back, I've probably done most of my reverting with the revert button.

I should actually get our main level designers to comment on this. They seem to have gone home for the weekend, so I'll try to nag them about it on Monday.

 

Just asked our main level designer, and he was as surprised by the half-reverting being a bug as I was. He too assumed that that was how things were supposed to be for transform values.

This might just be one of those cases where your users assumed that the bug was intentional, and used it as a central part of the workflow.

Then again. he also pointed out that reverting transform values is something he almost never does.

 

Right, which doesn't revert default overrides at all.

Right, I think few people ever did this. What I want to ensure is that the behavior for reverting default overrides is mostly optimized for those who use it a lot and depend more on it in their workflows, than for those who rarely use it anyway.

And while I think there's very rarely reason to revert root position, there's quite common needs to revert UI attributes such as width, height, and various alignment properties. What I have heard is several people request that these can be "properly" reverted so they're synced with the Prefab Asset.

So currently I'm leaning towards having reverting default overrides work the same way as other overrides (like they currently do in the custom build). It sounds like this could work well for those who rely on this a lot, and work less well for those who rarely revert default overrides anyway, but that's probably a lesser problem.

 

I rather like this solution to the full vs half revert issue. That said, if I had to choose I'd want revert to ensure the instance is kept in sync with the Prefab Asset.

Our application has a lot of UI and our designers have created a default set of elements that should be used to create any new UI part. I've spent the past year building UI's in WPF, which makes it very easy to propagate a change to a standard element to all instances of it. My plan is to use the new prefab variants and nesting to recreate a similar workflow with an established library of UI prefabs. For that to work effectively the ability to change every instance in one go from the Prefab Asset is essential, as it'll allow me to easily respond to changes in the specifications of the base set.

It also means I'd really prefer width and height to not be overrides by default, but as you said before, there are no hard and fast rules for what should and shouldn't be an override by default. In this build we at least have the option to revert them and I prefer that to nothing at all.

I know it's out of scope for this version, but please put the ability to select which elements should be overridden by default and which shouldn't on the roadmap. A bulk edit option for this would be nice too.

 

This. That's exactly what our team has been looking forward to. Making themes and styles with a few base UI elements and their variants. Having the width, height, etc of instances be in synch with their underlying prefabs is essential for those workflows.

I think that's the best way moving forward, since people will be able to choose which way they want prefabs to behave.

I'm just wondering about one thing. I just recently stumbled upon this thread. So I have tried 2018.3.0b9 from the Unity Hub and than the editor version you provided. The editor version 2018.3.0b9 from the hub behaves differently than your 2018.3.0b9 version. So is this feature going the make it into the final release version of 2018.3 or has it been cut?

 

Experimental feedback builds should really start getting custom names. There's been a ton of confusion over this - especially in the updated UI thread, which also has a few custom builds.

The experimental builds isn't a promise of anything, it's just an experiment to see what people like or not.

 

My 2 cents.

It is imperative to allow the transform to be applied to variants. If I have a window layout, and then I create many variants of that window, which is a very common use case - then every time I change the parent window's layout, the variants must be updated. This layout change often includes changing to anchors and positioning.

Right now it requires to redo the changes to all variants, unless I'm missing something.

 

@runevision The UI workflow that I want is still not working in this custom build yet. U may check Case 1096795 for more info. The workflow is working until Unity 2018.2.

 

Right. We have no plans to make default overrides show up in the Overrides dropdown. So changing properties like e.g. anchors in a RectTransform will not show up in the overrides dropdown even in this custom build, just like changing e.g. position of a regular Transform won't show up.

It's not that we don't agree this would be useful in many situations. It's that it's very individual and subjective whether it's most useful to have this happen or not. In an ideal solution it could be configured by the user on each Prefab Asset which properties should act as default overrides, but this is out of scope for the foreseeable future. And as long as we don't have such a solution, we're not going to rock the boat now and change which set of properties will act as default overrides. (In the custom builds we tried making scale be a default override for consistency with the rest of the Transform properties, but have now decided against that as well due to negative feedback.)

I'm not sure what you mean. The case specifically is about which things show up in the overrides dropdown and there was no overrides dropdown in 2018.2.

 

Ya. I mean in 2018.2 I can apply all the changes especially anchors in a RectTransform from Prefab Instance. Seems like currently there is no plan to return back this feature.

But I found that there is a proposed fix that can return my workflow back in another form i.e. entering Prefab mode from Prefab Asset. I have updated the info at Case 1096795.

 

That is possible in the custom build that this thread is about by right-clicking on the properties and choosing Apply.

I see, you'd like a parent environment canvas to be used in Prefab Mode even for Prefabs that have a Canvas themselves on their root. That's something we can think about. It's unrelated to default overrides though.

 

1) Awesome. Will this feature be merged into actual Unity 2018.3 anytime soon?

2) Is there any plan to return Apply button and put it somewhere at this UI?

 

We're trying to get it into 2018.3 but the chances are slim, as release management is currently wrapping up 2018.3.

No. It was removed because our user research showed that too many mistakes were made when applying all changes on a Prefab instance without seeing an overview of what those changes are. The new design with the Overrides dropdown has been met with overall very positive feedback with people telling us that it has solved that problem for them.

 

I see. Then can you merge Apply to Prefab and Revert into one column instead of needing to go through Modified Component?

 

Does that mean we'll have to wait till 2019.1 or can you sneak it into 2018.4?

 

You have can Added Component, Modified Component, Removed Component. The context is important to be able to properly understand what apply and revert means and does.

We considered doing it and have menu items like "Apply Modified Component to Prefab 'SubCanvas'" but it made the menu items - and thus the whole menu - much too wide, particularly since Prefabs can also have long names on top.

 

You can change to something like Apply Modified Component to Prefab 'SubCanvas -> Apply Modified Component and Revert -> Revert Modified Component. I think it should provide enough context. You dun really need to go through one level of menu to another level of menu and it takes longer time to apply changes.

 

There can be multiple apply targets, and it's important to make it clear which apply targets will apply the property as a value and which will apply it as an override. See https://docs.unity3d.com/2018.3/Documentation/Manual/PrefabOverridesMultiLevel.html
This is one reason we can't make it as short as you're suggesting.

 

It seems it will be in the first patch of 2018.3.

What we ended up with was the most minimal change possible, which is also quite close to how things worked in previous versions:

• Default overrides are bold when overridden (like in previous versions of Unity). Since they are overridden by default, this means they're bold by default.
  
• Default overrides don't have the blue margin (to differentiate them from normal overrides) and won't show up in the overrides dropdown (otherwise it would always display overrides and never be "clean"). Blue margin and overrides dropdown are for regular properties that only get overridden when explicitly changed by the user.
  
• You can apply and revert default overrides by right clicking on the individual properties. They will sync after that, similar to regular overrides, and like in previous versions of Unity.

 

Really glad to hear this. ^^ You wouldn't happen to have a (rough) eta on the 2018.3 release?

 

It kinda popped up in this thread, but was dropped, so I'll bring it back up:

Consider adding a thing to the right-click menu that sets a property to overridden. There's instances where I'd want the prefab instance to have a value overridden, but still have it be the same as the (current) value of the prefab.

It's not critical - right now we can achieve that by wiggling the value about - but it would be nice.

 

@runevision I see that it's possible to revert default overrides by right-clicking on the individual properties, but would it be possible to get the option to "Revert to Prefab" the entire root RectTransform component? This is something I do frequently and I would find it useful to have this back.

(Please let me know if I should post this somewhere else.)

In Unity 2018.2, I was able to right-click the RectTransform and "Revert to Prefab" all the default overridden RectTransform values in one step:



In Unity 2018.3 and 2019.1, this "Revert to Prefab" option is gone so I have to manually Revert Pos X, Pos Y, Width, Height, Anchors, Pivot, etc.



Or did I miss something and this option is available somewhere else?

For example, I noticed that there are also "Revert All" and "Revert" buttons for overridden components in this menu:



But the default root RectTransform overrides do not apply to this menu and thus the revert button is not available for these overrides:



(Personally, I think the default root RectTransform overrides should show up here but I understand from this thread that this was an intentional decision.)

I also understand that this may not be a common use case but I would appreciate if there was a way to revert the default root RectTransform to the prefab values in one step.

 

Wow, this looks like a reasonable resolution for the transform inheritance paradox. I should note that it was almost impossible to notice this lovely addition if I didn't skim this topic. Thanks to all.

 

@runevision @sonnyb

So what is the status of this case now?
Is there a way to revert a whole Rect Transform to the prefab, or is there a way to change the default overrides of the prefab.

It is really annoying, to revert all the properties one by one, especially when prefabs are used for UI elements.
Because when there are multiple variants and nested prefabs inside nested prefabs, it is really mundane.

Maybe, some simple script could solve/help with this? But the documentation is quite sparse so it is actually hard to come up with something.

 

@W_M_Reszke I haven't heard any updates regarding my previous suggestion on getting back the option to "Revert to Prefab" the entire root RectTransform component.

 

Necroing because the ever helpful Ciro pointed me here while i had the same frustrations as voiced here.

I think i understand the issue, and its quite hard to solve. There probably isnt a one-size-fits-all solution, and although adding settings isnt ideal maybe its something to consider here.

Besides a property value, and if its overwritten, a new setting could be introduced to either lock or unlock the value. By default the exact same properties are locked as they are now, but it allows us to unlock (or even lock!) properties at our own discretion.

Manually modifying it is not ideal, but it does make it insightful and makes it workable. To be honest, at the moment working with prefabs and UI is a pain.

 

This would still have the problem that you'd have to go and do this on every instance of a Prefab.

I think if we were to introduce customization, we'd let you control on the Prefab Asset which properties should be treated as default overrides or not and then that would take effect for all instances of that Prefab Asset.