Feature Sync prefs to KoL notes section?

[IronTetsubo]

I'm likely a little different from most folk, in that I regularly play from multiple locations. this is vaguely annoying as various prefs don't work well because kolmafia doesn't have a way to know what the status of them are, and even beyond that it's painful to have to update settings repeated. Now, I'm guessing this is a non-starter, but hey, may as well ask before assuming it will be rejected - thoughts on me putting together a feature to persist the kolmafia preferences to the "notes" section of your kol account quest log? Given the 5k character limit, I'd have to compress/zip them (and likely only include non-default prefs, since even compression likely won't do the trick). Now, I can work around this on my own by (outside of kolmafia) persisting the various files via another service like dropbox, but figured I'd throw it out to see if there was any interest in this. To minimize server traffic, I'd only persist the prefs on logout (and read on login), and again the absolutely bare minimum to meet the goal of having the same kolmafia experience when logging in from different locations.

 

[Theraze]

http://wiki.kolmafia.us/index.php?title=Dropbox

Thought there was a rejected FReq for the reasons you've pointed out as well, but not finding it currently. Anyways, the how-to directions for syncing settings with Dropbox are attached, from the wiki.

 

[IronTetsubo]

http://wiki.kolmafia.us/index.php?title=Dropbox

Thought there was a rejected FReq for the reasons you've pointed out as well, but not finding it currently. Anyways, the how-to directions for syncing settings with Dropbox are attached, from the wiki.

Ah? I didn't see anything in my cursory searching before which is why I asked, my apologies if I missed it. And indeed, I'm good with doing it myself outside of kolmafia, but wanted to ask first before assuming it was a waste of time to take a stab at.

 

[roippi]

5k characters is definitely not enough. There's ~24k in my user_prefs file alone.

I think proxy stores data in the combat action bar to sync states. That's limited to 2^16 characters, which is probably juuuust enough between global_prefs and user_prefs. Although users can specify their own preferences, arbitrarily inflating the size needed. And, of course, the CAB can be used for combat actions, which eats into the available space. So I think that is not an option, either.

Generally, most people find either dropbox or thumb drive works sufficiently.

 

[Theraze]

24k... wow. Mine vary between 34-35k each. Nothing custom, except that scripts have added...

 

[Veracity]

When Xenophobe implemented the CAB, he included instructions on how it could be used for data storage for external programs, like Greasemonkey scripts and KoLmafia. I believe kolproxy uses this mechanism. Here is what he said:

Combat Action Bars use a script, actionbar.php, to store and retrieve action bar configuration data. actionbar.php?action=fetch outputs a JSON object describing the configuration data. actionbar.php?action=set&bar=[json string] sets the configuration data and saves it on the server (and should always be called using a POST request, and, yes, you can do this with AJAX.) This information is loaded using AJAX as needed when the combat action bars are initialized.

Of note is the fact that the server does not modify the JSON object in any way when it stores it. Because of this, any of you intrepid third party application developers can use this function to store arbitrary string data for users of your scripts or programs, providing you heed the following caveats:

1) There is an internal 65535 character limit on the storage. Play nice and be frugal in what you store; you have to share this with everyone.

2) You must not modify the variables "whichpage" and "buttoncache" in any way. The Combat Action Bars script subjects the values of this data to very stringent syntax checking, and if the data is not syntactically correct, the script will completely destroy the entire JSON object, both server side and client side. Similarly, if the string that you store is not a legal JSON object, aforementioned clobbering will occur, so be careful how you interface with the script.

3) Don't call actionbar.php excessively. There's no hard or fast rule here; just use common sense. Try to group together individual changes as best you can.

I think it's not a bad idea, but after hearing a variety of reports from people over the years who lost their CAB, I'm leery. Eleron tells me that CAB bugs in KoL itself have all been squashed and it's safe, modulo bugs in user programs - like the old Greasemonky Battlefield Counter, which stored its data there, but not always correctly, it seems.

I envisioned keeping a local copy of the settings on the computer you are currently running from, as now, but synchronizing with the CAB when you log in and log out. So, if the CAB really truly has a more recent version of your settings when you log in, over-write your local preferences with what is in the CAB.

I do not want to see the bug reports from people if we trash their CAB - or if we trash their saved settings.

This is a scary feature. Even putting it in the notes section is scary, since that is available for users to edit and use as they choose.

 

[Veracity]

I think proxy stores data in the combat action bar to sync states. That's limited to 2^16 characters, which is probably juuuust enough between global_prefs and user_prefs. Although users can specify their own preferences, arbitrarily inflating the size needed. And, of course, the CAB can be used for combat actions, which eats into the available space. So I think that is not an option, either.

Oh, I think it's an option, but we'd have to compact the data.

User custom preferences worry me, though. Not that I, personally, use any.

 

[roippi]

24k... wow. Mine vary between 34-35k each. Nothing custom, except that scripts have added...

Well, that's the "vanilla" value as I'm on my desktop computer that I don't actually play on, just occasionally use for coding. I'm sure my lappy has a far more bloated file

Oh, I think it's an option, but we'd have to compact the data.

Fair. The lack of an upper bound on prefs size is definitely an issue though. in toto, I think there are enough concerns that I'd at the very least make the feature opt-in (and not opt in myself).

 

[bordemstirs]

Alternatively, you could choose which preferences you'd like to save and use a login/logout script to store them in your quest log. I do this with my bot for when we change host computers.

PO is a semicolon-delineated list of preferences to ignore in the event that rollover has occurred (one might also find benefit in automatically skipping any underscore-prefixed preference in the same circumstance)
settings is a semicolon-delineated list of which preferences to store.

void saveSettings(){
 visit_url("questlog.php?which=4&action=updatenotes&font=0&notes=");
}

boolean loadSettings(string postRO){
 boolean rollpassed=false;
 string ls=visit_url("questlog.php?which=4");
 matcher notef=create_matcher(";'\\>([\\s\\S]*)\\</text",ls);
 if(!find(notef))return false;
 string[int] setting=split_string(group(notef,1),'\\r?\\n|\\s=\\s');
 int x=count(setting)/2;
 if(x==0)return false;
 int day=-1;
 for i from 0 to count(setting)-1 if(setting[i]=="!day")day=setting[i+1].to_int();
 if(day!=gameday_to_int()){
  rollpassed=true;
  string[int] skipsplit=split_string(postRO,';');
  int[string] skip;
  foreach toskip in skipsplit skip[skipsplit[toskip]]=1;
  for i from 0 to x-1 if(!(skip contains setting[2*i]))set_property(setting[2*i],setting[2*i+1]);
 }else for i from 0 to x-1 set_property(setting[2*i],setting[2*i+1]);
 saveSettings();
 return rollpassed;
}
boolean loadSettings(){
 return loadSettings("");
}

void saveSettings(string settings){
 string[int] setting=split_string(settings,';');
 string submit="";
 foreach i in setting submit+=setting[i]+" = "+get_property(setting[i])+"\n";
 submit+="!day = "+gameday_to_int();
 submit="questlog.php?which=4&action=updatenotes&font=0&notes="+submit;
 visit_url(submit);
}

 

[IronTetsubo]

Hmm. Sounds like something you'd at least consider it if done properly, when done against the CAB (since that would give us enough room for the data when properly compressed down). I will take a stab at this, see what you all think.