Bug - Fixed Mafia automatically using custom combat macro

Malibu Stacey

Active member
Can I see the CCS section which invoked the consult script, please?
Looks like you had digitize, summon love gnats, extract, sing along and then called WHAM?
The first four would get composed into a macro, each round of which we would show on a single screen, since it was a mcro, and then we'd call the consult script, which would do its stuff.
How did it used to show? Did it show all the rounds from the macro and then all the rounds from Wham, all on one page?

Or did it used to refresh a time or two, showing the initial rounds, and then show the final round?


my CCS looks like this:

Code:
[ default ]
consult consult_test.ash <- does nothing but print the current monster to the CLI to workaround -> https://kolmafia.us/showthread.php?23415-Some-zoneless-encounters-skip-1st-entry-in-CCS
consult oracle.ash <- this is what cast digitize using a macro (my own script)
consult WHAM.ash <- this calls SmartStasis.ash first which submits a macro with summon love gnats, extract & sing along. It then submits its own macro which in this case was a simple attack.

oracle.ash does this for Witchess monsters:

Code:
    string macro;
  
    switch ( mob )
    {
      case $monster[Witchess Knight]:
      case $monster[Witchess Bishop]:      
        if (a stupidly complex condition)
        {
          macro += "skill Digitize; ";
        }
        break;
    }

    if (macro != "")
    {
      visit_url("fight.php?action=macro&macrotext=" + url_encode(macro) ,true,true);
    }

Previously there would be 4 refreshes of fight.php shown in the relay browser in this situation.
  1. The initial start of the fight
  2. My script casting digitize in a macro
  3. WHAM.ash calling SmartStasis.ash casting summon love gnats, extract & sing along in it's own macro
  4. WHAM calling attack in it's own macro which kills the monster & ends the fight.

OK, I did that in revision 19549. It no longer depends on luck to accumulate multiple rounds worth of items; every time we parse a fight response, we create the decorated page which will build up the deferred list of found items, and when the fight is over, you will see all of the items.

I tested with a CCS with three actions and a call to WHAM.

I don't think I want WHAM; it sometimes one shotted with an attack and sometimes used a love song. I can always finish my fights in Barf Mountain with with an attack. :)

Yeah WHAM is dumb about using items when it doesn't need to but thankfully you can set
Code:
zlib WHAM_noitemsplease = true
to stop it doing that.

Did your CCS create a macro with 3 actions or did it submit those actions using use_skill(), attack() etc?

I'll give 19549 a test after the next rollover.

Thanks.
 

Magus_Prime

Well-known member
I use the relay browser extensively, in run, and it may be just my perception, or the network "stars have aligned", but the relay browser seems MUCH more responsive with Veracity's recent changes.
 
Last edited:

Veracity

Developer
Staff member
Did your CCS create a macro with 3 actions or did it submit those actions using use_skill(), attack() etc?
It created a macro with the three actions. I just tried it again, adding Extract

Code:
[ barf mountain ]
try to steal an item
skill pocket crumbs
skill summon mayfly swarm
skill extract
consult WHAM.ash
I went to the relay browser, clicked on Barf Mountain, saw the initial round, and hit the "script" button.

Code:
[1862] Barf Mountain
Encounter: garbage tourist
Round 0: Veracity wins initiative!
<== hit "script"
Round 1: Veracity executes a macro!
Round 1: Veracity tries to steal an item!
You acquire an item: bag of park garbage
Round 2: Veracity casts POCKET CRUMBS!
Round 3: Veracity casts SUMMON MAYFLY SWARM!
Round 4: Veracity casts EXTRACT!
You acquire an item: Source essence (2)
Round 5: One of the mayflies flies into your opponent's throat, causing her to gag and reel.
WHAM: Running SmartStasis
WHAM: Starting evaluation and performing of attack
WHAM: We are going to 1-shot with attack with your weapon.
Round 5: Veracity executes a macro!
Round 5: Veracity attacks!
Round 6: garbage tourist takes 600 damage.
Round 6: Veracity wins the fight!
After Battle: The swarm of mayflies buzzes off into the distance and returns a few moments later carrying a rolled up FunFunds™ bill.
You acquire an item: FunFunds™
Everything leading up to WHAM was put into a macro.

