Bug - Not A Bug Key-o-tron biodata preferences do not reset on ascension

[zarqon]

I just ascended from a Bugbear Invasion run to another Bugbear Invasion run, and noted that my "biodataX" preferences did not get reset. This causes issues with scripts that are checking those preferences to determine zone availability.

They also don't seem to reset when using the Key-o-tron!

EDIT: Something weird is going on. After manually setting them all to "0", the properties are still not updating when I fight the relevant bugbears. Other properties are updating successfully. Any ideas what I should investigate?

 

[lostcalpolydude]

Apparently the settings are now status[Bugbear Ship Location] instead, and mothershipLocation is also relevant. The settings have more info than the biodata settings had.

 

[Veracity]

r13327 | veracity0 | 2013-12-03 10:55:04 -0500 (Tue, 03 Dec 2013) | 5 lines

The "stills" daily deed need not check if the guild store is open unless you
are a Moxie class with the Superhuman Cocktailcrafting skill.
The Bugbear "biodataZONE" settings have been removed, since the "statusZONE"
settings provide everything those settings provided and more.

Unfortunately, we can't remove obsolete settings from your settings file.

 

[zarqon]

Aha. CanAdv is still checking the old settings, will have to fix that. Thanks!

Might have to make a feature request for "remove obsolete settings". That sounds helpful. Or at least printing a list of all the settings you have that aren't also present in defaults.

 

[fronobulax]

Aha. CanAdv is still checking the old settings, will have to fix that. Thanks!

Might have to make a feature request for "remove obsolete settings". That sounds helpful.

I've thought about this and I doubt it can happen. How do you define "obsolete" when scripts can also create settings? My definition of obsolete would be any setting that is in the settings file, does not have an entry in default and does not have a name that begins with the name of a script in the scripts subdirectory followed by a "_". I've played with this using shell scripts and the best I am willing to do is generate a list of settings that don't fit the above. Then I can at least manually decide which ones to delete (or go for a 95% solution using grep and knowing grep alone is not going to tell me all the settings since script writers do the darndest things). Note that relay scripts won't be captured as described above.

I also considered some kind of KoLmafia level logging of calls that set and get preferences, but again, that is data that someone would have to process to guarantee no desired setting was lost.

My more drastic solutions would almost certainly break half the scripts in existence ;-)

 

[Bale]

Agreement with fronobulax. Not every script uses zlib vars for configuration and any attempt to remove all obsolete settings would remove those script configured settings.

 

[Theraze]

Aha. CanAdv is still checking the old settings, will have to fix that. Thanks!

Should be fixed in r62.

 

[xKiv]

How do you define "obsolete"

Anything that was called "obsolete" (or "removed") in a commit message?

 

[lostcalpolydude]

I've thought about this and I doubt it can happen. How do you define "obsolete" when scripts can also create settings? My definition of obsolete would be any setting that is in the settings file, does not have an entry in default and does not have a name that begins with the name of a script in the scripts subdirectory followed by a "_". I've played with this using shell scripts and the best I am willing to do is generate a list of settings that don't fit the above. Then I can at least manually decide which ones to delete (or go for a 95% solution using grep and knowing grep alone is not going to tell me all the settings since script writers do the darndest things). Note that relay scripts won't be captured as described above.

I also considered some kind of KoLmafia level logging of calls that set and get preferences, but again, that is data that someone would have to process to guarantee no desired setting was lost.

My more drastic solutions would almost certainly break half the scripts in existence ;-)

There are also all the mafia-created settings for [GUI Window Name]Frame that aren't in defaults.txt. I'm not sure if that's just because no one has bothered adding to defaults.txt when adding a new window, or if it's because there's no sane default value, or if the code depends on those settings not existing when the window is opened for the first time. (That could possibly be figured out by actually reading the code, but that's not really the point right now I think.)

Anything that was called "obsolete" (or "removed") in a commit message?

You didn't really miss the fact that he was talking about how the software would recognize an obsolete setting, and that your response is 100% useless, did you?

 

