ZLib -- Zarqon's useful function library

Since we're talking about mcd-ness... I've noticed that on a couple of unascended characters which I play occasionally, the mcd tries to adjust before every turn. (I guess this should really go in the BBB thread, since that's probably the culprit, but...) Of course, there is no possible mcd to adjust, which is why it is never at the "right" setting.

I haven't investigated what's going on too much, so it may not really be any of your scripts causing it, but since the mcd came up I thought I'd mention it.
 
If your problem is that it keeps printing "MCD: unavailable", then the culprit really is zlib. If there's no way to ever get an MCD, then it would be best not to keep reminding the player of that even though it doesn't cause a server hit. I'd suggest you open up zlib and find auto_mcd(). There will be a line that says...

Code: 
   if ( (!in_muscle_sign() && !in_moxie_sign() && !in_mysticality_sign()) ||
     (in_muscle_sign() && !retrieve_item(1,$item[detuned radio])) ||
     (in_moxie_sign() && available_amount($item[bitchin' meatcar]) == 0) &&
      !contains_text(get_property("unlockedLocations"),"South of the Border") &&
      !contains_text(get_property("unlockedLocations"),"Thugnderdome")   ) {
      return vprint("MCD: unavailable","olive",2);
   }
It will stop nagging you if you change that to:

Code: 
   if ( (!in_muscle_sign() && !in_moxie_sign() && !in_mysticality_sign()) ) return true;
   if ( (in_muscle_sign() && !retrieve_item(1,$item[detuned radio])) ||
     (in_moxie_sign() && available_amount($item[bitchin' meatcar]) == 0) &&
      !contains_text(get_property("unlockedLocations"),"South of the Border") &&
      !contains_text(get_property("unlockedLocations"),"Thugnderdome")   ) {
      return vprint("MCD: unavailable","olive",2);
   }
 
Or just change the verbosity level (either raise it in the script for that statement or lower your verbosity setting). I should probably bump that up a notch or two.
 
The message I get is:
Code: 
[COLOR="Olive"]MCD: adjusting to 10...[/COLOR]
Resetting mind control device...
Mind control device reset.

Except of course the mcd is not reset, because there isn't one, so this shows up before every adventure.

Possibly it has nothing to do with your scripts, Zarqon, as according to auto_mcd() I should just be getting the unavailable message. But betweenBattleScript is definitely BestBetweenBattle.ash, and automcd is true.

Code: 
> zlib vars

zlib automcd = true 
<cut stuff>

> prefref between

betweenBattleScript (user, now 'BestBetweenBattle.ash', default none)

> ash (!in_muscle_sign() && !in_moxie_sign() && !in_mysticality_sign())

Returned: true

What I'm seeing just doesn't seem possible. It may be best to just ignore me! (I thought I wasn't seeing this on my Bad Moon aftercore character, but it turns out she just didn't have BBB running. Now that it's running, I see the same bizzaro message.)

ZLib 15 and BBB 1.8. I follow the code from BBB into ZLib and should definitely be getting the "unavailable" message. This makes no sense!
 
Updates!

First, kmails no longer URL-encode the messages. This has been broken since revision 8127 but I avoided posting an update until I had more things to update.

The "more things to update" is all MCD goodness.

  • It will now skip MCD-ing for locations with no known combats, in addition to the MCD-sensitive areas (mainly boss zones) it previously skipped.
  • Those location-sensitive checks have been moved to the auto_mcd(location) function, since it actually didn't make sense for them to be in auto_mcd(int safemox).
  • If you are not in a sign (unascended), or have turned automcd off, it will silently exit the function without doing anything. (I hope -- still perplexed by the report above.)
  • Bumped the verbosity up a notch for MCD messages. Two notches for the "unavailable" message.
 
Looks nice. I hadn't even realize that url-encoding on kmailing was no longer necessary. That is what was responsible for an error that suddenly cropped up in one of my scripts. Finally I've got that sorted out!
 
I am happy to report that my Mysterious Output (tm) has gone away. I too remain perplexed by it ever being there in the first place.

In other news, setting verbosity at 10 gives some really interesting messages. Apparently these monsters aren't my huckleberries because they aren't gremlins, but why would a gremlin with the correct tool be referred to as a huckleberry? Truly, SmartStasis, you confound me.
 
check_version - How To Questions

I am trying to understand how to use check_version. I get the basic idea that I have to have a thread on Kolmafia.us that has the current version of the script. I understand that the first post in the thread has to contain some strings that identify versions and that check_version determines whether the version referenced in the post and the version being run are the same by doing string comparisons. However, I am at a loss to understand how to match the parameters in my call to check_version to my (as yet unposted) version page.
void check_version(string soft, string prop, string thisver, int thread)
Server-friendly once-daily version-checking. (Also hyphen-friendly.) If the user hasn't checked yet today, visits the specified thread in this forum to find the current version of your script. Your post must include "<b>soft version</b>" for the version info to be successfully parsed. If a new version is available, alerts the user in large text and provides an update link, then waits for a sufficiently annoying interval in case the user wishes to abort operation to go update the script. The current version is stored to a daily property, standardized to "_version_"+prop.
Click to expand...
Working backwards, the parameter thread is an integer that I can determine by creating my thread and then looking at the URL for it. I believe, although I am guessing, that thisver a string that identifies the version. It could be anything ranging from "1" to "untested-alpha 0.00". Whatever the string is, if there is an exact match with an appropriate string in the post, then the versions will be deemed the same. How do I indicate the version in the post? I infer that it has something to do with text rendered in bold and after the string "soft " but I am not at all certain and certainly not interested in spamming the forum with a test post until I get it right. I have no idea what the parameters soft and prop should be and how their values relate to the post page. When I look for examples they often are the name of the script but with capitalization differences. Where do these parameters occur in the post? When are things case sensitive? Is there any relationship between either of these and the name of the attached file containing the latest version?

Does the file name truncation reported by Bale in the discussion of his UR script have any effect on check_version?

Thank you.
 
I call it thus, for SmashLib:
Code: 
check_version("SmashLib", "smashlib", "1.2", 3065);

This indicates that somewhere in the first post of thread 3065 (http://kolmafia.us/showthread.php?3065), the text <b>SmashLib 1.2</b> appears -- "SmashLib" is the name of my software (hence "soft", I think), and 1.2 is the version. This version is then stored in a daily Mafia property called _version_smashlib.

Of course, in your actual post you don't use the html for the <b> </b> -- use the BBCode equivalents, which the board will translate into the html that check_version() sees.

So: write your call to check_version() with a bogus number, comment it out until you make your post, substitute in the correct thread number, then attach your script now that you know the correct number.

Edit: check_version() doesn't check the actual file, so the truncation Bale mentions won't affect it.
 
Last edited:
Very helpful. Thank you.

Why are the first and second parameters different then, or even needed? Is there case (in)sensitivity at play? What is the reason for/benefit of a daily Mafia property called _version_smashlib as opposed to one called _version_SmashLib?

If my script is DCChecker and I am also running SmashLib, that check_version("DCChecker","smashlib","1.0",9999) would be a Very Bad Idea because both scripts would be using the same daily Mafia property?

I see now that the "soft" in <b>soft version</b> is intended to be the same string as the first parameter which somehow escaped me before.

I infer, since check_version does not actually update files, that there is no relationship between any of the parameters and the name of the attached file?

Thanks again.
 
Somewhere in your thread on this forum, you need a line that goes <b>soft version</b>: that is, the first part is the software name as supplied to the function, then a space, then the version as a string (if you include "v" etc. in the post, you must also pass your version with this to the function). The parameter "prop" is used for the name of the property saved to your user prefs file. Note that if your post (or really, any front-page follow up) includes the same bolded version string, only the first appearance should be checked against.

For example, let's say your post had:
My Software v1.1

When you run check_version(), you would call as such: check_version("My Software", "mysoft", "v1.0", 9876).
This assumes a post number of 9876 for your script's thread, and will result in a property "_version_mysfot" being set to "v1.1" (which is cleared each day by mafia itself, and how the script knows whether it should check each time it's run; if the property exists, it can quit since it's already checked once today). This example also assumes that your user is running an older version of the script than what your post has been updated to report.

Edit: Ninjas everywhere, geez!
Edit2: It's possible that you may want to use a much shorter, or differentiated-by-user or something property. There's really no compelling reason to have "soft" & "prop" be different in most cases, but it's there just in case. You're also correct about the lack of relation between the function parameters & the files as they exist attached to your post.
 
Last edited:
It appears the function has been well-explained by my trusty colleagues.

There is a good reason for prop and soft to be different, however. One reason for the difference in the first two parameters is to maintain naming standards for mafia preferences. Another reason is scripts with spaces or strange characters in their names. You could name your script "--== Inigo's Auto-Caster (TM) ==--", but using "_version_--== Inigo's Auto-Caster (TM) ==--" as a property name is quite distasteful. (I actually shuddered while typing it.)

Just realized -- with the new forum software, this may require an update to ZLib. Although so far it appears that old links get redirected.
 
Last edited:
zarqon said:
It appears the function has been well-explained by my trusty colleagues.
Click to expand...
It has and I thank them. You too.
zarqon said:
One reason for the difference in the first two parameters is to maintain naming standards for mafia preferences.
Click to expand...
Are these standards and preferences something I should know about or that could be/should be/are documented somewhere? ;)
Thanks.
 
He hasn't bothered to explain, because it is all over the prefs file. The standard he refers to is to start with a lowercase letter, then use camel casing instead of underscores at the start of a new word. For instance: theStandardLooksLikeThis


zarqon said:
The funny thing about that is that all the auto-MCD logic is now in ZLib. Ha.
Click to expand...

I do find that quite amusing from time-to-time. That's what you get for not being willing to change a project name after it has been completely overwhelmed by feature creep.
 
Last edited:
Bale said:
He hasn't bothered to explain, because it is all over the prefs file.
Click to expand...
First, I freely admit to being deliberately dense, in the hope that someone else might have the same question and find it answered because I asked. I also admit that I am asking questions rather than just looking at code and files. I can do that but as long as I am not annoying people it is easier to ask than engage in software archaeology. That said, if I am being an a$$, just PM me and I'll try and adjust. I am an adult ;)

When reading back, the first thing that comes to mind is that I am perhaps too much of a literalist. The specific item that started the discussion was a property that used a naming convention starting with underscores, as in _version_smashlib. So I would ask, is this a mafia property, a mafia property that is used exclusively by ash or a zlib feature? Since these properties are persistent, how is that provided? A file on the user's local file system? A file managed by zarqon's Map Manager or something else?

Since I'm being anal about using nouns consistently, how do the above properties compare to preferences which I would say are files maintained by mafia, persisted in the settings subdirectory, have names like GLOBAL_prefs.txt and UserName_prefs.txt and have property names names that begin with a lowercase letter and use camelcase conventions. Is it even appropriate for me to try and make a distinction?

In general, if there is a convention out there it would be in my best interests to follow it but it does make a difference whether the convention applies to zlib maintainers, zlib users, ash users, mafia users and/or mafia developers. Hence my questions designed to determine what the convention is and when it should be applied.

Thank you for your patience.
 
I am also anal about nouns. I try to always refer to mafia's per-character variables as "properties" or "preferences" (they are synonymous in practice), and ZLib's variables as "script settings."

In the case of this function, it sets (and reads) a mafia daily property. These are accessible (and in this caes, created) via CLI's "set"/"get" and ASH's set_property()/get_property(), and live in your settings directory, as opposed to ZLib script settings, which are created by ZLib-empowered ASH scripts at runtime, and live in your data directory in your vars_myname.txt file.

If in doubt, things are established enough now that you can simply look in the appropriate place and follow the apparent convention.
 
You must log in or register to reply here.
Back
Top