I’m trying to separate my settings into specific categories in GameUserSettings.ini for organization. I’ve got the default GameUserSettings to change to my custom one but I’m not seeing the ‘audio’ category that I listed.
I’d like for it to look something like…
[/Script/IronGame.IronGameUserSettings]
bUseVSync=False
bUseDynamicResolution=False
... // rest of the default settings
[/Script/IronGame.IronGameAudioSettings] // Or something similar to this
MasterVolume=1.000000
MusicVolume=1.000000
SFXVolume=1.000000
UIVolume=1.000000
Yeah, unfortunately you can’t do that sort of thing with config properties/classes.
Option 1: Move your audio settings into IronGameUserSettings. The GameUserSettings usually becomes a union of all the player configurable values. If you look in GameUserSettings you’ll already see tons of different graphics settings.
Option2: Change AudioSettings to a structure instead. You would get any nice forward declaration behavior, but you would be able to collect all the related properties in a block that you could pass around like a pointer (if that’s why you’re doing it this way).
These are just off the top of my head. I would say option one is the usual approach.
Maybe these are just part of the same big UGameUserSettings but split into separate categories based on UPROPERTY somehow. I’ll try it out later when I can.
It’s not, the error that you’re getting is because hard references (raw pointers and TObjectPtr) are not supported as config properties.
Those examples actually prove exactly the opposite. Those are completely separate classes, not object instances nested inside a game user settings. If they were nested, you’d see the values in a way that would be similar to structures. Not with separate sections.
One possible setup:
A UMasterGameSettings derived from UGameUserSettings. This would be the class that is configured in DefaultEngine.ini.
Other settings classes are derived from UGameUserSettings. Not referenced by DefaultEngine.ini.
UMasterGameSettings has object references (not config) to the other settings classes.
In the constructor, UMasterGameSettings creates default subobjects for each of the object references.
You would then have to override various virtual functions on UMasterGameSettings (ApplySettings, SaveSettings, etc) and call the matching function of the subobjects.
But I don’t know if that’s really any better than just using structure properties that are just marked as config and then just work. But it’s all about tradeoffs.