Let's FINALLY fix Editor Preferences in UE5

General Feedback & Requests
,
1

I’ve been using UE4 for several years now, and I am mostly happy user of it, but every time I start a new project on open someone else’s, I get a harsh reminder of how frustratingly neglected one aspect of UE is - handling of Editor Preferences.

As the name “Editor Preferences” suggest, it’s a collection of preferences related to the editor. In other words, completely unrelated to the project. Yet, for some crazy reason, they are always saved with the project. Even things that are matter of ergonomics, such as inverting middle mouse pan direction to be consistent with the DCC package you are using gets saved per project.

Imagine for example if something similar happened in visual studio. If user settings such as keyboard shortcuts were saved within the .sln file and every time you opened someone else’s VS solution, you’d also get their keyboard shortcut customization. Or if you opened someone else’s Photoshop file, it’d change your Photoshop preferences. That would be absolutely crazy, yet this craziness is somehow considered okay in the land of Unreal Engine.

To add to the confusion, UE actually makes an exception for a few specific Editor Preferences settings, such as keyboard shortcuts, derived data cache folder location or color theme (in UE5). This adds yet another layer of confusion, uncertainty and inconsistency, where not all of the Editor Preferences are saved within the project, just vast majority of them.

The Editor Preferences window is full of extremely granular settings for every aspect of the editor, allowing the user outstanding degree of customization. For example look, in just graph editor, I can tweak many different variables to adjust how the curves connecting the nodes look like, or what colors the data type pins have:

image
image1204×1012 52.9 KB

But what is the point of this? Who in their right mind would invest so much time into a deep customization of the editor when this would have to be done for every new project, or every received 3rd party project.

The reasoning from the UE developers I’ve gotten time and time again was that there are some legacy issues, and that it can’t be changed at the moment. But now, we have UE5. We have whole new generation of the engine. Now is the best time it could possibly be to finally get rid of this embarrassing legacy issue.

If this doesn’t get tackled now, and UE5 gets settled into its rails, we will have to suffer another decade or so of disfunctional Editor Preferences system, before UE6 arrives around 2030 or so. UE5 is now in Early Access, in Alpha, so if this is a breaking change, let’s do it right now! The sooner this gets addressed, the less issues it causes down the road.

It’s about time we finally get proper Editor Preferences handling that are actually saved within the editor installation (in the operating system user account scope, to be more precise), not with the projects. Otherwise, we may as well remove the vast majority of Editor Preferences, because no one is changing them anyway, exactly for this reason.

PS: Yes, I know you can copy and paste .ini files between the projects. But it’s a workaround, not a solution, and often causes some unintended issues. So please avoid suggesting it in the replies.

11 Likes
2

I know you are making a bigger point and I do agree, but the graph editor settings is a bugbear of mine. I would dearly love to be able to print bp graphs but the heavy use of black (elegant enough on screen) and a checkered pattern so even photoshop colour changes become hard, mean I have given up even thinking about it.
Unless someone knows a way…

3

Are you looking for a way to change the background color of the BP editor graph?

4

Not only is this crazy, it’s also undocumented. There is a long help page for Editor Preferences that doesn’t even mention how preferences are saved.

Nor does it explain how “defaults” work or where they are stored. Like how if you change something and click “Reset to Defaults” nothing will happen unless you’ve previously used “Set as Default”. The so called default doesn’t actually have default values.

1 Like
5

Absolutely agree, have thought about this many times before.

6

Yes, I highly suspect that the Save As Default, Import and Export buttons just don’t work properly. I remember last time I tried to migrate Editor Preferences between the projects using the Import/Export buttons instead of manually copying and pasting the ini files around (which is just inappropriate way of doing it), it did not really work at all :confused:

7

Never thought this stuff was a problem, nor are these things hard to find out:

image
image935×525 38.1 KB

image

They’re all stored in your project directory. Read further for editor defaults.

