SmartStasis -- a complex script for a simple CCS

Oops, extra 't' at the end.

Updated batfactors. Thanks for your vigilance, all. Let me know if there are any further errors.

Which there will be. I'm improving BatBrain just about daily.

Next mini-project: accounting for Bander skill augmentation! Whee!
 
I am using latest build of mafia, SmartishStasis, and batfactors. My CCS is:

Code:
[ default ]
special action
consult SmartishStasis.ash
attack with weapon

I consistently get Evaluator syntax errors of this sort:
Code:
[957] Haunted Library
Encounter: bookbat
Round 0: y0u wins initiative!
Evaluator syntax error: can't understand myhp)
Evaluator syntax error: expected ), found
Round 1: y0u casts SAUCY SALVE!
KoLmafia thinks it is round 2 but KoL thinks it is round 1
You gain 10 hit points
Evaluator syntax error: can't understand myhp)
Evaluator syntax error: expected ), found

[...skipping some rounds]

Round 6: y0u casts SAUCY SALVE!
KoLmafia thinks it is round 7 but KoL thinks it is round 4
You gain 15 hit points
Round 7: bookbat takes 24 damage.
You gain 24 Mana Points
Round 7: bookbat takes 31 damage.
Round 7: y0u wins the fight!
You acquire an item: tattered scrap of paper
You acquire an item: Game Grid token
You gain 4 Strengthliness
You gain 6 Mysteriousness
You gain 6 Sarcasm
Evaluator syntax error: can't understand myhp)
Evaluator syntax error: expected ), found
Evaluator syntax error: can't understand myhp)
Evaluator syntax error: expected ), found

When I switch back to SmartStasis, those go away. Curious that some of them occur after the combat ends. Any ideas?
 
Yep, this happens because sometimes when editing the data file I add variables, but then forget to set them in BatBrain. Basically, whenever you see this error it means a formula evaluates to 0 -- which it probably shouldn't, but it probably won't harm anything.

More BatBrain updates!

These updates are mainly along the lines of moving more stuff into the data file, which is possible with the new universal format. I'd like to have all the equipment/effects/items/familiar/etc info in the data file, so that new game content can be added easily without requiring updates to the script. At present, that's kind of irrelevant, since I'm spinning BatBrain updates so frequently, but it will be helpful later.

  • Added Bandersnatch skill augmentation. If you're using a Bandersnatch, BatBrain looks at the data file to factor in its enhancements to your skills.
  • Moved the Crown of Thrones into the data file.
  • Set myhp and mymp in fvars[] each round (should fix th3ir error above).
  • Allow for "monster" and "notmonster" flags in the special field. The former means the effects only take place against the given monster, the latter means it works against every monster except the given monster. This is incomplete but still an improvement.

Next: now that BatBrain values stat gain, we can include that in all the appropriate event data. Almost nothing in the data file includes stat gain, so this will be another big project.
 
I think I'm going mad from all this Wiki-ing.

I just moved all the familiar data back out from the script into the data file. While I was at it, I added all the missing familiars (BatMan had previously only included about half of them).

The amazing thing about the above paragraph is that it took two sentences to write, but days to accomplish.

I've written a few utilities for myself that will help me identify anything missing from the data files. However, since "update" no longer downloads mafia's internal data files (I used to d/l them and then "update clear" afterwards), I'm not sure how to access these files anymore. Basically I'm looking for a way to find out in ASH if a given item is a combat item. Anyone know how I could get this info from within ASH?

I'm waiting to spin the next update until I add all the Hatrack info to the data file. Woohoo support for everything.
 
I've written a few utilities for myself that will help me identify anything missing from the data files. However, since "update" no longer downloads mafia's internal data files (I used to d/l them and then "update clear" afterwards), I'm not sure how to access these files anymore. Basically I'm looking for a way to find out in ASH if a given item is a combat item. Anyone know how I could get this info from within ASH?

You can use file_to_map() to access them in ash even if they aren't in your data directory

If you want to get them into your data directory you can use winzip or winrar to pull the data files out of KoLmafia.jar or use "update data" to download them
 
Last edited:
However, since "update" no longer downloads mafia's internal data files (I used to d/l them and then "update clear" afterwards), I'm not sure how to access these files anymore.
Works for me.

> update data

Downloading adventures.txt...
Downloading buffbots.txt...
Downloading classskills.txt...
Downloading combats.txt...
Downloading concoctions.txt...
Downloading consequences.txt...
Downloading defaults.txt...
Downloading equipment.txt...
Downloading familiars.txt...
Downloading foldgroups.txt...
Downloading fullness.txt...
Downloading inebriety.txt...
Downloading itemdescs.txt...
Downloading modifiers.txt...
Downloading monsters.txt...
Downloading nonfilling.txt...
Downloading npcstores.txt...
Downloading outfits.txt...
Downloading packages.txt...
Downloading pulverize.txt...
Downloading spleenhit.txt...
Downloading statuseffects.txt...
Downloading tradeitems.txt...
Downloading zapgroups.txt...
Downloading zonelist.txt...
Please restart KoLmafia to complete the update.

