Feature - Rejected set_propertyq

Forgive me if there's already a way to do this, I couldn't find it.

It'd be semi-useful (aesthetically, at least) to have a quiet version of the set_property function, as I'd like to use it in a script that runs fairly frequently and the clutter in the CLI is mind-boggling.

This was proposed and rejected several months ago because of the potential danger regarding being able to have malicious or poorly written scripts damage installations with no possible way to trace later... if a script that was supposed to read demon names accidentally wipes them instead...

I was hoping you wouldn't say that. After all, I could still delete the demon names as is and you would still have to do some work to restore them (if possible) the only difference was you'd see it happen. Isn't there a disclaimer about using user-made scripts because of this potential?
Oh well, thanks anyway.

So would my best option be saving to file or is there a less bulky way to retain a variable across multiple scripts/invocations?

I'm marking this as rejected, although I would like to know if anyone has a solution for bordemstirs' last question.

What I do, is if I'm saving enough data that it would clutter the CLI, I save it to a data file. (Generally, more than 2 variables.) Otherwise, I save it to a property (user preference). Bonus; if you have lots of once-daily stuff, you can still save it to data files, and use a single user preference to control / monitor when the file needs to be reset / blanked.

Also, for anything that might be of value to other scripts (either currently existing or even just "I could see it happening" scenarios), I truly suggest using zlib vars. You can get into some even wonkier stuff using my std_lib (or similar methods) if you want (saving lists into properties or zlib vars).

Keep in mind, of those using KoLmafia, some rarely / never have the CLI visible, and won't care either way (relay browser people). They won't really care if you keep the CLI clean or not. Those who do pay attention to the CLI tend to be the types of folks who want to know what's going on, and therefore are more likely to dislike hidden property changes. I would postulate that such folks would be much less bothered by CLI clutter than they would by hidden script behavior -- unless it's immediately apparent that tons of properties are being set, when the data should be saved in a file.

Edit to add:

Argh, hit "post" and THEN I remember a point I'd wanted to make the last time this came up!

I, for one, would have no problem with a "silent" option for any property-setting that worked on custom properties, ie those that mafia doesn't set itself. I just don't want any of the inherent mafia properties set without my knowledge.

Also, some scripts simply have to go the mass-property-setting route. For an excellent example of how to do this in a way where the user is kept "in the loop" I recommend checking out Bale's "newLife.ash", which sets a mass of choiceAdventure properties, but also gives a bit more info via the choice-setting wrapper function he uses. This is, IMO, "The way to go" when setting lots of properties is necessary, and helped me find a couple that were worthy of "tweaking." (Which I likely would have missed if the script had simply set the properties without additional info.)

Would a compromise request for a new class of property (like... ".propertyName") that is set silently just like "_propertyName" is reset at rollover have any merit? Or am I totally left using a file to save/load data (which, even though I know that's exactly how the real properties are set, for some reason feels "heftier" to me)

Edit to add: this would ensure that only custom properties are affected by silent property settings and mafia variables would remain protected.