Information on MCServer

[Shadowraix]

I'm going to start on TCLAP

Wooooooooo

[worktycho]

Just to warn everyone my design is going Java style At least four new classes so far.

[worktycho]

I seem to have designed myself into a hole here. I tried to build a wrapper class for cInifile to handle the overriding, but I didn't take into account that the cIniFile API makes it impossible to handle multiple sources.

---

Does anyone have some advice for what I can do short of rewriting cInifile?

[xoft]

My choice would be to add a function to cIniFile that merges another cIniFile instance into the current one and overwrites any existing data. Then load the regular settings.ini and merge in the system-wide overrides.

[worktycho]

That would causes any overrides to be written back. I think that overrides should be temporary.

[xoft]

I don't think that's such a bad thing. The overrides are enforced by the provider, so let the customers see what kind of enforcements there are.

A bigger problem that I see is multi-value items, such as the plugins list. There's no reasonable way to define a merge on that.

[worktycho]

Its more of a UX thing. It is extremely unusual for arguments that override config to set parameters. My expectation would be that either the parameters are forced overrides, or if they change the config file, to be able to change them whilst running. An example of this is MaxPlayers, I would expect it either to be a forced override, which can't be changed by plugins, or to change the config file, in which case I would expect plugins to be able to change it.

[xoft]

Right, that makes sense.
My next idea was to add the capability of chaining multiple cIniFiles together. But then doing manual lookups using KeyID and ValueID, and iterating through all the values (as is sometimes used) will get broken.

[worktycho]

That was what I tried to implement. Iteration is not the problem. The problem is that the keyIDs will conflict between the IDs. what I am trying out at the moment is to have the wrapper hand out its own IDs and then store a map of those to the child IDs, along with which child they came from. But the map just keeps annoying me, and also the way I'm assigning keys is based on order of access, which might break assumptions in iteration.

[tigerw]

Is overriding the settings, as opposed to the linear process of writing them to file in main.cpp and having them loaded normally later, beneficial or necessary? It appears to be causing a large amount of code to written for a disproportionately small feature.