MacGuffin 2.0 -- level 11 quest, automated

[hugsnotdrugs]

Update to a newer version of mafia:
builds.kolmafia.us

Fixed it! Fantastic, thanks a lot.

 

[zarqon]

Rather than wait forever while I slowly try to work out the annoying unsquashable bugs in my Hidden City function, I'll post what I have so-far as a non-working release, and ask for help in tracking down issues. Your help will expedite a working release.

The version I am posting here has entirely new logic for the hidden city, and does not even use hiddencity.ash. It's safe to use and won't break the internet, although I highly recommend adding [ protector ] 1: abort to your CCS. There are two issues I know about which I haven't been able to fix yet.

Issue One
Whenever it encounters an altar, it loops indefinitely:

Visit to Woods: Hidden City in progress...

[790] Hidden City (Square 24)
Encounter: Altared Perceptions

Visit to Woods: Hidden City in progress...

[790] Hidden City (Square 24)
Encounter: Altared Perceptions

Visit to Woods: Hidden City in progress...

[790] Hidden City (Square 24)
Encounter: Altared Perceptions

Visit to Woods: Hidden City in progress...

[790] Hidden City (Square 24)
Encounter: Altared Perceptions

And so forth. With debugging print statements I've tracked down the problem to these lines (specifically the middle one):

      set_property("hiddenCitySquare",get_first(hunt));
      if (!adventure(1,$location[hidden city])) return error("adventure returned false");
      prop = to_lower_case(get_property("hiddenCityLayout"));

The first line executes fine, setting the property to the value of the next unexplored square. Then the line containing adventure() loops -- wtf! The error message is never displayed, and the next line never gets executed.

This is easily to replicate in the CLI -- just set your hiddenCitySquare property to a known altar and try to adventure there just one time. I think this is probably a mafia bug rather than a problem with this script, but either way it's preventing the script from being releasable.

After this happens, you can abort the script and run it again, and it will carry on, since it doesn't try to adventure there now that the altar is detected.

Issue Two

I still can't figure out how the CLI's "hiddencity" command is supposed to work for altars:

hiddencity square [temple|altar itemId] - set Hidden City square [and perform an action there].

Attempting this using the correct square and item number results in:

[2174] has no matches.
Unexpected error, debug log printed.

The debug log shows a java.lang.NullPointerException at net.sourceforge.kolmafia.textui.command.HiddenCityCommand.run(HiddenCityCommand.java:81). So I'm thinking this might be another mafia problem? I suppose it could be done by visit_url() if necessary.

So presently, you need to use the spheres at the altars manually.

Your help in tracking down any other issues (or solving these) would be appreciated!

 

[Bale]

And so forth. With debugging print statements I've tracked down the problem to these lines (specifically the middle one):

      set_property("hiddenCitySquare",get_first(hunt));
      if (!adventure(1,$location[hidden city])) return error("adventure returned false");
      prop = to_lower_case(get_property("hiddenCityLayout"));

The first line executes fine, setting the property to the value of the next unexplored square. Then the line containing adventure() loops -- wtf! The error message is never displayed, and the next line never gets executed.

If it doesn't take an adventure to reveal an alter, then it isn't surprising that this will loop. It's trying REALLY hard to spend that 1 adventure. You'll have to use a version of Alhifar's run_adv(). Something like