[Theraze]

You didn't really miss the fact that he was talking about how the software would recognize an obsolete setting, and that your response is 100% useless, did you?

Well, presumably there would be a setting for "preference values that have been depreciated and should be wiped on login" which would need to be manually populated with the entries noted as obsolete from the commit logs. If anything automated were to happen.

 

[Darzil]

I think if we headed down that route (and I'm not certain we shouldn't), I'd probably suggest going with a list which also had messages, so when ash tries to pull them we output a message to the CLI, in a similar way to how we currently do for insufficiently specific data types, preferably saying how that thing is now tracked. There are quite a few ascension related settings that can now be handled by Quest entries instead, for example, and which we have code to generate which could be removed if scripts didn't use them.

 

[Bale]

I think if we headed down that route (and I'm not certain we shouldn't), I'd probably suggest going with a list which also had messages, so when ash tries to pull them we output a message to the CLI, in a similar way to how we currently do for insufficiently specific data types, preferably saying how that thing is now tracked. There are quite a few ascension related settings that can now be handled by Quest entries instead, for example, and which we have code to generate which could be removed if scripts didn't use them.

If we went down that route (and I'm not certain we shouldn't), I'd probably suggest that we could obsolete all settings which are hardcoded in KoLmafia for rollover reset and replace them with underscore preferences for the same purpose.

 

[fronobulax]

If we went down that route (and I'm not certain we shouldn't), I'd probably suggest that we could obsolete all settings which are hardcoded in KoLmafia for rollover reset and replace them with underscore preferences for the same purpose.

We have had this discussion before and the idea of renaming all KoLmafia preferences so that they obeyed the underbar convention was rejected because of the number of scripts that would break. Admittedly that discussion may have been hijacked by a discussion of whether the distinction between global and per character preferences was necessary.

That said, if there were were a consensus about the preference system and how to get from here to there, I would be pleased to take the lead in implementation.

I have a vision where mafia can enforce the convention that a preference created by a script is prefaced by the script's name (thus making deleting preferences from obsolete scripts trivial or easily automated).

 

[xKiv]

You didn't really miss the fact that he was talking about how the software would recognize an obsolete setting, and that your response is 100% useless, did you?

I am saying that automatic recognition of obsoleteness would likely end up doing one of these things:

1) nothing, because you realize you can't do it right
2) destroy somebody's settings that weren't obsolete
3) leave too many obsolete settings untouched
4) get you a nobel prize (or whatever is actually awarded for that) for creating an AI smart enough to download and understand all relevant source codes, design discussions, referenced information, etc ... ... and then correctly decide which settings should be kept because they are used/useful for *something*
5) get you a prize for creating a magic software 8-ball that can correctly (and every time, reliably) do the decision without understanding how

Comparatively - developers adding to a list of known obsolete settings, at the point when they actualy decide to obsolete the setting: reliable for low effort, *way much* less effort than anything more reliable.