Requesting: https://www.kingdomofloathing.com/fight.php?action=macro&macrotext=%0A%0A%0Apickpocket%0Aif+hasskill+7170%0Askill+7170%0Aendif%0Aif+hasskill+7024%0Askill+7024%0Aendif%0Aif+hasskill+7273%0Askill+7273%0Aendif%0A

WHAM created a macro.

Requesting: https://www.kingdomofloathing.com/fight.php?action=macro&macrotext=scrollwhendone%3B+sub+batround%3B++if+pastround+29%3B+abort+%22Stopping+fight+because+it+has+gone+on+for+too+long+%28set+WHAM_maxround+to+a+higher+value+if+you+think+this+was+in+error%29%22%3B+endif%3B+endsub%3B+attack%3B+call+batround%3B+

It showed me only the final result, since I removed all the pause and wait and refresh logic (the "show me what happened if the timing is exactly right" part.)
It did show me this at the end of the battle:

Found in this fight:

You acquire an item: bag of park garbage [use multiple]
You acquire 2 bits of Source essence
You acquire an item: FunFunds™

Now, I could swear that when I tried this yesterday, sometimes it did not do a pickpocket as the first action - which would be consistent with your bug report where it sometimes doesn't do the first action in your CCS. Looking at the code, I'm not seeing that, and it didn't happen this time.

I'll investigate this further in your other bug report.
 

Magus_Prime

Well-known member
One odd thing that started happening after these changes is that in Kingdom of Exploathing, when visiting the council to collect meat isotopes, there's a "Previously seen" section under the council window that always seems to list the following:

Previously seen:

You acquire 10 rare Meat isotopes
You acquire 10 rare Meat isotopes

The same thing even displays when I collect "your fathers MacGuffin diary".
 
Last edited:

Veracity

Developer
Staff member
Hmm. Presumably because the Council on KoE is a choice adventure - but one you can walk away from.
Do you walk away from that choice or do you accept it?
Rats. I am done with KoE. I’ll think about this.
There is probably a similar choice I can test in aftercore..
 

Magus_Prime

Well-known member
It's a choice adventure but the only choice is "Leave". The "extra" information appears on the relay browser screen below that button while the "choice" is yet to be taken. I forgot to disable Guide before enabling debug mode but here is a log of visiting the Council after finishing the Tavern quest. I am selecting the "Leave" button except for when I exited via reading my father's diary.

View attachment DEBUG_20190919.txt

Interesting...when I visited the Council after finishing the Castle quest I got the following below the "Leave" button:

You acquire 10 rare Meat isotopes
You acquire an item: giant discarded plastic fork [equip]
You acquire 10 rare Meat isotopes
You acquire an item: giant discarded plastic fork [equip]
 
Last edited:

Veracity

Developer
Staff member
That was helpful. We shouldn't need to defer use links on the Council page, since you can walk away from it - but I wasn't setting the "can walk away" flag until after we generated the use links.

I experimented with multi-stage fights (The Gourd) and noticed we generated use links even when another fight immediately followed.

I also noticed that we were generating use links twice in the relay browser: once when we examined the fight or choice, and again when we sent the response down to the browser. That would result in doubling the "previously seen" items which is what you just reported.

Revision 19553 fixes all of that.

I look forward to trying out The Gourd again tomorrow and, hopefully, seeing everything from all the multi-stage fights in a "Previously Seen" section.
 

Magus_Prime

Well-known member
You fixed the issue with the Council visit but, in the perverse way the universe seems to work...

I just got the following in the relay browser, with r19553, when I turned in all three items that Gnasir requested:


You acquire an item: desert sightseeing pamphlet [use]
You acquire an item: desert sightseeing pamphlet [use]
You acquire an item: desert sightseeing pamphlet [use]
You acquire an item: desert sightseeing pamphlet [use]
You acquire an item: desert sightseeing pamphlet [use]
You acquire an item: desert sightseeing pamphlet [use]

The gCLI, correctly, displayed three pamphlets.

Edit: After turning in the pages to Gnasir the wormriding hooks were duplicated in the same fashion in the relay browser.

Sorry I didn't get debug output. I didn't expect it to happen when it did.

