Zlib Variable Manager

That FN Ninja

That FN Ninja

Member
Zlib Variable Manager v0.3
KoLmafia Preference Manager v0.3

A variable manager for Zarqon's zlib.ash function library.

vman new.PNGvman new2.PNG

A property manager for all your KoLmafia properties.

prefman descs1.PNG

These require Jason Harper's htmlform.ash

Remember: htmlform.ash goes in your scripts directory and relay_zlib_manager.ash & relay_pref_manager.ash go in your relay folder like the names suggest.

Cross Compatibility Concerns Conquered! Cool.
Browsers tested: IE, Firefox, Opera, and Chrome approved. I think it's interesting to note that these run significantly slower in Firefox.

Thanks to:
Zarqon for zlib and all the other resources he's contributed to the KoLmafia scripting community.
Jason Harper for htmlform.ash
Heeheehee for his original zlib variable editor which was used as a starting point for these.

Change log:
07.11.10 - Removed sections and implemented a filter button instead
07.12.10 - Fixed Browser cross-compatibility issues.
02.25.11 - PrefMan v0.3 update. Added version tracking. Now parses the descriptions of the variables from the KoLmafia wiki.
02.26.11 - PrefMan: added workaround for customCombatScript property. Thanks Theraze.
 

Attachments

Last edited:
One thing I wanted to gets some opinions on is the format for the file containing the descriptions of the zlib variables. After the format is decided a file will be uploaded to Zarqon's Map Manager and the information will be loaded from there. In the third picture you can see an example of what I'm talking about.

The script currently just uses a simple string[string] map where the name of the variable is the key and the description is the value. What do you all think? Should more information be included? Like the name of the script that uses the variable? A record format could be followed where the name of each script that uses zlib vars could be the record which in turn contains a map of it's corresponding zlib vars and their descriptions. Also, what would be a good name for the file? Let me know what you guys think. Z, it's your call in the end.

Please remember Zarqon's variable naming suggestions when naming your script variables. The script is currently set up, so that if a variable ever changes, or is no longer used, it will not be displayed when using the Variable Manager. Once the description map is implemented, you can place "_obsolete_" anywhere in the no longer used variable's description and it will not be displayed and the first time the user successfully saves changes with the variable manager it will get deleted.
 
Last edited:
Neat! [Also, because it's the trend to build off of my crude framework that I kinda just tossed together, eh?]

Also, I think lines 26-27
PHP: 
file_to_map("vars_descriptions.txt", desc);
//load_current_map("zlib_var_descriptions", desc);
should have the comments switched. I mean, I don't have those map files yet.
 
That FN Ninja said:
Like the name of the script that uses the variable?
Click to expand...

That would be a good thing. It's quite possible to not know the script responsible for some variables. It'd be good if the name was made a link to the script's thread, opening in a new window when clicked.
 
The toggle() java function works, but you need to use check_visibility() when creating the kolbox so that the settings in the cookies are used when a new instance of the script is created.
 
slyz said:
The toggle() java function works, but you need to use check_visibility() when creating the kolbox so that the settings in the cookies are used when a new instance of the script is created.
Click to expand...

Of course, thanks for the info. Fixed locally.

heeheehee said:
I don't have those map files yet.
Click to expand...

The map file doesn't exist yet, that is what I'm trying to get feedback on. After the format is decided and the text file is uploaded to Z's map manager, I will adjust the script accordingly and uncomment the load_current_map function call. The responsibility for variable documentation will primarily rest with the respective script authors.

Bale said:
That would be a good thing. It's quite possible to not know the script responsible for some variables. It'd be good if the name was made a link to the script's thread, opening in a new window when clicked.
Click to expand...

Noted and thanks for the feedback. With that in mind, how does everyone feel about the following format?

Code: 
record{
    string thread;
    string[string] variables; 
}[string] var_scripts;
and the resultant text file would then look something like this:

Code: 
zlib.ash    thread    2072
zlib.ash    variables    verbosity    variable description goes here
zlib.ash    variables    threshold    variable description goes here
So the name of each script that uses zlib vars would be the key to a map of records. Each record will contain the script's thread number and a map of it's zlib vars keyed by variable name and the value would be the variable's description.

Also, about the name of the text file. How does vars_documentation.txt sound?
 
vars_documentation.txt sounds good.

A map indexed by script seems a bit awkward, especially with what I can imagine is the current system -- how would you know that a certain variable's in the documentation, especially if the naming is inconsistent?

Although, fine, I guess it could pull the variables from one script at a time, in the order that they're listed on vars_doc. Perhaps a category would have to be made for Unlisted Variables?
 
Well well well, this is interesting. And very cool!

Allow me to immediately suggest that scriptnames as keys is a bad idea, since scripts share variables.

Since others seem more willing to work on this than I do ;), let me share the ZLib Settings Editor (WOSSMAN) data format which I'd planned on using:

PHP: 
record {
   string type;    // setting type
   string doc;     // documentation
   string scripts; // comma-delimited list of scripts that reference the given variable
};

The map would be indexed by setting name.

type: Type would be set by ZLib when initiating a new variable (this is the original reason why there is a setvar() for every type rather than just strings), and would not be adjustable from the relay script. It would be used by the relay script to determine the appropriate form input -- further, dropdowns for mafia's typed constants would be prepopulated with all known items/monsters/etc, with a Java toggle to sort by number vs. name.

doc: The relay script would have a form (ideally, a little [edit] link under the shown documentation which changes it into a form) for editing documentation for each variable. This form (ideally AJAX) would submit data to a PHP script on my server which will make the appropriate change to the map file on the Map Manager (this ensures that people editing the map at the same time don't overwrite each other's changes).

scripts: Editing this would be part of the same form that toggles with documentation, and would submit data to the same PHP script.

If someone (FN Ninj?) has the time to put this together (I have to do a lot of searching to write anything in JavaScript) I'll be happy to make the server-side script, since that part at least is easy.

I have a few other items after looking at the screenshots.

1) I'm not sure I like the visibility-toggled sections, since the properties are mostly already named with proper prefixes (only a few of the earliest settings appear not to be). To me it seems more cluttered than just showing everything in a sortable table, and it's bound to get worse as more settings are added. Perhaps someone awesome at Javascript could make it so that if you click a scriptname in the list of scripts, it will (toggle-ably) cull the table down to just the settings referenced by that script, but that's probably a ways down the road.
2) Stab bats image. Awesome, and thank you.
3) Which script uses adv_value? There is a mafia property "valueOfAdventure" which should be used instead.

So, rather than wowing you with my amazing implementation of my plan, I guess I will simply mention my plan in those hopes that we can make something wow-worthy out of it together.

Also, I don't want my comments to detract from the awesomeness of this particular implementation -- which is already better than my plan by virtue of its working right now. I think it's more than a few steps in the right direction. Awesome work, heeheehee and FN Ninja.

EDIT: Oops, setting name is the key.
 
Last edited:
Yeah, uh, I don't think <div> tags support value as an attribute. The way I got around that in one of my scripts (a clan log override, not important) was setting standardized ids for all the tags, like, say, prefixing the ids of section divs with "sec" -- doesn't matter what, just as long as it's something that you wouldn't normally see in another div. Like "shdf"!
 
zarqon said:
PHP: 
record {
   string type;    // setting type
   string doc;     // documentation
   string scripts; // comma-delimited list of scripts that reference the given variable
};
The map would be indexed by setting name.
Click to expand...

Okay, that's the format for the file then.

zarqon said:
doc: The relay script would have a form (ideally, a little [edit] link under the shown documentation which changes it into a form) for editing documentation for each variable. This form (ideally AJAX) would submit data to a PHP script on my server which will make the appropriate change to the map file on the Map Manager (this ensures that people editing the map at the same time don't overwrite each other's changes).

scripts: Editing this would be part of the same form that toggles with documentation, and would submit data to the same PHP script.

If someone (FN Ninj?) has the time to put this together (I have to do a lot of searching to write anything in JavaScript) I'll be happy to make the server-side script, since that part at least is easy.
Click to expand...
I'll see what I can come up with. This is the first HTML/Javscript I've messed around with, but with a little trial and error, I'm sure it will get there eventually. I'll let you know when I get to a point of testing that will require a php script on your side.

zarqon said:
1) I'm not sure I like the visibility-toggled sections, since the properties are mostly already named with proper prefixes (only a few of the earliest settings appear not to be). To me it seems more cluttered than just showing everything in a sortable table, and it's bound to get worse as more settings are added. Perhaps someone awesome at Javascript could make it so that if you click a scriptname in the list of scripts, it will (toggle-ably) cull the table down to just the settings referenced by that script, but that's probably a ways down the road.
Click to expand...

I have a few ideas on a sort of filter/search box. We'll see how that goes.

zarqon said:
2) Stab bats image. Awesome, and thank you.
Click to expand...
It's a mediocre tribute at best, but it does link to your Bat King page. Glad you like it.

