You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to see (most of) the macro constants in main.c migrated to a separate file that is read at launch, possibly keeping the macros as fallbacks. From a developer perspective this has the advantage of allowing custom settings without Git complaining. From a user perspective it has the advantage of not necessitating repeated compilation as well as persisting client settings that can't reasonably be hard-coded (e.g. nick).
I'm willing to take a shot at this, myself, too, but only if @fogleman agrees with the merit and would be willing to integrate the changes (notwithstanding the quality of any implementation my unrefined skills could amount to). Some specifics would also need agreeing on:
format
file path
desired settings
documentation/communication
If I had to answer those questions I'd probably pick .ini; same directory as the craft binary; support as many settings as possible; and add a sample file containing all supported settings with their default values and as much additional documentation as possible. That file probably wouldn't be read by the client but simply serve as a reference or a starting point for personal configuration, because otherwise people may edit that file directly and then versioning becomes problematic again. I'm not married to any of those ideas, however. A more Linux-y approach would look for a dot-file in $HOME or something but that would be very un-Windows-y and I don't like that.
Some specific goals I would like to achieve with this:
customizing video and keybind settings without triggering changes
I'd like to see (most of) the macro constants in main.c migrated to a separate file that is read at launch, possibly keeping the macros as fallbacks. From a developer perspective this has the advantage of allowing custom settings without Git complaining. From a user perspective it has the advantage of not necessitating repeated compilation as well as persisting client settings that can't reasonably be hard-coded (e.g. nick).
I'm willing to take a shot at this, myself, too, but only if @fogleman agrees with the merit and would be willing to integrate the changes (notwithstanding the quality of any implementation my unrefined skills could amount to). Some specifics would also need agreeing on:
If I had to answer those questions I'd probably pick .ini; same directory as the
craft
binary; support as many settings as possible; and add a sample file containing all supported settings with their default values and as much additional documentation as possible. That file probably wouldn't be read by the client but simply serve as a reference or a starting point for personal configuration, because otherwise people may edit that file directly and then versioning becomes problematic again. I'm not married to any of those ideas, however. A more Linux-y approach would look for a dot-file in $HOME or something but that would be very un-Windows-y and I don't like that.Some specific goals I would like to achieve with this:
The text was updated successfully, but these errors were encountered: