A Multi-Armed Bandit PVP Script

There was a bug where the number of minis was hardcoded to be 12, which is not true for drunken season. This has now been fixed, but the stats may be wrong with the new mini in play. To do a hard reset, type "set myCurrentPVPSeason=-1" in the CLI.

The newly implemented bandit algorithms should get you back up to speed (with the optimal mini) exponentially quickly, so one doesn't need to worry (too much) about having said stats being reset.
 
I've been getting a lot of preference change notification spam recently, and I've traced it to this script. It seems that it sets logPreferenceChange to false to avoid spam (good), but then it sets it to true afterwards, regardless of what it was originally (bad).
 
I've been getting a lot of preference change notification spam recently, and I've traced it to this script. It seems that it sets logPreferenceChange to false to avoid spam (good), but then it sets it to true afterwards, regardless of what it was originally (bad).
That's why that started happening! I thought it was a new mafia feature.
 
That's why that started happening! I thought it was a new mafia feature.
autoscend saves the old value, sets the preference to true and runs. If autoscend is not allowed to finish normally it will sometimes be in a state where it is true and not restored to the previous value. The next run of autoscend will thus restore the value to true. I tracked this down because it is a global preference and I started seeing the clutter for farming characters who weren't going to do anything with the information.
 
TBH, I generally turn it off while autoscend is starting up, with the caveat that I am basically on my own for support if it's broken.

I really need to get back on my project to provide separate logging levels for what's recorded vs. what's in the gCLI. I don't care if a script fills up my log file, but I do care if it adds so much useless clutter to the gCLI that the useful information scrolls out of the buffer very quickly.
 
I've been getting a lot of preference change notification spam recently, and I've traced it to this script. It seems that it sets logPreferenceChange to false to avoid spam (good), but then it sets it to true afterwards, regardless of what it was originally (bad).
Just pushed a fix for this. Sorry about that!
 
Back
Top