ZLib -- Zarqon's useful function library

installed this and now get the following error when trying to use FirstThingsFirst.ash

Code: 
Unknown variable 'threshold' (FirstThingsFirst.ash, line 77)
 
Have patience -- I'll have all the updated scripts up within a few hours, I should expect.

For an immediate quick fix, replace instances of "threshold" with:

to_int(vars["threshold"])
 
WOO! This rocks!

Suggestion: In the map file, include with each setting:
* the name of the script that initially set it
* the date it was originally set
* the name of the script that accessed it last
* the date it was last accessed.
That should go a long way towards the problem of "does anything use this setting any more, and if not, can I delete it".

Yippitee skippity!
 
As dj_d says. It would be nice to be able to tell at a glance "does anything use this setting any more, and if not, can I delete it".
 
If you aren't sure it's used by anything, just delete it. A script that uses that setting will just reset it to the default value next time it's run.

I have plans in the wings for some kind of online user-editable documentation, where script authors and users alike can add which scripts use which settings and what they do. Users will also be able to edit their settings online (where the documentation is) and fetch that edited map from the server. This release has taken my scripting energy for the nonce, so don't expect it in the immediate future.
 
Last edited:
If you aren't sure it's used by anything, just delete it. A script that uses that setting will just reset it to the default value next time it's run.

You dramatically underestimate the OCDfactor of your colleagues here. I am already concerned that, right this very minute, I MIGHT HAVE SOME EXTRA SETTINGS THAT I DON'T NEED. Or even worse, I might DELETE A SETTING THAT WAS OPTIMAL AND REVERT TO AN INFERIOR DEFAULT!!!

I hate to shout, but this is our collective sanity on the line. Or over the line.
 
That was actually one of my design considerations. I originally designed a record for settings that included the script using the setting. But I realized that several things about the implementation were better simpler, and decided to leave the calling script information out of it, and use the script prefix idea: callingscript_settingname.

I also knew that I could trust my fellow OCD script authors to keep the settings file organized by following the naming conventions I wrote about at length in the above post. :)
 
Sorry for what I'm sure has been a flurry of annoying popups lately. This (Build 4) should be the last of the semi-unnecessary ones! The new system seems fairly stable. Any further popups will be due to bugfixes or Super Awesome Things, both of which are quite necessary.
 
My $0.02: Better to have a setting with a clear parent that is also incidentally accessed by something else, than a setting with no clear parent. If a script attempts to set the default, it should claim it with a prefix; if others want to access it, that's OK. That way every setting has a connection to the script that set it, and you have a chance in hell to figure out what it's for.

So basically, I'd recommend doing away with "common settings" and give them all a prefix - the script which created the setting.

(that's what I'm doing for my scripts, anyway!)
 
What better place for common settings than among a library of common functions?

Otherwise, some of my script settings might include:

ocw_macguffin_checklist_randbot_routine_login_defaultoutfit
ocw_macguffin_checklist_randbot_friars_routine_logout_is_100_run

I guess I'm just saying (rather ridiculously) that the settings I included here (a mere 4) have already become rather global in my scripts, and I can't choose a script for them to belong to. But generally, I strongly echo your recommendation for the script-identifier-prefixing of settings.
 
Two things, first: is this intended behaviour?
Checking for updates (running bumcheekcity and hippoking's Rollover Management Script ver. 0.56)...
_version_bumcheekcityroll => 0.56
New version available: 0.55
Click to expand...

This was when I was testing a new version before actually putting it in the thread.

Second, would it be possible to have the "vars.txt" files stored elsewhere so they don't appear on your scripts menu? If you're running multiple characters, that menu gets cluttered up quickly.
 
1) Yes. ZLib does no parsing of whether a version number is higher or lower, only that the string matches. That means you can do versioning like Ubuntu if you want:

Rollover Management Script - Galumphing Giraffe

Or like KoL's resistances:

Best Between Battle Script SUPER VERY 200% BEST

2) Mafia automatically creates maps in the scripts directory (which makes no sense, since mafa can't execute maps), so there is no way to change their created location. However, after they are created you can move them to your data directory yourself, and then they will still work just fine, without cluttering your scripts directory.
 
I've never tried anything other than the data dir. If you try something else and it works, let us know! Mafia's directories are in different locations for different operating systems, so include your OS if you report back.
 
Well, it seems it only works in the data directory, and thats fine. I tried my own ScriptDataFiles dir where my maps are and also a subfolder in scripts, but neither worked; a new var_ file was created in the scripts folder.

I am using Windows XP and i like to zip up the scripts i use as well as the maps i created and email them to myself once a week, CYA you know, and the var_ files should be in that. But i don't need the larger general mafia data files zipped. I'll just copy them out before I create the zip file.

Thanks!
 
Last edited:
You can actually just delete all of mafia's data files. Mafia keeps its data files internally, and external files are only needed if you want to change something for your personal copy of mafia. After deleting those, you'll find that the data dir is quite tidy and small. All 37 files in my data dir are map files made or used by scripts. Only 5 of them are larger than 6K, and unless you're using EatDrink.ash, you probably won't have any larger than that.
 
Cool! i kept itemflags.txt with the memental, singleton and junk lists, but then it is quite small. Thanks for the info!
 
zarqon said:
1) Yes. ZLib does no parsing of whether a version number is higher or lower, only that the string matches. That means you can do versioning like Ubuntu if you want:

Rollover Management Script - Galumphing Giraffe

Or like KoL's resistances:

Best Between Battle Script SUPER VERY 200% BEST
Click to expand...

Or to use more sane examples, you can use versions like "alpha1.0 pre-release", or "beta 1.2"
 
You must log in or register to reply here.
Back
Top