One thing that's not appearing with r19553 is the [outfit] link when I get the last piece of an outfit. It happened with both the eXtreme Cold-Weather Gear and Mining Gear. Selecting the outfit from the Outfit drop-down on the Gear pane properly equipped all parts of the outfit.
 
Last edited:

Veracity

Developer
Staff member
I believe that is because we generate a use link when you hand in the item and get the pamphlet, but since you are still in a choice, we defer it - and since you are still in the choice, we "visit" it, which will add another use link.

Revision 19554 hopefully fixes that.
 

Veracity

Developer
Staff member
That last change fixes the outfit link too, by the way, since it moved the use link generation to after result processing. Just tested on extreme cold weather gear.
 

Veracity

Developer
Staff member
I just went through an entire sequence at The Gourd, with 4 choice adventures and 19 combats. At the end, I got this:

Code:
Previously seen:

You acquire an item: spider web [combine]
You acquire an item: razor-sharp can lid
You acquire an item: razor-sharp can lid
You acquire an item: Knob Goblin firecracker [use]
You acquire an item: Knob Goblin firecracker [use]
You acquire an item: razor-sharp can lid
You acquire an item: spider web [combine]
You acquire an item: razor-sharp can lid
You acquire an item: razor-sharp can lid
You acquire an item: Knob Goblin firecracker [use]
You acquire an item: Knob Goblin firecracker [use]
You acquire an item: spider web [combine]
You acquire an item: spider web [combine]
You acquire an item: spider web [combine]
You acquire an item: spider web [combine]
You acquire an item: razor-sharp can lid
You acquire an item: razor-sharp can lid
You acquire an item: spider web [combine]
You acquire an item: spider web [combine]
You acquire an item: spider web [combine]
You acquire an item: razor-sharp can lid
You acquire an item: Knob Goblin firecracker [use]
You acquire an item: razor-sharp can lid
You acquire an item: Knob Goblin firecracker [use]
You acquire an item: spider web [combine]
You acquire an item: fancy gourd potion [use]
WIsh I'd found some of the rare items to pay for the jar of psychoses, but, hey - science!

I think that multi-fights and fights going to choices going to fights all are working the way I'd like them to work.
 

Veracity

Developer
Staff member
I think this is done.

- I refactored the "script" button in the relay browser to not kick off the fight in a different thread. This eliminates a lot of asynchrony, polling, artificial pauses, etc.
- I synchronized usage of FightRequest.instance so that instance data from one fight couldn't leak into a fight running in anther thread.
- I changed how & when we accumulate delayed use links. We collect them for all rounds of a script, even though you'll now see only the final page of the combat.
- multi fights and multi choices that yield items should reliably accumulate everything seen for display in the Previously seen table at the end.
- I cleaned up how we handle choices that lead to fights to, I believe, recognize that you are no longer in a choice.

Considering that I could not actually identify what caused the original report, I can't guarantee it's fixed, but hopefully the first two things I mentioned did it.

I've automated and run in the relay browser and everything seems to work the way I want. I've not seen my LOV script abort because it thought it was still in a choice.

I'm going to let this bake a couple more days, in case you-all notice anything weird.

But if everything looks good to you-all, I'll mark this fixed and spin release 19.9, which might be the final "official" point release, depending on how other things go in KoL-land.
We'll see.
 

Veracity

Developer
Staff member
I am noticing that my script which runs the LOV is getting "A choice follows this fight immediately." when trying to take the choice following the second fight.
Looking at the code, I cannot see how that is possible, given the ASH functions I am calling.
But, this is new and repeatable, so I guess I need to turn on DEBUG logging and see what's up.
As it turns out, it's not really repeatable, but I figured out the issue. It has nothing to do with my recent changes.

I'm in Marmot in aftercore for the first time since I've had this script. Marmot drops a ten-leaf clover, once a day. If it happens in the LOV tunnel, clover protection tries to kick in and "using" the clover fails because, as the message says, a choice immediately follows the fight where the clover dropped.

Revision 19558 will not attempt clover protection if a fight or choice immediately follows the fight that dropped the clover.
I assume clover protection will kick in after the next fight finishes and it notices the clover.
I bet it will run that fight with an intact clover, though. I wonder if I should try a deferred clover protect or if I shoould just make my script do it manually after the LOV tunnel is done.
 
Top