ZLib -- Zarqon's useful function library

I'd support something like expanding how the vars map is stored, but leaving vars[] alone (to avoid forcing scripts to update), if possible. The expanded datafile would presumably have the datatype and default value, and so the following would presumably work:
Code: 
if (vars["myVar"].to_type().to_string() != vars["myVar"])
   vars["myVar"] = varsMap["myVar"].default;
Basically, varsMap would be
Code: 
record {
   string val;
   string type;
   string default;
} [string] varsMap = map_to_file("vars_"+my_name()+".txt");

The one thing I'm kinda iffy about is that you'd have to iterate over all the elements of varsMap[] to generate vars[].

I'd totally add support for this in relay_zlib.ash, by the way. You'd need a few special types, though, like monsterList for stuff like ftf_olfact. There'd also be issues of "how do we update the current datafile? Assume type is string?" and "well, how will setvar() work now? New overloaded form?". Presumably setvar() would need to be modded to add the info into the map as needed. Overall kinda hacky, but possibly worth it in the long run?
 
I've already edited ZLib locally. All vars are normalized to their correct type whenever a script uses them. It's fairly sexy.
 
The beginning of that framework has been in zlib forever. It's about time you did something with it.

zarqon said:
I've already edited ZLib locally. All vars are normalized to their correct type whenever a script uses them. It's fairly sexy.
Click to expand...

It turns me on when you say a thing like that! You're making me want to see it. You're such a tease!
 
Figured I should move random zlib talks here as opposed to threadjacking. :) So yep, one possibly useful, possibly confusing thing is that if you start a gCLI window before you login and launch zlib or a script that employs it, you'll end up with a "vars_.txt" file without a name attached to it, used only in those same circumstances. Possibly useful in terms of lazy sandboxing or the like.

Another pondering, though this is one that would affect more things... would it make sense to move general zlib variables under the zlib heading... so verbosity would be zlib_verbosity instead, is_100_run would be zlib_is_100_run, etc. Negative: Breaks scripts that directly call old values. Positive: Segments off the zlib bits, makes vars_<name> less confusing when parsing; if someone's old script is the problem with verbosity, it shouldn't affect new/current installations, since it's running off zlib_verbosity instead.
 
Theraze said:
So yep, one possibly useful, possibly confusing thing is that if you start a gCLI window before you login and launch zlib or a script that employs it, you'll end up with a "vars_.txt" file without a name attached to it, used only in those same circumstances. Possibly useful in terms of lazy sandboxing or the like.
Click to expand...

I find that very useful when running a script to automate multiple characters, just in case I have to abort and then later restart it. When a character is done, I set vars["character name"] = true! I have all my no character settings in "vars_.txt".
 
Just a heads-up: this is next on the update list. I've made a handful of changes lately and it's about time for another update, particularly given the usefulness of settings normalization.

Still to do:

1) Make has_goal() account for combat rate modifiers.
2) Make check_version() more relay-friendly. Add an option for authors to specify required mafia version, which would inform users of requirements before they update scripts that would also require mafia updates. (I finally got what you meant, Doodle.)

Originally, I hoped to make a has_item() derivation of has_goal(), which would be very useful for calculating how many adventures it would take to get an item (or its ingredients) without needing to make it a goal. But that's too far away for this update, I think.

It's not a lot to do, but considering that it's been weeks since I had a free hour at home when I didn't desperately want to sleep, it might not be happening today. :)
 
OK, so I updated CanAdv tonight rather than ZLib -- prompted by an error due to the new Tavern. But that doesn't really count, so ZLib is still next.

@Doodle: haha!
 
Guys, exciting news!

1) I am close to having a working prototype of the WOSSMAN. It's a relay script that uses AJAX to ping itself! And using the soon-to-be-available ZLib function normalized(), settings are normalized when edited! I just have a feature to add (verifying submissions against your pwd hash) and a confusing bug to fix (fetching JSON-encoded arrays of mafia's datatype constants isn't working for items or monsters and maybe others... possibly due to odd characters? *beard scratching*) and I'll be ready for release.
2) jQuery is friggin' awesome. I'm including it along with this script, and I suspect future relay scripts may also want to take advantage of it. Seriously. Frig.
 
Ehh...I dunno. How are you going to include jQuery? Also, since KoL already uses jQuery, couldn't you be able to fetch it? Also also, isn't jQuery code terribly difficult to read for those who are new to it?
 
