_prefs

[roippi]

For various reasons, I am interested in creating my own user preferences. I would like the boolean preferences that I create to reset on rollover to false, and the integer preferences that I create to reset to 0.

Current behavior for preferences that begin with an underscore is to reset upon rollover to their value in defaults.txt. In the case of user-defined preferences, they do not exist in defaults.txt, so they reset to a blank string. Contrariwise, preferences that do not start with an underscore do not change on rollover. (that was like a triple negative, sorry)

Neither of these behaviors suits my needs, so I am forced to hardcode behavior in my login script to reset those preferences appropriately. This is kludgey at best, and requires me to alter my login script every time I add a new preference.

So, my question: would it break anything to force user _prefs to reset to false or 0 instead of blank strings?

 

[Bale]

Yes, it would break things.

I have scripts that want to see a value of "" to know that it is the beginning of the day. zlib's check_version() does the same.

 

[roippi]

I do the same in a couple of my scripts..

I guess if the behavior all along had been "reset boolean _prefs to false, ints to 0, and everything else to a blank string" everybody would be happy. But I don't intend on feature requesting something with marginal benefit that will break a lot of stuff.

Frustratingly, I don't know what to feature request, then.

 

[Winterbay]

A possibility could be to make a 3 argument version of set_property() (and whatever the internal version is called) where the third argument is "default value" and have Mafia reset the preference to that value on rollover. I am not sure if that is at all possible though, but it's an idea

 

[Bale]

Winterbay , I don't even know how that proposal is supposed to work since it resets them at rollover, not when set_property() is called.

 

[Winterbay]

Yes, but the idea I had (which may be completely unfeasable) was that when you first set it you can call it with "set_property("_property", "value", "default value")" and then at rollover it will return to the default value which would thus need to be saved somewhere (probably indicating a rewrite of the prefs-file on the way...).

 

[bumcheekcity]

For various reasons, I am interested in creating my own user preferences. I would like the boolean preferences that I create to reset on rollover to false, and the integer preferences that I create to reset to 0.

Current behavior for preferences that begin with an underscore is to reset upon rollover to their value in defaults.txt. In the case of user-defined preferences, they do not exist in defaults.txt, so they reset to a blank string. Contrariwise, preferences that do not start with an underscore do not change on rollover. (that was like a triple negative, sorry)

Neither of these behaviors suits my needs, so I am forced to hardcode behavior in my login script to reset those preferences appropriately. This is kludgey at best, and requires me to alter my login script every time I add a new preference.

So, my question: would it break anything to force user _prefs to reset to false or 0 instead of blank strings?

int checkIntPreference(string prefname) {
if (get_property(prefname) == "") return 0;
return to_int(get_property(prefname));
}

Fixed.

 

[roippi]

int checkIntPreference(string prefname) {
if (get_property(prefname) == "") return 0;
return to_int(get_property(prefname));
}

Fixed.

I need to reset booleans too.

 

[Theraze]

That doesn't reset the preference, just checks if a given Int Preference has a value and if not, returns 0. For checkBooleanPreference, just make == "" return false and to_boolean instead of to_int on the last line...

 

[roippi]

That doesn't reset the preference, just checks if a given Int Preference has a value and if not, returns 0. For checkBooleanPreference, just make == "" return false and to_boolean instead of to_int on the last line...

I know.

If I'm specifying which preferences to use checkBooleanPreference and which to use checkIntPreference, I'm hard-coding them, which is no better than my current situation of resetting them in my login script.

Again: there is no a priori way, when presented with a preference that is a blank string, to tell if it used to be a boolean, integer, float, or string.

 

[slyz]

Doesn't the daily deeds panel know if it should check for an int or a boolean?

 

[roippi]

Doesn't the daily deeds panel know if it should check for an int or a boolean?

Sometimes yes, sometimes no. Skill deeds are overloaded to do two different things if the pref is boolean or int. I'll be doing the same with combobox deeds.

But that's mostly external to my problem. Really, there are two issues, if you want to get down to the nitty gritty:

1) Functionality. Every time the daily deeds panel is instantiated, it goes through and checks every preference that you've set to make sure that they're appropriate (not blank, are the appropriate data type). This is a Good Feature until you define your own _preference that gets reset to a blank string on rollover. Oops, now your custom deed is broken.

