Stronghold path included in .cfg file?

[PodeCaradox]

My idea is to separate the selection and options to two different files. The path should not be in the selection file because it can have some trouble with users who want install the patch from other users.

For edge case of multi Paths and Configs i have the idea to use Start arguments as follow: Config="arrayofconfigs" example: Config="test1.cfg,test2.cfg,test3.cfg,test4.cfg,test5.cfg,etc" Path="PathToStronghold"

On start show a Dialog for selection of .cfg file

If we add Displaying the .cfg file name in title we can also dismiss the Selection Dialog and just use the W/S keys to loop trough the .cfg files forwards and backwards. Also if we show the Path somehow(maybe only if applied it will added to the Titlebar or somewhere else) we can make it as a array(Path="PathToStronghold,OtherPath,etc") and loop with 2 keys trough it. Keys only enabled if a start argument got applied. Maybe add the keys to use as start argument to change them to whatever the user likes. :)

[Heroesflorian]

For using multiple configs, I think it might be worth to consider adding a /config/ subfolder in the ucp directory that will automatically be searched for cfg files, instead of putting a list with all config filepath strings into some commandline argument. (Independent of that, for the ucp cli would get an argument specifying the one config file that should be applied, ofc.)

Also, right now that I think of it, I'm not sure at what point in time the used config file is actually written to currently... every time some checkbox is clicked inside the ucp gui, or only when exiting the ucp gui, or...? Because I'm thinking if the ucp supports multiple configs, and the ucp gui allows editing config files (making it, among other things, a config editor as a matter of fact), then having some save / save as, apply / revert functionality might be nice.

Anyway, one issue I see with having paths be independent of cfg files entirely and in all cases is that the mapping config <-> installation path is then a manual process that has to be re-executed manually every single time, which seems tedious / error-prone, and thus a quality of life detriment compared to the current status quo.

Nonetheless, I certainly agree a split between ucp "game settings config" (or "config" for short) and "ucp gui settings config" (or "options" for short) generally makes sense for several reasons. Having path be dependent on config in all cases does have issues as well - particularly when sharing a config with other users that may have a different setup for their install paths, causing obvious (installation not found) or unnoticed (wrong installation picked) errors.

Thus I would favour, a system that allows both, config with and without install path in some understandable, comfortable and hopefully fail-save way, if possible.

---

Use cases to consider for any implementation (I hope I thought of everything relevant here, but feel free to correct me and suggest more):

1. I want to use/switch a config file created by someone else (to play multiplayer with others, or to play singleplayer with aiv/aic sets created by someone else that go with the config). Note: I want this to be particularly easy and intuitive, as I may not be willing or able to deal with complicated, lengthy or error-prone procedures for this (especially for jumping into multiplayer matches).

2. I want to create an own config file to use or test a set of changes (to develop an own aic, customize aivs or adjust other settings for singleplayer to my personal taste). I may want to share that config with others later.

3. I want to use multiple configurations of the ucp in parallel on different SHC installations on my computer.

4. I want to reference resource assets (e.g. aivs, aics, maps?) in several config files (without having to duplicate them to the location of every config file referencing them).

5. I want to keep track of which configs are currently used on what SHC installations. (Ideally, I also have some indication of what version of a config file is installed / if that file has changed since last installing it, but that may be difficult and low priority?)

6. I want to have all of the aforementioned stuff (if applicable) usable for both ucp gui and ucp cli.

[PodeCaradox]

For using multiple configs, I think it might be worth to consider adding a /config/ subfolder in the ucp directory that will automatically be searched for cfg files, instead of putting a list with all config filepath strings into some commandline argument. (Independent of that, for the ucp cli would get an argument specifying the one config file that should be applied, ofc.)

Also, right now that I think of it, I'm not sure at what point in time the used config file is actually written to currently... every time some checkbox is clicked inside the ucp gui, or only when exiting the ucp gui, or...? Because I'm thinking if the ucp supports multiple configs, and the ucp gui allows editing config files (making it, among other things, a config editor as a matter of fact), then having some save / save as, apply / revert functionality might be nice.

Anyway, one issue I see with having paths be independent of cfg files entirely and in all cases is that the mapping config <-> installation path is then a manual process that has to be re-executed manually every single time, which seems tedious / error-prone, and thus a quality of life detriment compared to the current status quo.

Nonetheless, I certainly agree a split between ucp "game settings config" (or "config" for short) and "ucp gui settings config" (or "options" for short) generally makes sense for several reasons. Having path be dependent on config in all cases does have issues as well - particularly when sharing a config with other users that may have a different setup for their install paths, causing obvious (installation not found) or unnoticed (wrong installation picked) errors.

Thus I would favour, a system that allows both, config with and without install path in some understandable, comfortable and hopefully fail-save way, if possible.

Use cases to consider for any implementation (I hope I thought of everything relevant here, but feel free to correct me and suggest more):

1. I want to use/switch a config file created by someone else (to play multiplayer with others, or to play singleplayer with aiv/aic sets created by someone else that go with the config). Note: I want this to be particularly easy and intuitive, as I may not be willing or able to deal with complicated, lengthy or error-prone procedures for this (especially for jumping into multiplayer matches).

2. I want to create an own config file to use or test a set of changes (to develop an own aic, customize aivs or adjust other settings for singleplayer to my personal taste). I may want to share that config with others later.

3. I want to use multiple configurations of the ucp in parallel on different SHC installations on my computer.

4. I want to reference resource assets (e.g. aivs, aics, maps?) in several config files (without having to duplicate them to the location of every config file referencing them).

5. I want to keep track of which configs are currently used on what SHC installations. (Ideally, I also have some indication of what version of a config file is installed / if that file has changed since last installing it, but that may be difficult and low priority?)

6. I want to have all of the aforementioned stuff (if applicable) usable for both ucp gui and ucp cli.

1. In the new UCP you can save and load Configs, maybe yes a folder would be nice to load more than one Config or a search of all subfolder where UCP is in, but how display them? (on start with selection which one you want to use and which currently is applied to that Stronghold path you have currently?) AIC/AIV you want to be inside of the config or how you mean that, because this should be later in the Modloader some Guys want to build?(i mean the aic/aiv files)

2. Same thing Load/Save config in UCP with new GUI will be easy

3.How you want them in parallel, every time a new UCP window or maybe with a selection Window of all found Configs you set paths for with also selectable Stronghold Paths from a extra file you just have Paths to different Strongholds?

4.This will be need some more discussions if this will be in UCP or in a modlader. In future UCP will be for Modder and a Modloader for users that want specific mods?

5. Yeah some indications would be nice inside of Stronghold like ModPack(nameoftheConfig) used in Stronghold? Or maybe Hash all selection together for version?

6. Should be possible with the redo of GUI and UCP library behind. they will use the same name keys for the selection names.