> update clear

Please restart KoLmafia to complete the update.

Basically I'm looking for a way to find out in ASH if a given item is a combat item. Anyone know how I could get this info from within ASH?
I see that item_type() exists - but, that returns "food" or "zap wand" or "familiar larva" or "shield" or "accessory" or "shirt" - which are all primary uses for items. "combat" is (often) a secondary use for a "usable" item, and I don't see anything that checks for that.

You can do things like that for a skill using a proxy field:

> ash $skill[stream of sauce].combat

Returned: true

> ash $skill[cocoon].combat

Returned: false
so, one might think that a $item should have a proxy record associated with it too, for such uses. But, no. Instead, we have things like is_tradeable(), is_giftable(), autosell_price(), and so on. In retrospect, all of those should just have been proxy fields of a $item, rather than special functions. But for some reason, Jason didn't implement proxy records back when ASH was being designed, years before he joined the team. :)
 
Works for me.

Me too, now that I remembered it's "update data" and not "update" like it used to be. It's been ages since I've needed to figure out what data was available in mafia's data files (which means, in my opinion, ASH is working quite well).

I'm just parsing tradeitems.txt now looking for the "combat" tag -- all is well.

I did not know that whole proxy record thing was possible! I don't think that's in the ASH Wiki either. What are the possible proxy fields and which other data types does that work for? This could be extremely handy -- in fact, depending on the fields available I can probably rewrite the entire mana-burning section of my logout script.
 
Jason announced this in revision 9028 which says:

r9028 | jasonharper | 2011-02-09 19:33:29 -0600 (Wed, 09 Feb 2011) | 13 lines

ASH item and familiar values (and more types in the future) can now be
treated as read-only records, to access various attributes that previously
required reading a data file with file_to_map(). Example: for any item X,
X.inebriety is its amount of drunkenness, 0 for non-booze items. This
approach avoids the inevitable breakage of existing scripts that would have
occurred if I had added global functions for each of these attributes.

To find out what attribute fields are implemented for some datatype, just
display an arbitrary example of that type via the gCLI "ash" command:
"ash $item[hell ramen]" or "ash $familiar[cocoabo]" for example.

Also removed some lingering traces of a couple of former item use types.
and followed it up with:

r9033 | jasonharper | 2011-02-12 14:29:49 -0600 (Sat, 12 Feb 2011) | 2 lines

Add proxy records for ASH skill, effect, and location values.
So there is, in fact, a $item proxy record.

> ash $item[hell ramen]

Returned: Hell ramen
fullness => 6
inebriety => 0
spleen => 0
notes => 20-29 meat
descid => 388744461
levelreq => 6

> ash $skill[entangling noodles]

Returned: Entangling Noodles
level => 2
traincost => 500
class => Pastamancer
libram => false
passive => false
buff => false
combat => true
permable => true

> ash $familiar[volleyball]

Returned: Blood-Faced Volleyball
combat => false
hatchling => blood-faced volleyball
image => debug.gif

> ash $effect[gothy]

Returned: Gothy
default => use either 1 spooky eyeliner, 1 spooky lipstick
note =>
all => aggregate boolean [string]
**use 1 spooky eyeliner => true
**use 1 spooky lipstick => true
**drink 1 gloomy mushroom wine => true
image => http://images.kingdomofloathing.com/itemimages/gothy.gif
descid => 06cb86ddd689278c5af31423a8210a72

> ash $location[harem]

Returned: Cobb's Knob Harem
nocombats => false
zone => Knob
parent => Knob
parentdesc => Cobb's Knob
It would be easy to add additional $item fields. For example, plural, usable, multiusable, combat, curse, candy.

What do you currently parse out of data files (or build-in to your script) that would be easier to pull right out of KoLmafia's internal data like this?
 
Did Christmas come early this year? This is the most fantastic thing to happen to ASH since ternary operators! I noticed the record-like output when using the CLI "ash" command, but didn't realize this was also ASH-accessible information.

  • For this particular script, "combat", "usable", and "multi-usable" would make handy item fields. Presently that information is included in the script's ever-growing data file, but I'd imagine removing the string-parsing involved in retrieving it would speed the script up a wee bit (contains_text(<record.field>, "multi") is probably not as fast as $item[name].multi).
  • I don't think this is present in the data files (yet?) but it would be excellent to have a "plurality" field for monsters -- I think StDoodle may have already requested that this info be included in the data file as it becomes known. That would obsolete one of the four maps that BatMan loads on running.
  • Bounty items could include in the "notes" field some info about where they're found and how many are needed (something like "<n> needed from <loc>"). That would obsolete another map BatMan uses.