KoL uses jQuery? News to me, as it is not among the .js files in the relay folder. It's also possible to fetch jQuery using the Google API link, but I just dropped the minified version into the relay folder in the interest of loading speed. Likewise the excellent jeditable plugin.

Code readability isn't too much of an issue here, as users will not need to read jQuery code, only use the very svelte webpage (that only needs to load once, w00t). I just started learning it over the last four days as I was looking for AJAX solutions to the ZLib settings editor, and I didn't find it that difficult. The documentation is quite helpful, and beyond that the working examples that are easy to Google up help tremendously. But to be fair, it helped that I was already familiar with HTML, CSS, and object-oriented programming.
 
Yeah...I first stumbled across jQuery (or so I believe) code in KoL while looking at theJavaScript for handling chat messages. Currently, it can be found in /images/scripts/jquery-1.3.1.min.js. I wonder whether it would be wise to rely on that path, since it could be changed without any warning. Perhaps making a function called insert_jquery() for handling generic jQuery loading in relay scripts would work.

PHP: 
void insert_jquery() //use KoL's jQuery
{
	writeln('<script type="text/javascript" src="/images/scripts/jquery-1.3.1.min.js"></script>');
}

Also, using KoL's jQuery may prevent you from using more recent features and plugins, so using Google API's jQuery may be preferable.
 
Last edited:
I'm pretty sure I'm using some bits that wouldn't work using that older version of jQuery. Since it's small, and since I'm also including another plugin, I think I'll just stick with releasing all three files as a zip package to be unzipped in the relay folder. I'm including the CSS in the ASH file.

Which makes me think about requesting a [CDATA[ ]] equivalent for ASH. :)
 
r21 Updates!

Three major things.

  • ZLib settings are now normalized to the correct type when a script calls setvar(). There is also a new ZLib function normalized(string mixvar, string type) available for normalizing strings to a specified type.
  • has_goal(location) accounts for combat frequency modifiers.
  • check_version() now returns a string, rather than void. The string will be empty unless an update is found, in which case it will return a div with an id of versioninfo, for easy CSS styling. Now check_version is usable by relay scripts! Authors can also now optionally specify a minimum build of mafia in the thread, using the syntax "[requires revison XXXX]". The update notification will now inform you if you also need to update mafia to use the new update. Untested.

And a few other tweaks too small to mention. Enjoy!!
 
More Exciting ZLib-Related News!

I've been slaving away at the WOSSMAN for the last week or so, and I'm finally ready for beta testers and feedback.

Implemented:

  • Edit-in-place ZLib settings. I think I may be the first person to use AJAX to talk to ASH. :)
  • Each setting has popout documentation on mouseover, with a checkbox to expand all.
  • Filter box at the top shows/hides settings as you type. Friggin' A.
  • Delete settings (with confirm).
  • All submissions are checked against your password hash (so you don't accidentally change a setting for the wrong character).
  • Settings are normalized on edit.
  • Edit-in-place documentation in the same data format we agreed upon for FN Ninja's ZLib Settings Manager, and even using the same filename. I hope it may save some people the time they already invested writing documentation.

Not yet implemented:

  • Functionality to update documentation directly on the Map Manager, not only on the local copy.
  • ZLib's setvar() should add the setting to the documentation map and set the type when initializing a new setting.
  • Scripts should be able to link to their threads, somehow.
  • Masks for string variables, for normalizing more complex settings. If possible values for a setting are "lion", "tiger", and "bar", I want someone to be able to specify that those are the only valid values. I also want someone to be able to specify something like "familiar" in the mask to mean a string matching any familiar. I'd also like it to work with comma-delimited lists of things. We'll see.

Please help with 3 things:

  1. Does it work in your browser? Does anything look horribly weird?
  2. The dropdowns for some of mafia's datatypes (for example items and monsters) don't load right. Whyyyyyyyyy???? ARGH
  3. I'm a complete novice to jQuery, and I'm kind of a hack at CSS too -- if you see anything I could have done more efficiently, I would appreciate knowing. I feel that the craziness with the selectors in the filter.keyup event could be streamlined somehow.

I would also like to hear your opinions on 2 more things:

  1. When it comes time to release this, should I integrate it into the ZLib thread or make a separate thread for it? I imagine that having them both in one place for easy downloading (a la Bale's UR) would be nice, but I also like the idea of having a separate place to discuss the WOSSMAN vs. ZLib. Give me opinions and considerations and arguments in favor and against!
  2. Right now, when populating the select boxes I'm filtering familiars down to the ones you have (idea stolen from FN Ninja). Are there any familiar-type settings where you may want to specify a familiar you don't have? This is easy to edit later if such a setting comes into being, but if there isn't presently one I'd like to filter them for ease of use.

Also attention, script authors using ZLib settings! You may consider this advance notice to start adding documentation for the settings your script uses. This beta script will work fine for that. Currently the script does not update the map at all, but rather your local copy of vars_documentation.txt. So after running the script once to get the current map, you may update all documentation using this script and then add your changes by uploading vars_documentation.txt to the Map Manager. Your contributions to making your scripts easy to configure will be appreciated by your users, I'm sure. Or in the case of some, the users will be the ones contributing, ha.

Installation: just unzip this file in your relay directory. It contains relay_WOSSMAN.ash, jQuery 1.4.3 minified, and the jeditable plugin.
 

Attachments

At this moment my most serious thought about the WOSSMAN is simply, "Holy Fuck!"

I noticed the cute easter egg when you click on the words, "Wikified Online Script Settings MANager". Very nice.

First criticism: As nice as the mouse-over effect may be, it makes for an awkward UI experience for me. I'd find it easier if I had to click on the variable's name in order to open up the description information.

Second criticism: The expand check-box has buggy results for me where there's a long delay while the output jerks around, eventually clicking on it will make it stabilize. Particularly when I'm also using the filter.
 
Last edited:
1) Looks beautiful in general.
2) The part that says "Showing 176 settings" isn't visible for me unless I double-click to have it selected. It's in a weird spot RIGHT on the line between the top dark and the white.
3) Agreed on mouseover, it does make it rather difficult to actually get to where you want to be. If you move fast enough as well so that it's trying to open based on where you were a second ago, and you've moved on before it loaded, and don't move after it finishes... you can be hovering on something and never have it realize it.
4) It doesn't seem to believe that Rinn's autoBasement is a real script. None of those variables are considered 'used'. Same goes for dj_d's eatdrink. And levelup.
5) While is_100_run is detected as a familiar, the various familiar bits for Wossname aren't known to be a familiar, they're still listed as being of "string" type.
 
