New functionality to create the cloud save dirs at startup

[otavepto]

Properly fixes and closes #332

This allows the emu to create the expected directories for cloud saves at startup.
New options in the ini file configs.app.ini:

• create_default_dir=1

  This makes the emu create the default directory for cloud saves
  [Steam Install]/userdata/{Steam3AccountID}/{AppID}/

  The variable Steam Install is substituted with the path for steam_api or steamclient depending on the current method used, either regular dll/so replacement, or using the cold client loader.

• create_specific_dirs=1

  This makes the emu create the custom/specific directories for cloud saves, defined by the OS-specific ini sections:

  • [app::cloud_save::win]
    Used for Windows OS
  • [app::cloud_save::linux]
    Used for Linux OS

• When parsing a custom directory for cloud saves, the emu will substitute the variables defined in the SDK page for Steam Cloud, but they have to be defined in the ini file with a custom format.

  The variable name must be wrapped in 2 colons ::, for example:

  • Original format: {SteamCloudDocuments}
  • Emu-specific format: {::SteamCloudDocuments::}

  This makes it easier for the emu to detect variables which were not substituted (by looking for {::), and avoid creating these directories to avoid unintentional behavior.

Also added new helper functions:

• Search for a substring with case insensitive support.
• Replace all occurrences of a substring with case insensitive support.

Note:

This requires support from the python tool gen_emu_config so it has to be updated.
I've provided a complete implementation of that here, from collecting the data to properly parsing it, anyone is welcome and free to copy the code and use it however they want.

[otavepto]

This feature is currently enabled by default since it's not something intuitive that users would think of enabling at any time at all.
On the other hand, it might create unnecessary folders.

Not sure what's best, so any feedback would be appreciated. In any case, the ini flags mentioned above could be used to turn it off.

[universal963]

In general, I still prefer handling all of these in external tools like gen_emu_config, but due to all kinds of difficulties (needs tons of new parameters and/or manual setup to handle variables and such), it seems this solution is more acceptable.

[Detanup01]

Will also put your link into readme where can also generate config.
Then in this weekend some release with last 2 pr then

[alex47exe]

Just an idea here, but wouldn't it be better to use the already generated productinfo json from steam api or the config ufs subsection of that, and automatically parse the correct required paths from there, instead of asking the user to manually add them? They could be even written automatically into the ini by gen_emu_cfg...
Imo, that subsection (and other useful ones like config launch, common supported languages) should always be saved in a folder to be later properly parsed and used by the emu or other tools - at least that's what my modified gen_emu_cfg does by default (saves them in .\steam_misc\app_info\ )- of course you would need to modify your gen_emu_cfg to do that too, if you want to further improve...

[otavepto]

Just an idea here, but wouldn't it be better to use the already generated productinfo json from steam api or the config ufs subsection of that, and automatically parse the correct required paths from there

There are some usual known problems in software in general which arise when we start depending on external input:

• Format is never guaranteed, once Valve changes their schema, the emu logic will break.
  This happened a lot during the lifetime of the gen_emu_config tool, hence, parsing their output json directly in the emu would make it brittle

• Tying the emu logic to Valve's, completely inhibits abstraction and subsequently customization of the input.
  In our case for example, we wouldn't be able to prefix the identifiers names with {:: and we wouldn't be able to distinguish between non-substituted identifiers and legit folders names without some non-trivial parsing logic.

  For example, given this string {MyFolder}, we can't really tell if this is legit folder name or a reserved identifier without first parsing the entire string, then checking for the name between these braces, which complicates the logic.
  But with the custom format, we can easily scan a string for this {:: part and detect non-substituted identifiers.

By handling all of that in a tool like gen_emu_config, we lift the burden of parsing out of the emu's code and leave it to the tool.
The tool is much easier to work with and could be changed any time if Valve modified their json, and the emu will always have a guaranteed consistent format of its own.

People could then easily change the tool, without having to compile the emu.

instead of asking the user to manually add them? They could be even written automatically into the ini by gen_emu_cfg

This hurts 😄 please check the notes section at the end of this PR, I literally spent ~2 days coding this annoying parser for the C# port. I've also created a release of it to hopefully decrease the amount of later (inevitable) complaints.

Imo, that subsection (and other useful ones like config launch, common supported languages) should always be saved in a folder to be later properly parsed and used by the emu or other tools

Parsing these files directly in the emu would be problematic as mentioned above, but saving the output json files has always been the case since the earliest releases of the gen_emu_config tool, both the original, and the C# port.
For the C# port, check these folders:

• backup/ contains a dump of the original json files
• generated/<Name and App ID>/gse/extra_info/ contains the following at the time of writing:
  • product_info.json original dump of the file
  • launch_config.json a minified version of the config section which contains all the supported launch options
  • app_details.json original dump of the file

of course you would need to modify your gen_emu_cfg to do that too, if you want to further improve

Assuming this is meant for the C# port of the tool, this also hurts :/
I don't see any room of improvements at the moment, but that's why I made it open source with a very permissive license that doesn't even require attribution. People are always welcome and free to do whatever they want with it.
I'd encourage you to try the latest release, you'll find it a breeze to use and produces a good set of .ini files which you can build on.