Just tested in UE5, it worked for me. You need to make sure to import them into the same category you exported them from; the files are named *Category* Backup Date.ini, and it looks like it only stores the settings for the category you export from.

You do that by editing the editor config files:

image
image656×703 45.6 KB

Those circled dates are the date I modified it. To test it, in BaseEditorPerProjectUserSettings.ini, I changed bShowFriendlyNames to false, made a new project, and it was set to false by default. Though, this will only work for projects made after the change; these are the notes as to why:

; -------------------------------------------------------------------------------------------------
; IMPORTANT:  EditorPerProjectUserSettings.ini has special behavior!
;
; This .ini file contains the defaults for many editor and engine "preferences".  These preferences
; are saved to an EditorPerProjectUserSettings.ini file in the user's /<Game>/Saved/Config/ directory. 
;
; If you change the default for a preference in here, that change will *NOT* automatically 
; propagate to users who already have saved preferences.  The idea is that we must preserve
; their existing settings and never want to clobber entries in that file.
;
; If you add a new preference, the new key and value *WILL* be propagated to the user's
; EditorPerProjectUserSettings.ini file.  After we load the user's existing settings, we'll merge in
; any missing keys and values that are present in these defaults.
;
; One easy technique for forcing a "reset" of an already-existing preference is to simply
; rename the variable for that preference.  The config system will treat it as a newly-added
; key and will propagate the change to existing users' preferences.
; -------------------------------------------------------------------------------------------------
8

1, I can’t imagine the frustration of going though every single preferences category and exporting/importing the settings one by one. That’s just unacceptable. And having to do that every time I decide to modify some of the preferences further, and having to do that in every project I open with outdated preferences. I jump usually between at least 3-4 different projects at a time.

2, You are doing exactly what I asked people to please not do in the original post. You are providing clunky workarounds. Yes, we all are aware those workarounds exist, but those are so frustrating and slow to do it just makes it not worth it to customize the editor preferences deeply, which is a real shame given than there’s so many of them and they offer great flexibility. What we need is a proper solution, not a workaround.

We need something that makes us certain that if we invest for example 4-5 hours into meticulously exploring and configuring every single editor preference to suit us and improve our productivity, we need to be certain that this configuration will be stored universally and reliably, and that we will ideally never ever have to go through that lengthy process ever again. We precisely, specifically need this:

1, All preferences will always save with the Editor installation, in the scope of operating system user account

2, Export button to export the entire editor preferences at once (not per category), used for:
A, Backing up preferences prior to machine OS reinstall
B, Migrating preferences to another machine
C, Migrating preferences to newer Unreal Engine version

3, Import button to import the entire editor preferences at once (not per category), used for:
A, Recovering saved preferences after machine OS reinstall
B, Importing preferences saved out from another machine
C, Importing preferences from the previous Unreal Engine version

4, Removal of the “Save as Defaults” button. Since the preferences do get saved immediately after they are adjusted, and the proposal expect the preferences to be saved with Editor, not the project, this button just does not make any sense and would only introduce uncertainty about what is actually going on with the preferences. As long as there is any need for this button, something is going terribly wrong with the Editor Preferences system.

Once again, I’d like to stress a point that workarounds and proper solution are two completely unrelated things.

10 Likes
9

What I’d love to see is one step further: Cloud Sync. So whenever I change some settings / colors around, it should save it in my Epic Games account (if I choose to enable it), and if I open the project on another computer (or if I create a new project, etc), it should sync it and update the settings.

5 Likes
10

Ok, yeah, I see what you mean.

Looking into it more, I found some good news: it already works halfway like you want it to. The priority order of the settings are Project → Project Defaults → Engine Defaults (e.g. EditorPerProjectUserSettings → DefaultEditorPerProjectUserSettings - > BaseEditorPerProjectUserSettings). Any setting that is missing from the project settings is read from the project defaults, and if it’s missing from there, then it’s read from the base, which is where the true defaults are.