Those last two aren't so much making existing mafia data accessible as adding more data to mafia. So, for scripts in general, I took a look at the Map Manager to see what information people felt the need to create separate maps for.

  • For all of the above types it could apply to, having an "image" field would have uses, especially in writing relay scripts. There are several maps on the Map Manager simply matching image names to a subset of a data type, which could be eliminated if the image name were accessible this way.
  • There are also several maps matching familiars to their hatchlings, which it appears have already been obsoleted by this development.
  • Also also, there are several maps matching effects to their enchantment(s) (i.e. Oleaginous Soles => +40% Combat Initiative), which may or may not already be in the "note" field for skills, not sure on that one.
  • Relatedly, I'd really like item_type() to return "pasta guardian larva" where applicable -- that would help a good deal in parsing conditional drops from item_drops_array().
  • Are substat gains included in the notes field for consumable items? I have a script that parses the three relevant consumables files for that info.
  • SmashLib (still in rather widespread use) loads two data files for information -- looks like the info it grabbed from equipment.txt is now available in ASH with get_power(), can_equip(), and item_type(), but the info it grabbed from pulverize.txt (special results from smashing -- or nosmash / upgrade flags) is not available.
  • The last one I can think of is the creation method for creatable items -- where mafia says something like SUSE SMITH TINKER ACOCK etc. There are several scripts around that load concoctions.txt just to get the creation method.

If you'd like me to post this elsewhere or make feature requests out of each point, let me know. I just answered the question in the place it was asked.

Thanks again for bringing this to my attention!
 
It would be easy to add additional $item fields. For example, plural, usable, multiusable, combat, curse, candy.

Not really related to BatMan, but could you add the adventure gains for food? It's in the datafile as a string in the form of a range.
 
For this particular script, "combat", "usable", and "multi-usable" would make handy item fields. Presently that information is included in the script's ever-growing data file, but I'd imagine removing the string-parsing involved in retrieving it would speed the script up a wee bit (contains_text(<record.field>, "multi") is probably not as fast as $item[name].multi).
Revision 9197 adds a few things:

item.plural is a string which is the plural name of the item
item.combat is a boolean which says whether or not you can throw it in combat
item.usable is a boolean which says whether you can "use" an item
item.multi is a boolean which says whether "using" the item will do it all at once or one at a time
item.reusable is a boolean which says whether or not you lose the item when you use it, in or out of combat

I don't think this is present in the data files (yet?) but it would be excellent to have a "plurality" field for monsters -- I think StDoodle may have already requested that this info be included in the data file as it becomes known. That would obsolete one of the four maps that BatMan loads on running.
If you can find the request for the info to be added to monsters.txt, please add a response asking for it to be available in proxy data. Note that we have no proxy records for monsters yet...

Bounty items could include in the "notes" field some info about where they're found and how many are needed (something like "<n> needed from <loc>"). That would obsolete another map BatMan uses.
Bounty item support could stand to be refactored. It's all tied into locations. We have the data to go from a location to the bounty item and count, but no efficient way to do the reverse. I would suggest the following fields:

item.bounty = location
location.bounty = item
location.bounty_count = integer

Make a feature request.

For all of the above types it could apply to, having an "image" field would have uses, especially in writing relay scripts. There are several maps on the Map Manager simply matching image names to a subset of a data type, which could be eliminated if the image name were accessible this way.
We don't save item image names. We could easily scrape them from the item description.

Make a feature request to do said scraping, add it to the data files, somewhere, and make an item proxy field to retrieve it.

There are also several maps matching familiars to their hatchlings, which it appears have already been obsoleted by this development.
Nothing for ME to do here. :)

Also also, there are several maps matching effects to their enchantment(s) (i.e. Oleaginous Soles => +40% Combat Initiative), which may or may not already be in the "note" field for skills, not sure on that one.
No. The "note" field for effects tell you how to get the effect - and the "all" field breaks multiple methods into a map.

To go from effect to modifier(s) is something else different - which we COULD calculate. Make a feature request if you want...

Relatedly, I'd really like item_type() to return "pasta guardian larva" where applicable -- that would help a good deal in parsing conditional drops from item_drops_array().
Sounds like a feature request.

Are substat gains included in the notes field for consumable items? I have a script that parses the three relevant consumables files for that info.
No. We should have .adventure, .muscle, .mysticality, and .moxie fields. I think Bale asked for that. Sounds like a feature request...

