Ok so I didn’t know where to post this, but I’ll leave it right here, alright so:
What I was thinking is that the worldserver.conf is already bigger than I expected, I’d say to create 1 more config file, or split these configs somehow such as:
A new folder: configs / settings however
New file custom.conf.dist includes:
AUTO BROADCAST
AUCTION HOUSE BOT SETTINGS
New file loggers.conf.dist includes:
SERVER LOGGING
LOGGING SYSTEM SETTINGS
Tbh Idk how to create a new config file and to use it but hope this makes you think a bit
I agree with that, but instead of searching over 3174 lines, better having other config files by the settings category, because Im sure in the future TrinityCore will add alot more config settings so better split some configs from now.
After thinking about it I agree with +Nay that searching a DB table would be more difficult, considering the details fields are not easily read without clicking on each one.
I think the most efficient multiple file method would be two files: one for standard worldserver / rbac and one for custom configs.
How would the table structure in the DB look like? There are boolean, int and string config: the value of those couldn’t be stored in the same column unless everything was converted to string.
The point +Nay was bringing up was that the database would need to either:
[ul][li]Store everything as a string (boolean, int, string) and then have the core convert it when it reads it in[/li]Risk improper conversion
[li]Extra CPU cycles[/li][/ul]
[li]Have a field for each datatype in each record[/li][ul]Wasted overhead, each CONF setting only uses one datatype
[li]Risk improper input results[/li]Example: If the core expects a value in the boolean field but the database had the value accidentally inserted in the integer field, when the core checks the boolean field it will default to 0 (false)
[/ul]
I don’t think a GUI is a good enough reason considering someone could write a GUI to load a CONF file into input fields and edit it but nobody has bothered. IMO a table would be much more troublesome than the CONF.