I tested this by changing a setting in the base and opening an existing project; the change propagated to that project. I changed it back, tested again, and it propagated again. I even changed it while the editor was running and clicking “Reset to Defaults”, and it worked. So the editor already syncs settings between projects; you just have to make sure not to change it in your project (and if you do, you can just use “Reset to Defaults”).

But this still leaves you with the problem of “how do I change settings in the editor and sync it to all other projects?” Well, once you modify a setting in a project, it is added to a project-specific file. Once you click “Set as Default”, it saves it in the project’s default file. So all you have to do is copy it from the default file to the base file, and that’s it. Of course, you have to write a script to do this, but it can be done super simply in something like batch or a plugin, and once you write the script, it’s fully automated.

For the script, you just read the setting from the default file, find it in the base file, and replace the value. However, it even works when appended to the end of the base file (i.e. there are two instances of the same setting with different values); the last instance overrides the first. So really, you can skip the "replace part and just make a new section at the end of the base file called “User Defaults” and append them there.

NOTE: There are some true project-specific settings that reference directories in the project itself, but so far, I’ve found only a few, so it shouldn’t be hard to catch them (just check for either /game/ or /*project name*/ in the setting).

Once again, I get this is a workaround, but it’s simple and solves your problem. I get you want Epic to implement it natively (and I agree), but this solution will at least solve the problem on your side, as well as anybody else who needs it.

On Epic’s side, the only thing they need to do is add a “Set as Base” button that sets them in the base file; unless I’m missing something, it’s really that simple; you can even implement it as a plugin.

1 Like
11

Hi everyone! Just wanted to chime in quickly and say that this is something we are aware of and working towards. We know that a high degree of customization isn’t as useful if you feel like you have to redo the work constantly, so stay tuned for future updates in this area.

7 Likes
12

+1 on this, and thanks for letting us know @Shadow.Storm.

14

This is actually pretty high priority for the Editor UX team :slight_smile: We want your preferences and customizations for your editor workflow to be trustworthy and persist no matter what project you’re working in, so we are actively working to make that happen.

9 Likes
15

:heart::heart::heart:

16

while we are on this topic, i’d like to share a pet peeve of mine.
I wish there was a more robust way of storing folder colors.
occasionally I get new builds that result in me having to remove saved/intermediate which result in UI resets, but most annoyingly it also wipes my folder colors.

I’d be really happy if I could make sure these are properly saved, even if I delete saved/intermediate or open the project in another engine version, or take them with me if I open the project on another computer. (though I am not sure how feasible that last request is)

17

Folder colors are one of the customization things we want to make more stable and portable!

1 Like
18

Since we are talkinng at the Preferences related pet peeves. One of mine is that the “Procedural Foliage” toggle is an Editor Preference, not a Project Setting. It always feels quite awkward when I receive project of someone else, who uses Procedural Foliage and has PF Volumes in their level. I can use them and interact with them, but to create a new one, I have to change an Editor Preference.

There should be better way to let the user know they are about to use an experimental feature than having what’s clearly a Project Settings inside Editor Preferences. Some projects may need to use Procedural Foliage while others won’t.

19

i’m new and don’t know anything but would it solve it if groups of prefs could be saved/loaded/shared like any other engine asset?

20

No, preferences are not assets, and are not supposed to be treated as such. Assets are something that resides within the project, where as the entire point of this thread is to stop Editor Preferences from being stored within the project.

That being said, the Preferences can already be exported and imported as .ini file, but with a fatal flaw that it has to be done per category, and there are additional underlying intricacies as @midgunner66 described. So if the whole system is fixed properly, then it should be possible to export the entire Editor Preferences as a single .ini file and then import it into another UE installation, having the complete preferences migrated, with no exceptions.

That would more or less make them work as sort of an “asset” if that’s what you mean.

2 Likes
21

ooh! thank you :slight_smile: