I’m developing a plugin that needs extensive project settings.
So far I know how to add project settings and already did so, however, there are quite a few of dependencies between the settings, so I need to reset some values when others get ticked etc.
I’ve done so by using the PostEditChangeProperty function, but I found that for a large number of dependencies, this is quite the unclean approach and requires heavy hardcoding.
I’m looking for a way to create a small architecture that allows me to specify a class per settings, which also observes the state of certain other settings to trigger a reset when required.
However, it seems like UE4 does not allow me to do this easily. When registering settings, the section will get replaced instead of added to if the section already exists; meaning I can’t just keep on calling “RegisterSettings” as it would overwrite prior settings.
Is there a way to add different settings spread over multiple classes to the same section somehow?
What it would allow you to do is split up the functionality of adding your settings through RegisterSettings and handling their changes in PostEditChangeProperty into different categories or groupings. When your main custom setting class wants to call RegisterSettings it calls this function on each of its child decorator list, allowing them to fill the custom widget list before actually calling the RegisterSettings function.
Thanks, but how exactly would I go on about doing that? It’s not the pattern itself that confuses me.
Rather, I just tried to create another UObject that would be a “setting”, but I now noticed I can not have objects marked with the UProperty specifier “config” - which means I wouldn’t be able to create “settings classes” anyways.
You mentioned the “main settings class” would fill the custom widget list with its children. How do I do that though? I was under the impression I could just create a settings page by using the config specifiers. I don’t think I can add member attributes to the “main custom settings class” dynamically though.
Are you suggesting I could create the settings page differently?
I want to have a certain, “static” set of configs later on.
That set is just so big and full of dependencies that I want to have a clean architecture that lets me rather easily and in a readable format add new configs, which should then be easily managed (as in, reset to a certain value under certain conditions etc.)
So if I have 10 configs, later decide to add a new config because of a new feature, I do not want to “hardcode” how the new config behaves together with all the other configs, as that severely bloats the code.
I want to do something like creating a new object (the config), then overwrite a reset function where I hardcode the reset value, and then have a few other attributes that determine when this value will get uneditable and/or reset etc.
If that is not possible, something else along those lines.
Is your goal to be able to add configs to a single page dynamically, or are you just trying to organize your code to handle the change notification and the dependencies?
If you want to specify config properties using UPROPERTY specifiers you can use custom metadata in the UPROPERTY as well. This information could be used to determine how that property is handled in the PostEditChangeProperty. The full architecture and how you tie metadata to handler can get as complex as you want, from tying it to specific hardcoded functions all the way up to custom class hierarchies of handlers.