(Yes, I'm still trying to sort this out...)

My mind's eye view is that the server has a set of settings: SServerSettings. This is everything the server needs to know.

On start up, the structure is created (in main.cpp, defined in server.h).

Then, if GUI-enabled, CSettings populates it with values from the inifile - hence CSettings doesn't get passed a server instance any more - the server doesn't yet exist.

Next, all the values collected from the command line overwrite the appropriate entry in the settings structure.

And then finally, CServer gets instantiated with the SServerSettings instance reference.

To change a server setting, you call the server as you do now and it records that value in SServerSettings&.

When the server terminates, if GUI-enabled, CSettings is passed the SServerSettings reference to store to the inifile.

It's actually a fairly straight forward change in the server. The only concern I have when it comes to the client code... it isn't anywhere near as simple a model. Much of what's in the inifile isn't even for the client. So I'd keep the SClientSettings struct "unpolluted", free of GUI settings, perhaps having a separate SClientGUISettings for those.

One benefit is dropping all that code I added checking for command line options to prevent the inifile being used. The logic above handles that without any effort.

It could also help make it clear on what will persist to the inifile -- if it's not in one of the structs, it's not getting saved.