Support for alternative base folder for config files (settings.xml, banlist.xml, etc)

[Rilot06]

Is your feature request related to a problem? Please describe.

Currently you can only change the following config file paths:

• mtaserver.conf: with --config parameter when starting the server
• acl.xml: in mtaserver.conf
• server-id.keys: in mtaserver.conf

Every other config and runtime generated files (e.g. settings.xml, banlist.xml, internal.db, registry.db, etc) are hardcoded to be in the mods/deathmatch/ folder. The reason I'm writing this issue is because I'm working on a docker image for MTA:SA server, and I don't want to volume bind the whole deathmatch folder, only specific ones, like ./config:server/mods/deathmatch/config (for these exact files), ./resources:server/mods/deathmatch/resources, etc.

Describe the solution you'd like

An option for base config folder path in mtaserver.conf, like: <config_base_folder></config_base_folder> <!-- Leave blank for default mods/deathmatch folder, change for an alternative path relative to mods/deathmatch --> Maybe acl and idfile tags could use this folder as the parent root by default too.

Describe alternatives you've considered

A startup parameter for the server binary, the same way as the --config one. It could work the same way as the mtaserver.conf <config_base_folder> solution. ./mta-server64 --config-folder config (still relative to the mods/deathmatch folder, so this would mean mods/deathmatch/config/{settings.xml,internal.db,etc})

Additional context

It's definitely not the most important thing in the world, but I believe it could be a great addition. If the issue doesn't get enough positive feedback, sure, I could just bind the full mods/deathmatch folder as a volume, or do a bind for every single file, but then they couldn't easily be auto generated by the server, since docker would auto create them as completely empty files. If the issue does get enough positive feedback, then I'm willing to implement this as a PR, but I wouldn't want to make it without any discussion about it.

Security Policy

• [x] I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.

[botder]

I see no problem with this, as long as you don't break the default behavior.

[Rilot06]

I see no problem with this, as long as you don't break the default behavior.

Yep, that's obvious, I'll do it as a non-required new option, with the default being the same as now. Can I ask which of the two solutions you think would be better? The mtaserver.conf option or as a parameter for the server binary?

[Nico8345]

Yep, that's obvious, I'll do it as a non-required new option, with the default being the same as now. Can I ask which of the two solutions you think would be better? The mtaserver.conf option or as a parameter for the server binary?

How about both and param being the preferred one?

[Rilot06]

How about both and param being the preferred one?

Sure thing, that's the same way as <serverport> and --port work, parameter could overwrite the .conf one. Thanks for the suggestion, I'll start working on it tomorrow probably!