ZLib -- Zarqon's useful function library

[Theraze]

However, though I wasn't clear what you meant by "delisting of defaults" I think you're fine in this case, as values that are not present in defaults can still exist and will not be removed (quite necessary given we're transitioning from not having defaults). Usually that would mean you haven't run the script the setting belongs to yet, but it could also be used for arbitrary values. It would only be removed from vars if you set it to a value that is the same as the default.

Since this is a not insignificant change I'll give everyone loads of time to transition. Let's say... six whole months! Or maybe a year! For now, ZLib adds the default values back in to vars[] so as not to break existing scripts. But in the meantime, let's all encourage each other to be better versions of ourselves and use getvar(), not vars[].

That's the delisting I was talking about. If we parse through the vars list as currently...

boolean var_check(string vari) { 
    if(vars contains vari) 
        return vars[vari].to_boolean(); 
    return false; 
}

As long as vars contains the defaults, then var_check as it exists will continue to work. If the defaults are delisted from vars, then we need to change var_check to be a modified form of getvar to check specific values without spamming the screen, even if they happen to have verbosity up to 9.

[coandco]

Do you vprops by Veracity installed?

Doesn't appear so. Why?

[txrangersxx]

Doesn't appear so. Why?

That is required for the new property changes to work. Zargon needs to make it a dependency

[coandco]

That is required for the new property changes to work. Zargon needs to make it a dependency

Hmm. That didn't help. I installed vprops and edited my test script, which now reads:

import <vprops.ash>;
import <zlib.ash>;

print("har_farming_location is " + getvar("har_farming_location"));

I'm seeing the exact same behavior:

> zlib har_farming_location

Copy/paste/modify/enter any of the following lines in the CLI to edit settings:

zlib har_farming_location = Barf Mountain

> call test.ash

har_farming_location is The Castle in the Clouds in the Sky (Top Floor)

I'm at a loss for where to look to diagnose this problem.

[zarqon]

@coandco: That's new. Can you duplicate this issue and then open both your vardefaults.txt and vars_<myname>.txt files and tell me the values of that setting in each file?

@txrangersxx: Funny because it works for me without vprops installed.

@Theraze: Aha. This bit of ZLib loads the defaults into another global map called vardefaults:

record singlesettingdefault {
   string type;         // int, string, boolean, etc. (later can be "list of X" or filter/mask)
   string val;          // default value as initialized in setvar
   string init;         // use date for now to form groups; ideally establishing script
};
static {
   singlesettingdefault[string] vardefaults;  // stores all script setting default values
   file_to_map("vars_defaults.txt",vardefaults);
} 

So for cases where you were checking vars[] for x, you'll have to check both. This ought to behave like your previous function did:

boolean var_check(string vari) { 
    if(vars contains vari || vardefaults contains vari)
        return getvar(vari).to_boolean(); 
    return false; 
} 

If these variables aren't being set with setvar() though, there's no need to change anything, since they will never be present in vardefaults[].

This is much cleaner:

boolean var_check(string vari) { 
    return getvar(vari).to_boolean();
} 

but as you mentioned it does output those verbosity 4 alerts when trying to access settings that don't exist in either vars or vardefaults. That's a rather unorthodox use of script settings and would probably be better suited to a separate data file (imagine if BatBrain tracked happenings in ZLib vars, haha), so I'm not going to remove that friendly warning message as it is helpful for all the more "intended" uses.

[lostcalpolydude]

Based on this thread, I'm guessing that it's more than just coandco seeing that issue.

[coandco]

@coandco: That's new. Can you duplicate this issue and then open both your vardefaults.txt and vars_<myname>.txt files and tell me the values of that setting in each file?

Okay. I've confirmed the issue still exists:

> zlib har_farming_location

Copy/paste/modify/enter any of the following lines in the CLI to edit settings:

zlib har_farming_location = Barf Mountain

> call test.ash

har_farming_location is The Castle in the Clouds in the Sky (Top Floor)

Here's the setting in vars_defaults.txt:

har_farming_location	location	The Castle in the Clouds in the Sky (Top Floor)	20170516 00:41:09 PDT

When I open vars_CrankyOne.txt, the line isn't present. In fact, "Barf Mountain" doesn't show up in any text file in the data directory:

E:\Temp\data>grep -i "Barf Mountain" *.txt

E:\Temp\data>

I'm really not sure where it's getting "Barf Mountain" from when I do the zlib CLI invocation, but it's definitely there. Is there some sort of debug switch I could turn on to get more output from zlib?

[txrangersxx]

Sorry Zargon i made assumption

[Veracity]

zarqon does not use code that I write.
Nor do I use code that he writes.

NIH syndrome?

[coandco]

Hmm. I restarted KoLMafia completely, and the CLI and script invocations of zlib are now in sync once more... as the default values. I had to completely redo all of my Harvest.ash settings, but they now seem to be holding steady across Mafia restarts, and I was able to do my farming. We'll see what they look like once rollover hits. Hopefully this was a one-time thing, though the other thread that got linked here doesn't fill me with hope, as other people are complaining about their stuff getting repeatedly reset.