Feature Deprecate _concoctionDatabaseRefreshes

[fronobulax]

As far as I can tell this preference is incremented by KoLmafia but is never actually used.

It doesn't really harm anything although when when logPreferenceChange is true it certainly clutters the session log. I know that could be handled by adding it to logPreferenceChangeFilter but I'd like to know what it is being used for, if indeed it still has any use.

So I propose "resolving" this by deleting the code that increments it or by explaining to me why it has current utility to someone.

Thanks.

 

[Veracity]

Since refreshes of ConcoctionDatabase are expensive, we'd prefer that they only happen when something in your state changes.
We'd prefer that they only happen once for each such change and, if there are a bunch of things "changing" at once - like logging in - that it happens only at the end of all such changes.

Have we finished solving that problem? Probably not, but it is not being actively worked on any more.

I never run with logPreferenceChange since THAT feature feels like "spam" to me, considering that I've never needed the output.
Of course, I generally don't run other people's scripts, so I'm never surprised at having my settings changed.

 

[fronobulax]

autoscend forces logPreferenceChange to be true. Since it is a global preference it will be true for all characters which is suboptimal if characters are being run simultaneously and not all of them need the logging. It can be useful to a script author in discovery and debugging but it is just clutter for me when I am doing neither.

Just eyeballing some logs it looks like the characters running the script have between .75 and 2.0 refreshes per adventure. The VMF character seems to be running about .5 and .75 refreshes per adventure. I am prepared to be corrected if anyone actually actually parses logs to get the numbers

If someone was actually working to reduce the number of refreshes I can see how the preference might help especially in collecting "before and after" statistics for comparable runs to see if anything makes a difference. But if it were deleted and I were working the problem I'm not sure I would restore it. My approach would be to use code inspection and the debugger to set up cases where unnecessary refreshes were occurring and then use the same tools to convince myself that changes were for the better.

 

[Ryo_Sangnoir]

Making logPreferenceChange not global would seem to solve this problem more generally, instead of solving it for one preference out of the hundreds which are logged you don't care about?

 

[Malibu Stacey]

autoscend forces logPreferenceChange to be true.

autoscend sets logPreferenceChange to true while running. It resets it to whatever it was before autoscend was run once autoscend stops running.
If some other script set it to true before you ran autoscend, blame that script.

 

[fronobulax]

autoscend sets logPreferenceChange to true while running. It resets it to whatever it was before autoscend was run once autoscend stops running.
If some other script set it to true before you ran autoscend, blame that script.

I will refine my statement - autoscend sets it to be true while it is running. Once autoscend has written that change to GLOBAL_prefs.txt any other instance of KoLmafia will start with it as true whether that was what the user expected or not. Depending upon the order things shut down it may remain set, again with no user interaction.

This issue would exist with any GLOBAL preference and multiple instances of KoLmafia running simultaneously.

 

[Veracity]

And that is an issue with people running multiple instances of KoLmafia at the same time
Something I have never done - and will never do.

I have no opinion about how KoLmafia behaves when people use it in ways that I, personally, think is a bad idea.
Let the people who choose to do do dumb things work to solve the issues...

 

[Ryo_Sangnoir]

garbo / autoscend seem to set the following global preferences:

allowNegativeTally
allowNonMoodBurning
allowSummonBurning
logPreferenceChange
logPreferenceChangeFilter

any objections to just making each of them user-specific? The two dealing with MP burning seem like they should be user-specific to begin with.

 

[fronobulax]

And that is an issue with people running multiple instances of KoLmafia at the same time
Something I have never done - and will never do.

Whereas I have run two characters simultaneously pretty much since I started using Kolmafia years and years ago. The driver has always been wall clock time. While one char is auto adventuring I can be doing something with the other. I always figured that if two simultaneous characters was a problem then the code would change to not allow it.

 

[fronobulax]

garbo / autoscend seem to set the following global preferences:

allowNegativeTally
allowNonMoodBurning
allowSummonBurning
logPreferenceChange
logPreferenceChangeFilter

any objections to just making each of them user-specific? The two dealing with MP burning seem like they should be user-specific to begin with.

I think I am fine with that knowing that some people may have to manually propagate their preferences.

There might be a case for logPreferenceChangeFilter remaining global because most of the things that are there are there because they are long and change often will be long and change often for every character and it is a preference of the human player and not what character is being played. But since I often try and imagine a world with no GLOBAL preferences I would not insist on this one remaining.