ZLib -- Zarqon's useful function library

In my experience most weird issues dealing with file creation/reading failure are permissions related. Hey, people who have this issue: is your mafia installation located, for example, in Program Files? You won't get a stack overflow anymore, but if you test using matt.chugg's method above you will still see the purple messages about attempting to access a nonexistent setting.
 
I believe the certificate is fixed now. Was pretty nice to see that the Map Manager fix from last time worked to prevent constant errors in the event that the domain was inaccessible.
 
zarqon said:
I believe the certificate is fixed now. Was pretty nice to see that the Map Manager fix from last time worked to prevent constant errors in the event that the domain was inaccessible.
Click to expand...
Fix either did not work or has not propagated yet. Map Manager did not update and Registry is not happy.
 
fronobulax said:
Fix either did not work or has not propagated yet. Map Manager did not update and Registry is not happy.
Click to expand...
I'm seeing the same thing. curl -v <yourURL> still returns the same cert. Has your provider given you a timeline for this to be installed?
 
zarqon said:
Ok now it's fixed! Sorry y'all.
Click to expand...
Passes my tests. Thank you.

Code: 
* Server certificate:
*  subject: CN=www.zachbardon.com
*  start date: Mar  1 13:45:47 2021 GMT
*  expire date: May 30 13:45:47 2021 GMT
*  subjectAltName: host "zachbardon.com" matched cert's "zachbardon.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
 
Got an odd SSL error when trying to update ZLib this morning:
Code: 
zlib not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: SSL handshake failed:  'Remote host terminated the handshake'
 
Magus_Prime said:
Got an odd SSL error when trying to update ZLib this morning:
Code: 
zlib not checked - exception: org.tmatesoft.svn.core.SVNException: svn: E175002: SSL handshake failed:  'Remote host terminated the handshake'
Click to expand...

I got a different error today, also due to SSL handshake exception, but it was trying to update the faxbot data from SourceForge. I see SSL exceptions occasionally but they are intermittent and not repeatable. For example, I did not get one checking to see if zlib needed an update. Not sure this is a zlib problem or a mafia problem that can be debugged and fixed.
 
what happens if you go to the zlib directory and do an svn update from the terminal/command line?

Code: 
Michaels-MBP:zlib mcroft$ pwd
/Users/mcroft/Library/Application Support/kolmafia/svn/zlib
Michaels-MBP:zlib mcroft$ svn update
Updating '.':
At revision 51.

Michaels-MBP:zlib mcroft$
 
I'm seeing some weird behavior where, if setvar() changes the default value of a variable, and the user has no custom value for that variable, then getvar() does not pick up the new default value immediately.

Here are my test scripts:

Code: 
// alice.ash
import <zlib.ash>

string owner = 'Alice';
string owner_color = '#00ffff';
string dog_default_name = 'Ace';

string var_name = 'test_dogname';
print(`I am {owner}. I want to name my dog '{dog_default_name}'.`, owner_color);
print_html(`- <tt>vardefaults['{var_name}'].val == '{vardefaults[var_name].val}'</tt>`);
print_html(`- <tt>vars['{var_name}'] == '{vars[var_name]}'</tt>`);
print_html(`- <tt>getvar('{var_name}') == '{getvar(var_name)}'</tt>`);

setvar(var_name, dog_default_name);
print_html(`I called <tt>setvar('{var_name}', '{dog_default_name}')`);
print_html(`- <tt>vardefaults['{var_name}'].val == '{vardefaults[var_name].val}'</tt>`);
print_html(`- <tt>vars['{var_name}'] == '{vars[var_name]}'</tt>`);
print_html(`- <tt>getvar('{var_name}') == '{getvar(var_name)}'</tt>`);
print(`----- Good bye, {owner}! -----`, owner_color);

Code: 
// bob.ash
import <zlib.ash>

string owner = 'Bob';
string owner_color = '#ffcc99';
string dog_default_name = 'Bella';
string var_name = 'test_dogname';

print(`I am {owner}. I want to name my dog '{dog_default_name}'.`, owner_color);
print_html(`- <tt>vardefaults['{var_name}'].val == '{vardefaults[var_name].val}'</tt>`);
print_html(`- <tt>vars['{var_name}'] == '{vars[var_name]}'</tt>`);
print_html(`- <tt>getvar('{var_name}') == '{getvar(var_name)}'</tt>`);

setvar(var_name, dog_default_name);
print_html(`I called <tt>setvar('{var_name}', '{dog_default_name}')`);
print_html(`- <tt>vardefaults['{var_name}'].val == '{vardefaults[var_name].val}'</tt>`);
print_html(`- <tt>vars['{var_name}'] == '{vars[var_name]}'</tt>`);
print_html(`- <tt>getvar('{var_name}') == '{getvar(var_name)}'</tt>`);
print(`----- Good bye, {owner}! -----`, owner_color);

And here is my gCLI output in a new KoLmafia session:

Rich (BB code): 
> alice.ash

I am Alice. I want to name my dog 'Ace'.
- vardefaults['test_dogname'].val == ''
- vars['test_dogname'] == ''
- getvar('test_dogname') == ''
I called setvar('test_dogname', 'Ace')
- vardefaults['test_dogname'].val == 'Ace'
- vars['test_dogname'] == ''
- getvar('test_dogname') == 'Ace'
----- Good bye, Alice! -----

> alice.ash

I am Alice. I want to name my dog 'Ace'.
- vardefaults['test_dogname'].val == 'Ace'
- vars['test_dogname'] == 'Ace'
- getvar('test_dogname') == 'Ace'
I called setvar('test_dogname', 'Ace')
- vardefaults['test_dogname'].val == 'Ace'
- vars['test_dogname'] == 'Ace'
- getvar('test_dogname') == 'Ace'
----- Good bye, Alice! -----

> bob.ash

I am Bob. I want to name my dog 'Bella'.
- vardefaults['test_dogname'].val == 'Ace'
- vars['test_dogname'] == 'Ace'
- getvar('test_dogname') == 'Ace'
I called setvar('test_dogname', 'Bella')
- vardefaults['test_dogname'].val == 'Bella'
- vars['test_dogname'] == 'Ace'
- getvar('test_dogname') == 'Ace'
----- Good bye, Bob! -----

> bob.ash

I am Bob. I want to name my dog 'Bella'.
- vardefaults['test_dogname'].val == 'Bella'
- vars['test_dogname'] == 'Bella'
- getvar('test_dogname') == 'Bella'
I called setvar('test_dogname', 'Bella')
- vardefaults['test_dogname'].val == 'Bella'
- vars['test_dogname'] == 'Bella'
- getvar('test_dogname') == 'Bella'
----- Good bye, Bob! -----

When bob.ash is executed for the first time, getvar('test_dogname') returns 'Ace' even after calling setvar('test_dogname', 'Bella'). But when bob.ash is executed again, getvar('test_dogname') returns 'Bella' as expected.

I discovered this while investigating a bug in Philter (formerly OCD-Cleanup, forked from OCD Inventory Control). Philter (and OCD Inventory Control) sets the default value of BaleOCD_DataFile to the current player's name:
Code: 
setvar('BaleOCD_DataFile', my_name());
setvar('BaleOCD_StockFile', my_name());
When you run OCD for player A, it sets the default value to 'A', meaning it would use OCDdata_A.txt. If you logged into another account B and executed OCD, the default value would be changed to 'B', but getvar() would still return 'A', causing OCD to purge B's inventory using OCDdata_A.txt.

What is causing this? I suspect that it has something to do with a static variables, since this behavior only occurs when bob.ash is executed for the first time in the current KoLmafia session.

Could this be looked into? I could avoid this behavior on Philter's side by not using my_name() as the default value, but I'm open to other ideas.
 
Last edited:
Perhaps related? I run a new script with character A. There are no defaults so zlib helpfully makes and records some guesses. I then run the same new script with character B. Character B gets the default value from character A and that happens to be wrong. I think the fundamental issue is that derived defaults are global but the settings only make sense per character.
 
Oh yeah, this is definitely happening due to the defaults map being a static variable. I hadn't imagined a case where the desired default value would be different per character.

For your case, is there a reason to make the filenames user-configurable? If not, I would recommend hardcoding them to Philter_data_<my_name>.txt, etc (like ZLib and BatBrain do, or Ezandora's scripts do, for example). That would at least bypass the issue. I suspect you have used those variables to maintain backwards compatibility with OCD, but as long as you include some transitional code to rename aberrant map files and preserve the data, I doubt users would notice/care.

On my side, I also need to stop that happening. I have recently acquired an effect (intrinsic): Dad, though, so my coding time is quite limited at the moment. It looks like I originally intended to remove the transitional code that is causing this issue (line 326), but I can't recall why I had to put it in there, and I fear that yoinking it may mess something else up.

EDIT: Okay, I recall what it was -- when I changed ZLib to separate defaults and specific user values, most scripts were accessing vars[] directly rather than using getvar(), for the very good reason that getvar() didn't yet exist. Anyone wanna grep their KoLmafia folder for "vars[" and see if they have any scripts still doing that? The only results I have are from ZLib and PrefrefPlus, so I'd be fine to remove that line.
 
Last edited:
I did as you asked and found "vars[" in quite a few scripts that I've accumulated over the years. Some of them are minor but EatDrink is not.
1622800725976.png
 
How many of those do you still use? Looks like several are not relevant anymore. Also, the current version of BatBrain does not contain any instances so it seems several of your scripts are also outdated.

Script authors have had since May 14, 2017 to do the search-and-replace I recommended here, so I'm starting to feel like perhaps it's time to make the transition complete. Four years of deprecation is enough before moving to obsolete right?
 
You must log in or register to reply here.
Back
Top