SmashLib (still in rather widespread use) loads two data files for information -- looks like the info it grabbed from equipment.txt is now available in ASH with get_power(), can_equip(), and item_type(), but the info it grabbed from pulverize.txt (special results from smashing -- or nosmash / upgrade flags) is not available.
Sigh. Who wrote smashlib? Who will update it? If I see it being updated to not read equipment.txt, I'd be more inclined to help it obviate pulverize.txt. Feature Request.

The last one I can think of is the creation method for creatable items -- where mafia says something like SUSE SMITH TINKER ACOCK etc. There are several scripts around that load concoctions.txt just to get the creation method.

If you'd like me to post this elsewhere or make feature requests out of each point, let me know.
I want individual feature requests, so that we can address each one individually, rather than only being able to close the bug after we've done everything - assuming we ever get to doing everything.
 
I want individual feature requests, so that we can address each one individually, rather than only being able to close the bug after we've done everything - assuming we ever get to doing everything.

I'm making a whole kaboodle of feature requests to satisfy the feature request requests. I am hopefully helpfully helpful.
 
Fantastic! I'll remove the now redundant info from my data files.

Looks like Bale made all the feature requests at the same time I was making them. I just decided to sit back and let him make them all. :)

Except two: I've added the request to StDoodle's request (and enhanced it a bit), and my feature request for item_type() => "pasta guardian larva" was made a while back, here:
http://kolmafia.us/showthread.php?3992-Add-quot-pasta-guardian-quot-item-type
 
All feature requests have been made or amended except for the following:

SmashLib (still in rather widespread use) loads two data files for information -- looks like the info it grabbed from equipment.txt is now available in ASH with get_power(), can_equip(), and item_type(), but the info it grabbed from pulverize.txt (special results from smashing -- or nosmash / upgrade flags) is not available.

Sigh. Who wrote smashlib? Who will update it? If I see it being updated to not read equipment.txt, I'd be more inclined to help it obviate pulverize.txt. Feature Request.

This is not necessary. We already have an ash function that returns all results from smashing AND the probability of getting those items! Someone should simply update smashlib with that. I don't use it so I have no interest in doing the update myself.

Code:
[COLOR="olive"]> ashq print("If you pulverize 1 million glowing red eyes you should get..."); foreach it,num in [B][COLOR="#008000"]get_related($item[glowing red eye], "pulverize")[/COLOR][/B] print(num + " " + it.plural);[/COLOR]

If you pulverize 1 million glowing red eyes you should get...
1666 effluvious emeralds
666666 clusters of hot nuggets
165000 hot wads
1666 steamy rubies
666666 clusters of stench nuggets
165000 stench wads
666666 clusters of twinkly nuggets
166666 twinkly wads
 
Last edited:
Ok, this seems like aproject I can take on. Just one question: How do you test for empty returns (i.e. items that have the nosmash-setting)?
That appears to be one of the major uses of pulverize.txt in smashlib. Removing the use of equipment.txt was very easy and have already been done.

Code:
int[item] test;
test = get_related($item[Emblem of Ak'gyxoth], "pulverize");
if(test == null)
   print("Empty");
else
   print("Not empty");

Does not work (since null is an unkown variable).
 
You could use count(), since it returns an empty map if there aren't any results:
Code:
> ash $item[ glowing red eye ].get_related( "pulverize" ).count()

Returned: 8

> ash $item[ Emblem of Ak'gyxoth ].get_related( "pulverize" ).count()

Returned: 0
 
Ok, this seems like aproject I can take on. Just one question: How do you test for empty returns (i.e. items that have the nosmash-setting)?

This function from relay_OCD should answer that and a few other questions:

PHP:
boolean is_pulverizable(item it) {
   int [item] pulvy = get_related(it, "pulverize");
   if(pulvy contains $item[useless powder])
      return false; // Let's not count useless powder...
   if(count(pulvy) > 0)
      return true;  // Yay! Something useful!
   // Powders and nuggets can be pulverized also!
   if(it.to_int() >= 1438 && it.to_int() <=1449)
      return true;
   switch(it) {
   case $item[sewer nugget]:
   case $item[floaty pebbles]: 
   case $item[floaty gravel]:
      // These things can be turned into wads!
      return true;
   }
   return false;
}
 
I've mostly added support for El Vibrato punchcards to SS. Am I safe in assuming that someone would only command the towering construct to MODIFY SELF (the construct changes to a random other construct) if they 1) lacked the other options and b) had a chance of getting more SPHERE cards (both ATTACK and WALL cards in inventory)?

Pardon the off-topic post. ;)
 
Back
Top