Load INI-based vanilla-compliant configs from scripts efficiently

[phobos2077]

My mods use a lot of ini settings to work. I use get_ini_setting/string opcodes present from the old sfall days. These have a few issues:

• Clunky interface (having to concatenate strings every time, compiled code is a bit ugly)
• Has performance issues (see Don't use GetPrivateProfile* WinAPI functions for loading INI #468, will partially get fixed by using custom ini parser)
• Can only load ini from normal file system, not from game databases

I'd like to separate mod configs from "player preferences", configs should be inside dat file/folder like all other files. For example, crafting schematics could be configured via INI/TXT file. Right now it doesn't seem to be possible to keep this file in the dat.

Proposed opcodes:

• 0x8285 - int config_load(string filePath, int isDb)

  • Loads and parses INI file at given filePath.
  • if isDb is 0, will search and load file from normal file system (like get_ini_string), any other value - will load from game databases (DAT).
  • Returns ID of loaded config. Subsequent calls with the same filePath will not load anything and just return the same ID.
  • Configs loaded via this opcode will be unloaded and ID's invalidated on game reset/reload. So don't save these ID's in any persistent storage such as global vars or other INI files.

• 0x8286 - any config_get(int configId, string/int section, string/int key, int type)

  • Reads data from a config ID previously retrieved with config_load.
  • If section and key are both strings, reads value from a config based on those.
  • If section is a string and key is 0, will create and return a temp map (array) where keys are section names and values are section values.
  • If section is 0, will create and return a temp list (array) filled with section names, sorted alphabetically. Key and type are ignored in this case.
  • Type allows to convert values to another type upon retrieval. 1 - integer, 2 - float, any other value - string (no conversion). Does nothing when section is not a string.

Reasoning:

• Opcodes instead of sfall_funcX because config_get might get called potentially hundreds of times. Not sure if it's a valid concern though...
• 2 opcodes instead of 1 because for once, there's an additional isDb parameter that will have to be passed every time otherwise, which is a bit weird. Also this approach fits with how the game itself uses other resource types such as prototypes and message tables. It's loaded once and you can then efficiently access the data via indexes. add_extra_msg_file is a good example of this.
• Unloading configs on reaload also fits with how most other game resources work.

Under the hood, configs will be parsed using the new INI parser:

• Fully compatible with Fallout's config_* functions.
• Configs stored as 2-level dictionary with string values.
• Sfall itself will use this same parser for all INI reads - internal and scripted (including get_ini_* functions).

[phobos2077]

Possible future extensions:

• config_set and config_save will allow to create and store mod configuration (not sure if it's needed though, since it won't work with configs loaded from DAT and you can already use set_ini_string for "preferences")
• config_load without a path to create an empty config that you can fill with config_set... probably dumb when we already have arrays

[phobos2077]

Alternative approach:

Instead of opcode, single metarule:

array sfall_func4("config_load", string filePath, int isDb)

• Loads config at given path from either DB or normal file system.
• Creates a permanent array (map) where keys are section names and values are other permanent arrays (maps) where keys and values are strings.
• Subsequent calls with the same filePath and isDb will return the same array, unless the array was disposed using free_array.

PROs:

• No new opcodes needed. Since accessing array keys is already efficient enough.
• Using existing array functionality.
• Just one function gets job done.
• Can still be expanded in future to save such array into an INI file, as long as the correct array structure is kept.

CONs:

• Less efficient, needs to allocate array and copy all strings to sfall array. If you have a big config and don't need all the data, a whole config will still be loaded.
• Somewhat inconsistent with other sfall functions that return temp arrays.