If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Suggestion: In the map file, include with each setting:
* the name of the script that initially set it
* the date it was originally set
* the name of the script that accessed it last
* the date it was last accessed.
That should go a long way towards the problem of "does anything use this setting any more, and if not, can I delete it".

If you aren't sure it's used by anything, just delete it. A script that uses that setting will just reset it to the default value next time it's run.

I have plans in the wings for some kind of online user-editable documentation, where script authors and users alike can add which scripts use which settings and what they do. Users will also be able to edit their settings online (where the documentation is) and fetch that edited map from the server. This release has taken my scripting energy for the nonce, so don't expect it in the immediate future.

If you aren't sure it's used by anything, just delete it. A script that uses that setting will just reset it to the default value next time it's run.

You dramatically underestimate the OCDfactor of your colleagues here. I am already concerned that, right this very minute, I MIGHT HAVE SOME EXTRA SETTINGS THAT I DON'T NEED. Or even worse, I might DELETE A SETTING THAT WAS OPTIMAL AND REVERT TO AN INFERIOR DEFAULT!!!

I hate to shout, but this is our collective sanity on the line. Or over the line.

That was actually one of my design considerations. I originally designed a record for settings that included the script using the setting. But I realized that several things about the implementation were better simpler, and decided to leave the calling script information out of it, and use the script prefix idea: callingscript_settingname.

I also knew that I could trust my fellow OCD script authors to keep the settings file organized by following the naming conventions I wrote about at length in the above post.

Sorry for what I'm sure has been a flurry of annoying popups lately. This (Build 4) should be the last of the semi-unnecessary ones! The new system seems fairly stable. Any further popups will be due to bugfixes or Super Awesome Things, both of which are quite necessary.

My $0.02: Better to have a setting with a clear parent that is also incidentally accessed by something else, than a setting with no clear parent. If a script attempts to set the default, it should claim it with a prefix; if others want to access it, that's OK. That way every setting has a connection to the script that set it, and you have a chance in hell to figure out what it's for.

So basically, I'd recommend doing away with "common settings" and give them all a prefix - the script which created the setting.