Since I seem to have real users, which makes this more than just demonstration code: yes, it would be desirable to keep configuration in per-user settings, rather than having to edit the script.
I understand that zlib provides such a facility, but I am loath to import an entire library of stuff I don't want to use in order to get one feature - especially a library that auto-updates itself. Opinions vary, but for MY code, that's a non-starter. I also don't particularly like having to look up configuration variables in a map - although that seems like a coding decision. For example, in CounterChecker, I see:
Code:
setvar("BaleCC_SrInHC", FALSE);
...
if(!can_interact() && vars["BaleCC_SrInHC"] != "true") {
and on and on. I would probably do something like this:
Code:
setvar("BaleCC_SrInHC", FALSE);
...
boolean sr_in_hc = vars["BaleCC_SrInHC"].to_boolean();
...
if(!can_interact() && !sr_in_hc) {
On the other hand, I can think of other models for dealing with this problem that I like better. How many hundreds of times have users here been told "you cannot customize this script by editing it; you must edit your file of variables"? I consider that to be a flaw.
Consider this model:
The script defines a bunch of settings with default values.
settings + defaults are clearly shown near the top of the script.
The user can edit the defaults to taste.
The actual configuration variables used within the file are taken from user setting - or, if they are not set, from the default.
Therefore, the only settings actually saved for each user are those that differ from the default. Now, once you've changed a setting, changing the default will not affect your customization - which is zlib-like - but you can use standard get/set in the gCLI to change things, rather than a special command (or relay script).
That was just on-the-fly brainstorming. I'll think more on this problem.