2) Usability. Whether I define _prefs and coerce the blank strings into bools and ints, or define prefs and reset them to false and 0, I still have to hard-code each one. I can't, as bumcheekcity did, say "oh, all blank strings should be interpreted as 0," because some are 0, and some are false. Still others might be strings that I actually want to be blank. There is no programmatic way to look through my _preferences and tell which blank strings used to be what.

 

[slyz]

Sometimes yes, sometimes no. Skill deeds are overloaded to do two different things if the pref is boolean or int. I'll be doing the same with combobox deeds.

Would it make sense to separate the int and boolean versions of deeds then?

You could have BooleanPref for once-a-day deeds, and a MultiPref becomes "IntPref", for n-times-a-day deeds. For those, the user has to make sure the preference is set to true (or incremented) when the command is used.

The same goes for BooleanItem deeds I guess, with BooleanItem and IntItem (the latter doesn't currently exist I think, the user would need to do the same via an MultiPref). For those, the Daily Deeds panel could set to true (or increment) itself, when the button is used.

Again, for Skills, we could have a BooleanSkill and an IntSkill.

Another way to do the same thing would be to treat all the preferences as ints: "" defaults to 0, and you could have CustomPref, ItemPref and SkillPref. When the user specifies a maxUse, use that, and default to maxUse = 1 if not.

 

[roippi]

That.. might actually work. Separating out the deeds strictly into boolean and int versions means that I can coerce empty strings into false and 0, respectively.

Unfortunately I'll have to strip out most of the safety checking for if you are specifying a preference that doesn't exist. That's okay, I guess.

(and you're right, theres no IntItem deed, currently. I actually couldn't think of any item that would be used that way)

 

[slyz]

Unfortunately I'll have to strip out most of the safety checking for if you are specifying a preference that doesn't exist.

It could easily be created I guess

Separating out the deeds strictly into boolean and int versions means that I can coerce empty strings into false and 0, respectively.

I think I prefer the version where all the prefs are ints, actually. You could have:

CommandDeed - executes a command. Acceptable forms:
CommandDeed|displayText|preference|command
CommandDeed|displayText|preference|command|maxUse

ItemDeed - uses an item and increments preference by one if successful (and if the preference hasn't already been incremented internally by Mafia itself). Acceptable forms:
ItemDeed|displayText|preference|itemName
ItemDeed|displayText|preference|itemName|maxUse

SkillDeed - uses a skill and increments preference by one if successful (and if the preference hasn't already been incremented internally by Mafia itself). Acceptable forms:
SkillDeed|displayText|preference|skillName
SkillDeed|displayText|preference|skillName|maxUse

In every case, maxUse defaults to 1 if the user doesn't specify it.

 

[Theraze]

So in that handling, Daily Deeds needs to snapshot whatever preference before and after the execution and increment it if it's the same at the end?

 

[slyz]

For items and skills, yes, in case the user uses a preference that Mafia already increments automatically (like spookyPuttyCopiesMade, for example).

I'm not really sure how success could be checked for item and skill use: KoLmafia.permitsContinue() should be enough in most cases, but maybe not all the time.

 

[roippi]

It could easily be created I guess

Yeah. It's just a super common mistake to not capitalize something, or using, say, _libramCasts instead of libramCasts. So, I liked that feature.. ah well, out it goes.

I think I prefer the version where all the prefs are ints, actually. You could have:

That's pretty clean, actually. They will still need to handle boolean preferences, but those can just be cast to 0/1.

I'm still not sold on the "incrementing preference if mafia doesn't do it automatically" thing. Disregarding the technical problem of defining and detecting what constitutes "success," there are situations where you wouldn't want it to automatically increment. i.e. A script can increment a pref by more than one or decrement it.

 

[Theraze]

I think if you want to check for booleans, you can just toss a to_boolean on your to_int...

> ash to_boolean(to_int("1"))

Returned:
true

> ash to_boolean(to_int("0"))

Returned:
false

 

[slyz]

I'm still not sold on the "incrementing preference if mafia doesn't do it automatically" thing.

From what I gathered, when using a Skill deed button, you rely on Mafia to increment the associated preference? Mafia only does this for a limited number of skills though.

I understand that, without a sure way to check for success, you don't want to increment the preference. It would just turn into a "how many times did I use this button today" preference.