[Suggestion] Rework config distribution so updates don't override settings

[michihupf]

I don't know if it is too late for this but it would be beneficial if new releases did not override existing configs. I personally like the system that CS# uses with default configs that have different names. This would make updating way easier without extensive scripts.

Or we could change the release build to not include the config folder and provide the defaults with a separate zip. This would be more annoying for initial setup but what is one extra file?

Also this would also not break backwards compatibility because the config names don't change either way.

[marqdevx]

Hi Could you please add more details?

Which configs, used by this plugin, are getting overwritten?

[michihupf]

cfg/MatchZy is included in the release distribution, so I guess the answer to your question is all of the configs are overwritten with their default on update, unless you skip these files/create backups of configs before an update

[borzaka]

The only problematic config files are are live_override.cfg and the live_wingman_override.cfg because this is where where you set your custom config which gets overwritten with a new release. I think it would be enough to skip those configs in the release. The others are good defaults.

Or include the override exec in every .cfg file, so everyone can override config there, and not in the original file. exec MatchZy/XXX_override.cfg

[michihupf]

The only problematic config files are are live_override.cfg and the live_wingman_override.cfg because this is where where you set your custom config which gets overwritten with a new release. I think it would be enough to skip those configs in the release. The others are good defaults.

I think you are missing the point. If I wanted the default I wouldn't have opened this issue. admins.json also gets overwritten, which is a problem when not using CS# admins, which I don't but maybe someone does. I have also made changes to prac.cfg to change some ConVars and the whitelist.json is also reset on update. I think we should not cherry-pick what is included and what is not. They are config files for a reason, to change configuration options - accepting a reset to default settings on every update just because it is "a good default" makes no sense.

Or include the override exec in every .cfg file, so everyone can override config there, and not in the original file. exec MatchZy/XXX_override.cfg

Can you elaborate on that? I am not sure what you mean? Are you suggesting to have admins_override.cfg, config_override.cfg, etc? If so why not move the defaults to XXX.cfg.example or XXX.cfg.default in the release and make the XXX.cfg (without .example or .default) the "override" config - this would ensure current config setups by people are not overridden and will ensure backwards compatibility by introducing new default configs and having the currently dispatched configs be treated as override. If these names are fucky on Windows I guess we could just name XXX.default.cfg or something... depends on preference I guess.

[marqdevx]

I get it now

What do you think about a cvar to add a different path for your CFGs?

1. First it checks if the target cfg is on the custom path,
2. if not check default path,
3. if not, raw commands

[michihupf]

wouldn't that need a config to begin with (to set the ConVar)? I think introducing more code logic and modularization to tackle this is the wrong way. The core of the problem is that production configs not default configs are present in the MatchZy.zip releases.

I'd suggest the following steps:

1. Check target.cfg
2. If not present check target.default.cfg <--- this is what is shipped on release

This keeps any config changes in target.cfg and code can be reused off of the _override configs.

[marqdevx]

In my case I have not encountered that issue as I dont copy/extract the cfg folder

Although I think your suggestion is clean 👌

I will try it out :)