Thank you both for your feedback.

Bale 1 and Theraze 3 re: mouseover. I have only found it annoying when actually trying to edit settings. If I move the mouse, I could hide the form I was editing. I forgot to mention that I'm planning to disable the entire documentation sliding process when you're editing any form element -- as soon as I figure out how to do it. In the meantime, I'll try the click method and see if it's worth the extra effort of clicking. It's easy enough to change -- on line 121 change "mouseover" to "click".

Bale 2: jerky results? Are you running a machine without much video memory? How many settings do you have? I'm pretty sure we both use Opera, and my results are very aesthetically pleasing -- expand halts for a little bit before expanding if all settings are showing but otherwise runs quite smoothly.

Theraze 2: What browser are you using? I have only tested it in Opera, and I don't care if it looks horrible in IE <= 6, but otherwise I'd like it to look OK in all browsers. This is probably a CSS issue. I'm not so good at CSS so I approach this issue with trepidation.

Theraze 4: It doesn't list them because no one has added documentation for them. I don't even have most of those in my vars file (I show exactly 100 fewer settings than you). So, have at it! (Perhaps you didn't notice that you can actually edit everything except the actual setting names using this script.) This is what puts the 'W' in WOSSMAN. And if you add something wrong, I'm sure someone else (ideally a script author who created/uses that setting) will fix it.

Theraze 5: Methinks you did not read the documentation for the ocw_f_xxxx settings -- they are strings because they also accept things like "items", "meat", "stats", etc. This is one example of why I want to be able to use more involved masks for normalizing values. Please, no one set the type on these to "familiar".
 
Re 2: In the case of my relay browser, IE8-64bit. It reduces the chance of anything else causing interference.

Re 4: Interesting. Does vars_documentation get prepopulated from somewhere, or have I just been ignoring the fact that I've been pressing an extra tab to pass it when I'm manually editing my settings files? If it's a prepopulated file, is it getting downloaded from the site or is it generating off the files themselves? Just wondering what's the best way to make things more 'normal' overall. :)

Re 5: I read through all that stuff... but back when I was first configuring. Then I decided to do BM and BC runs, and jumped from the specific settings to is_100_run, and they became (as long as 100 is set) irrelevant (and actually all set to none). :D So I've forgotten all about them, except that the 'f' stands for familiar. I suppose someday I should really stop just setting 100 runs, but it's just so much easier... :D
 
You must log in or register to reply here.
Back
Top