zarqon said:
3) Which script uses adv_value? There is a mafia property "valueOfAdventure" which should be used instead.
Click to expand...
My Trafa.ash script used the zlib variable adv_value before the mafia "valueOfAdventure" property was implemented. Trafa.ash has since been updated to use the mafia property, I just havn't taken the time to delete it from my vars.txt That's why the current implementation of variable manager is set up to parse the description of the variables for an "_obsolete_" string. Once the documentation is implemented fully those sorts of variables will be weeded out of the vars files automatically.

Bale said:
Using Opera, the "Expand/Collapse All Sections" button does not work.
Click to expand...
heeheehee said:
Yeah, uh, I don't think <div> tags support value as an attribute.
Click to expand...

Yeah, I was kind of wondering if that was valid when I set it up that way. I didn't bother to check it out in other browsers. Lesson learned. I'll change that.
 
Late to the party as usual. I really like this but hope that it will work for super secret scripts that are not published yet, but do use zLib. I would not want map files hosted and disseminated to contain variables for scripts I did not use or for scripts that only I use.
 
@frono: Using this system the map file would contain all settings with existing documentation -- out of consideration for my server. I could not condone a system that has a server hit per setting. However, users would only see the settings that actually exist in their vars file. And for people that poke around and look at the actual map, seeing the settings that various script authors are using/creating may be inspiring to other script authors -- and/or may encourage users to try out other scripts.

But if you want to keep your settings private, just don't create any documentation for them. Ideally, settings won't exist in the documentation map unless they actually have documentation. Unfortunately, this means that the input forms for secret settings will just be text boxes, since type information is part of the documentation map.

We could put together something more complicated that submits your actual vars file, then my server parses the file and returns the current documentation map for only the settings in your vars file, but that makes version checking quite a bit hairier -- the server-side data file would need to include a timestamp for each bit of data. I'd rather not do that.

@FN Ninj: In light of the above, since the type field will be populated by ZLib and not this script, when making form inputs, if type is empty, treat it as "string". Also avoid adding any default documentation to settings that have no documentation. Leave them blank. A default message could be added to the page, like "click here to write a description of this setting", but that should not be added to the data file.
 
Last edited:
I was being tongue in cheek when I referred to super secret scripts but I am concerned about clutter and obsolescence. I may be far afield from what is being proposed and discussed, but what I would like is:
  • A standard way for scripts to handle persistence.
  • A friendlier way than the gCLI or a text editor to change such variables.
  • Annotation for variables, when available, to include "where used".
The first is zLib. The second is something like the variable editor under discussion. I would propose a convention whereby the script author wrote annotation and provided a file with the script. The existing mechanisms to manage universal data files on a remote server could be extended to annotation files.

People would only have annotation for variables if they had an annotation file - written by them or by the script author.

I would want some automated way to generate the variables to be edited. Reading the vars file handles that. I can also see something like grep being used on the ash files in the scripts directory or zLib itself just writing a record that indicated a script had "used" a variable.
 
Update v0.2

Removed sections and implemented a filter button instead. Let me know what you guys think.
Also added an alpha release of a KoLmafia preference manager based on the same sort of implementation.

Note: These only work nicely in Internet Explorer for the time being. Firefox doesn't like how I've set them up. Cross-browser comparability is giving me a headache.
 
Last edited:
Update v0.3

Fixed browser compatibility issues. Now works with IE, Firefox, Opera, and Chrome. :)

Bale said:
Darn. This program lost my contribution. :( Less cool. Works though. I'll stick with my rendition for now.
Click to expand...
Sorry Bale. I could upload the old section version as well if you'd like. However, the filter option is a lot nicer, especially as more and more variables are introduced. Take the pref_manager for instance, the filter is a lot more convenient than a plethora of sections. It works better for scripts that only have one or two settings as well. If it's any condolence, I do have plans to add a filter by script name option after I get the documentation portion fully functional. At any rate, I'm still grateful for your matcher that I used in the initial release.

Also, your version doesn't seem to work in IE, but I guess that doesn't matter because I think Opera is much nicer than IE. I'm going to start using it as my default browser. I installed it just to check compatibility and I must say, I'm a big fan!
 
Actually, I'd appreciate it if you would upload the old section version so that I can check something in the code. When I downloaded the new version I wasn't expecting it to be so different.

I'm happy you're enjoying Opera. It's a pretty sweet browser. I particularly love synchronize, so that I can use my bookmarks and notes wherever I go.
 
You must log in or register to reply here.
Back
Top