boolean explore_square() {
   page_text = visit_url(to_url($location[Hidden City]));
   matcher m_choice = create_matcher("whichchoice value=(\\d+)", page_text);
   while(contains_text(page_text, "choice.php") {
      m_choice.reset(page_text);
      m_choice.find();
      string choice_adv_num = m_choice.group(1);
      string choice_num = get_property("choiceAdventure" + choice_adv_num);
      
      if(choice_num == "0") return error("Manual control requested for choice #" + choice_adv_num);
      if(choice_num == "") return error("Unsupported Choice Adventure!");
      
      page_text = visit_url("choice.php?pwd&whichchoice=" + choice_adv_num + "&option=" + choice_num);
   }
   if(contains_text(page_text , "Combat")) run_combat();
   return true;
}

 

[kain]

I think instead of using adventure() ... you could use boolean adv1( location, int, string ), which tries to spend 1 turn 1 time in a given location.

 

[zarqon]

Ooh, that function definitely did not exist when I was learning ASH. Sounds like just what this situation needs. Nice! Issue 1: probably solved, within hours. Now for Issue 2.

 

[jasonharper]

The "hiddencity N altar" command actually takes an item name, not an ID.

 

[zarqon]

ORLY? It didn't work before. If you say so I'll give it another shot though.

 

[jasonharper]

Oh, I see what the problem is - it's splitting the parameters on spaces with no upper limit, so it's never going to work with an item name with a space in it. I'll fix this shortly, but here's a work-around that will work on existing builds:

cli_execute("hiddencity " + square + " altar \u00B6" + itemID)

(Important: no space between the \u00B6 and the ID.)

 

[Bale]

I think instead of using adventure() ... you could use boolean adv1( location, int, string ), which tries to spend 1 turn 1 time in a given location.

Dang. I forgot about that new function. Well your solution is definitely simpler even if I identified the problem first.

 

[zarqon]

Jason, thanks for the planned fix, as well as the temporary workaround. Unfortunately, I just finished the MacGuffin quest today, so you might actually fix it before I get to use your workaround.

cli_execute("hiddencity " + square + " altar \u00B6" + itemID)(Important: no space between the \u00B6 and the ID.)

Just to clarify: "itemID" means the item name, not the item ID, right?

 

[jasonharper]

No, I really meant the ID there - the \u00B6 character (¶), followed by a numeric ID, is accepted by most CLI commands in place of an item name. The feature exists in order to allow ASH functions to invoke CLI commands with no possibility of fuzzy matching problems, but it's useful here because it allows an arbitrary item to be specified without any spaces.

The problem should be fixed in r7841, but you may want to use the workaround anyway, to minimize bug reports from people who aren't using the latest build...

 

[Skystriker]

I'm sorry for asking such a newb question, but where is "vars_myname.txt" ?

 

[zarqon]

@Skystriker: My fault -- you no longer need to edit that file directly since now there is support for changing that setting directly from the CLI. I edited the first post to reflect that change.

@Jason: Excellent, thanks. Now all that's left is adding spirit/specter support.

I do think I'll end up making the combat CCS more all-purpose, rather than just for physically resistant monsters. As I've been developing it, it has evolved into a bunch of more general-purpose combat functions. The hardest part will actually be estimating damage dealt and received -- it will have to consider monster elements and resistances, spell damage modifiers, your current resistance levels, etc. I need to develop functions that handle a "damage" type, which will be a bit more complicated than just an int.

 

[Bale]

I do think I'll end up making the combat CCS more all-purpose, rather than just for physically resistant monsters. As I've been developing it, it has evolved into a bunch of more general-purpose combat functions. The hardest part will actually be estimating damage dealt and received -- it will have to consider monster elements and resistances, spell damage modifiers, your current resistance levels, etc. I need to develop functions that handle a "damage" type, which will be a bit more complicated than just an int.

Nice to hear that it is coming along. Thank goodness Jason added modifier_eval() to make it possible. I'm really quite curious to see it.

 

[zarqon]

2.0.8 Updates

Ok, the hidden city function is now presumed bugless if not fully functional, so I've made the update in the first post. Even though it's still unable to properly deal with specters, it's an improvement over the previous functionality since counters should still fire properly and specters can be handled by your CCS. You will need a CCS to deal with them (unless your default attack deals enough elemental damage).

Additionally, the script now makes sure you've identified your bottles and fixes the issue with obtain() unequipping Spookyraven's spectacles.

 

[Xenthes]

If I am reading the first post correctly hiddencity.ash is no longer needed,correct?
Just seeing if I can delete it out of my scripts folder.

 

[Bale]

hiddencity is now just a subroutine in macguffin. However it is the only part of this script I actually use, since I hate the hidden city.

I deleted everything that wasn't do_hiddencity() and saved it as HiddenCity.ash for my personal usage. If anyone else wants to be able to do the hidden city separately like we used to, they can just download this, although it isn't an official zarqon product...

 

[bouzdreaux]

I'm getting this whenever I run macguffin.ash:
Function 'vprint( string )' undefined (macguffin.ash, line 318)

What's the dealio?

 

[aqualectrix]

Update your copy of zlib.

 

[zarqon]

@Xenthes: Yes, the hidden city script is no longer required. Please review the first post which has been edited to reflect the changes.

@Bale: Please either remove the notify Zarqon from the hidden-city-only script, or add a script "macguffin.ash". I am unable to parse those notifications.