Bug - Fixed Consult script problems

[picklish]

Here's a consult script that's being used bumcheekascend.ash:

string consultBarrr(int round, string opp, string text) {
if (round == 1) {
return "item the big book of pirate insults";
}
return "attack";
}

adventure(1, $location[Barrrney's Barrr], "consultBarrr");

Here's the log that results:

[332] Barrrney's Barrr
Encounter: tetchy pirate
Strategy: /home/enne/.kolmafia/ccs/hardcore.ccs [default]
Round 0: picklish wins initiative!
Round 1: picklish executes a macro!
Round 1: picklish attacks!
Round 2: tetchy pirate takes 16 damage.
Round 2: picklish executes a macro!
KoLmafia thinks it is round 3 but KoL thinks it is round 2
Round 3: picklish executes a macro!
Round 3: picklish attacks!
KoLmafia thinks it is round 4 but KoL thinks it is round 3
Round 4: tetchy pirate takes 14 damage.
KoLmafia declares world peace.

When I go to the relay browser, I get: Invalid macro command encountered: "void"


The same thing happened with a consult script for using a yellow ray. This worked fine when I played yesterday, but no longer works for me at r9094.

 

[slyz]

It looks like adventure() is using your CCS instead of the consult function.

 

[Bale]

Just to be clear, that's called a combat filter, not a consult script. I like to use the correct words for things in hopes of spreading less confusion.

 

[holatuwol]

Oh, I thought those functions returned macros, didn't realize they returned CCS actions. Should be fixed in r9097?

 

[slyz]

I think the code use to look for a semi-colon in the string passed as the 3rd parameter. If there was one, the string was simply considered as a macro. If not, then the combat filter was called.

I haven't looked at the new code, maybe that distinction is still there?

 

[holatuwol]

Well, the distinction on how to handle the third parameter was still there, but the logic on what to do with what was returned changed a bit so that wasn't actually the case.

The reason for that was I assumed that the combat filter function would also generate a macro based on the current monster / round number / monster status, and so I rearranged all the logic accordingly. Since that turns out to not always be the case (it can sometimes generate a CCS action instead), now I just have extra handling on the return value of that function, which should result in the same behavior.

 

[slyz]

FightRequest.java is a big chunk of code to take in, especially given the many ways that it can be called. I'm slowly trying to catch on how everything works, and I guess your re-write will give me another occasion to look into it.

 

[holatuwol]

Yeah, that's one of the reasons why I'm refactoring it. Being away from the code for three years, I'm not 100% confident about what it's actually doing vs. what it's supposed to be doing, and I figure refactoring the whole thing should help clear up my own misunderstandings as well as anyone else's who patches the code base.

 

[Veracity]

It's grown and grown over the years. Certain refactorings - such as cleaning the HTML and walking the tree to figure out exactly what happened in what order - allowed us to fix otherwise unfixable bugs and improve the session logging, but there's an awful lot of black magic in the rest of it that makes it fragile and hard to modify.

I'm all for cleaning up the code to be more readable, reliable, robust, resiliant, refactorable, and (what's a word starting with 'r' for) maintainable.

 

[Ethelred]

I'm all for cleaning up the code to be more readable, reliable, robust, resiliant, refactorable, and (what's a word starting with 'r' for) maintainable.

Repairable?

 

[heeheehee]

I know this thread is flagged as fixed, but using the latest build, I've still been getting this issue -- when using a combat filter with adventure(), it still chooses to use the CCS over the filter.

 

[slyz]

I re-opened it.

 

[holatuwol]

I know this thread is flagged as fixed, but using the latest build, I've still been getting this issue -- when using a combat filter with adventure(), it still chooses to use the CCS over the filter.

What's your combat filter do? I tried a simple one that just returns "run away" and KoLmafia tried to run away.

 

[heeheehee]

It returns either a skill to use (e.g. "skill mudbath") or "attack". I'll check again with a fresh filter, just to be sure.

Edit: basic filter, as an AT:

string filter (int round, string opp, string page) {
  return "skill moxious maneuver";
}

void main () {
  adventure(1,$location[beanbat chamber], "filter");
}

Defaulted to CCS.

 

[holatuwol]

On a character that does not have moxious maneuver, that script tries to use moxious maneuver every round, even though I don't have the skill. On a character that does have it, the script uses moxious maneuver and defeats the beanbat.

What does the script wind up doing for you?

 

[Winterbay]

[1606] Beanbat Chamber
Encounter: beanbat
Strategy: D:\Privat\KoL Mafia\ccs\SC Nemesis.ccs [default]
Round 0: winterbay wins initiative!
Round 1: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 2 but KoL thinks it is round 1
Round 2: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 3 but KoL thinks it is round 1
Round 3: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 4 but KoL thinks it is round 1
Round 4: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 5 but KoL thinks it is round 1
Round 5: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 6 but KoL thinks it is round 1
Round 6: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 7 but KoL thinks it is round 1
Round 7: winterbay casts MOXIOUS MANEUVER!
KoLmafia thinks it is round 8 but KoL thinks it is round 1
Round 8: winterbay casts MOXIOUS MANEUVER!
KoLmafia declares world peace.
KoLmafia thinks it is round 9 but KoL thinks it is round 1
Click here to continue in the relay browser.

With that code I get the above (as a SC). KoL reports "You don't have that skill" when I click on the link. You're not confused by the fact that it says "Strategy: D:\Privat\KoL Mafia\ccs\SC Nemesis.ccs [default]" at the top and thinks it uses the CCS despite that it doesn't? (just checking )

 

[heeheehee]

User error on my behalf -- had auto-attack active and didn't realize it. Sorry 'bout that. It's working fine now. Guess that's what I get when trying to debug stuff when I've been up too long.