(ETA: also, you asked "how do you define", not "how do you recognize"; that's an important distinction to make)

 

[lostcalpolydude]

I have a vision where mafia can enforce the convention that a preference created by a script is prefaced by the script's name (thus making deleting preferences from obsolete scripts trivial or easily automated).

So should Pyromania not exist? (It creates skillBurnX settings as needed, which mafia uses for mana burning.)

 

[Theraze]

The auto-preface also either breaks all existing scripts, causes script interaction to not work anymore, and/or is opt-in script-writer only and not actually mandated, which means it wouldn't really happen.

 

[fronobulax]

(ETA: also, you asked "how do you define", not "how do you recognize"; that's an important distinction to make)

We may have an issue with language. On the team that I lead if I talked to my developers about removing preferences and I said "How do we define obsolete?" those people in the room who wanted to make progress in the discussion would adopt a working definition of "define" that was functionally equivalent to your definition of "recognize". Those who chose not to do so would be acknowledged as technically correct and not especially helpful. So I feel you missed my point entirely but you did so because my language was imprecise.

For some reason, I am reminded of the following:

A man is flying in a hot air balloon when he realizes he is lost. He reduces his altitude and spots a man in a field below. He lowers the balloon toward the man and shouts to him, “Excuse me, can you help me? I am late to meet a friend, but I don’t know where I am.”

The man below says, “I’m happy to help. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees N. latitude, and between 58 and 60 degrees W. longitude.”

After a brief pause, the balloonist declares: “You must be a lawyer.”

“I am” replies the man. “How did you know?”

“Well,” says the balloonist, “everything you have told me I am sure is technically correct, but I have no idea what to make of your information, and the fact is I am still lost.”

The man below responds, “Indeed. And you … You must be a client.”

“Why, yes, I am,” replies the balloonist, “how in the world did you know?”

“Well,” says the man, “you don’t know where you are, or where you are going. You have made a promise which you have no idea how to keep, and you expect me to solve your problem. The fact is you are in the exact same position you were in before we met, but now it is somehow my fault.”

 

[fronobulax]

If every preference followed a naming convention that allowed for reliable, automated decisions about where it was used, then at least two existing problems could be solved: Settings files have preferences that are no longer maintained by mafia and settings files have preferences that were set by scripts that are no longer used. Both of these are only problems for certain personality types That was behind my vision statement and I fully understand that the difficulties of getting from here to there are significant ;-)

 

[xKiv]

We may have an issue with language. On the team that I lead if I talked to my developers about removing preferences and I said "How do we define obsolete?" those people in the room who wanted to make progress in the discussion would adopt a working definition of "define" that was functionally equivalent to your definition of "recognize". Those who chose not to do so would be acknowledged as technically correct and not especially helpful. So I feel you missed my point entirely but you did so because my language was imprecise.

Sounds to me like skipping a step. You get something that probably works, but is unverifiable. You don't have the explicit agreement on what you want to happen (definition), and instead you jump right into implementation. You agree on *how* to implement it, but not *what* to implement.
This can be sufficient ... or it can lead to wasting time when you realize that what you implemented does something you do not want (or is unacceptable to your client).

For some reason, I am reminded of the following:

I am more reminded of the one(s) where they agree on playing a song by its name, or first few words, and then start playing five different songs.
Hey, that's what they agreed to do, so it can't be wrong!


---
Also, it's not at all obvious that "obselete" should mean "a developer decided to call i obsolete". It could mean "is used to be used in mafia's source, but isn't anymore". Or "hasn't been modified by anybody in 2 years (please use a constant instead)". Or "has been called deprecated in previous point release". Or any number of other things, some of which even make sense.

 

[zarqon]

A few contributions:

1) settings being prefixed by the script would have to be enforceable to be useful. I see two options:

• Whenever a script attempts to write to a preference that doesn't exist in defaults, automatically preface it with the name of the calling script. Likewise, when it tries to read such a preference, check whether the preference exists prefaced by the script name and read that.
• Keep script-created settings in an entirely separate file. Setting a preference that does not exist in defaults would write to the separate file, and reading would read from either file, preferring mafia's over the user's in the event of duplicates (which should probably also generate a warning).

2) I'm all for the obsoletizing of settings which have been duplicated by quest settings, etc. A multistep "phasing out" of those properties would make it easy for users and authors to work out the transitions. First, print warnings when scripts access settings which will eventually be removed. Next, perhaps a month later, actually remove those settings and continue to print messages saying that those settings were removed. Finally, perhaps several months later yet, remove the messages.

3) I'm also all for the conversion of pre-underscore daily preferences to use underscores. Backwards compatibility could also be implemented fairly easily: if a script attempts to access a preference that does not exist, but a version of that setting with an underscore exists, use that setting and print a warning.

4) Something generally helpful across the board (and which would also help with any of these transitions) would be a warning message when get_property() is called for a nonexistent setting. Currently no such indicator is given.