Dynamic Combat in the Age of Macros

jasonharper

Developer
As KoLmafia inches its way towards full support for combat macros, it's clear that there needs to be a way to dynamically choose combat strategies, based on mafia's knowledge about the monster and the player, without losing the advantages of a macro-driven combat. This isn't always going to be possible (unless TPTB implement the monster HP & level predicates that some people have requested), but the potential improvements in speed and reduction in server hits make it a highly desirable goal.

I don't see any practical way to repurpose the existing consult script mechanism to allow them to contribute to a macro. The point at which the macro is built is not necessarily the time at which a consult script would normally be called; calling the script at that point would completely screw up the combat if it turned out that the script knows nothing about macros. Also, it seems desirable to have some visible difference between the invocation of a consult script and that of a macro-generating script, so that the user can easily tell whether a given CCS section is going to produce a macro-driven or turn-by-turn combat (since there are likely to be CCS commands that are only valid in one context or the other, or that have different behavior between the two).

For the sake of argument, let's call this new form of script an "employ script" - the idea being that an employee is generally eligible for benefits that a consultant would never receive. All employ scripts in the relevant CCS section would be called once, at the very beginning of the combat, and allowed to extend or modify the combat macro being built. They could make use of all of mafia's functions for retrieving data about the monster or the player, with the understanding that these values were only accurate at the start of the combat - any changes during the execution of the macro would need to be accounted for in the generated macro code. They would NOT be capable of doing anything that involves server interaction, since the fight has already started.

An employ script would be defined something like this:
string main( string opponent, string pageText, string macroSoFar, string parameter )
* opponent is the name of the monster being fought, just as in a consult script or combat filter function.
* pageText is the raw HTML of the initial combat page. This isn't necessarily going to be useful (since it's a one-time snapshot), however you may want to examine the Skills popup to see what conditionally-available skills are actually available.
* macroSoFar is the current text of the macro being built - a mafia-generated header with some useful subroutines defined, followed by macro translations of all the prior lines in the CCS.
* parameter contains any extra text from the CCS line; it could be used to customize the behavior of the script, more conveniently than using a "note" line with a consult script. It also serves the less obvious purpose of making the parameter count something other than 3, so that mistakenly attempting to employ a consult script, or consult an employ script, will fail before any code runs.
* The return value entirely replaces the macro being built. It would probably be an error for this to be any shorter than the original value of macroSoFar.

The simplest thing an employ script could do is to append some commands to macroSoFar, and return that. Other possibilities include:
* It could look back through the previously-generated macro commands to decide what to do. For example, it could refrain from adding a "pickpocket" action if that has already been done
* If it wanted to set up a global abort condition, active throughout the combat, it could insert the command at the beginning of the macro.
* There will be a subroutine called "mafiaround" defined in the header, and called before every combat action to handle things like automatic antidote use. The script could insert commands into that subroutine, for example to implement an eye color check for using He-Boulder major rays.
* There will likely be other defined subroutines for the script to call or modify.

The question for scripters is: will this work for you? Is there anything you can imagine being doable as part of a macro-driven combat, that would be somehow impossible to do via this interface? If there is anything you feel would still have to be done via a consult script, for any reason other than "it requires tracking the monster HP and/or ML", what is that reason?
 

StDoodle

Minion
As excited as I am to see combat macro support completed, I'm not sure how much I, at least, could commit to an answer right now. As things currently are on the KoL side, I'd at least want to be able to produce a couple of macros in succession, with those beyond the first conditionally executed based on things like how close to dead the monster and I am.

Of course, this means extra server hits... which is bad. However, if and when KoL gains support for variables (and jiggle, and any other miscellaneous basic features that are missing), this would become much less of an issue. If that were to happen, I would probably be okay with current consult scripts disappearing altogether, in favor of macros and "employ scripts."

Also:
...the idea being that an employee is generally eligible for benefits that a consultant would never receive.
*Sigh* So true...
 

Bale

Minion
* The return value entirely replaces the macro being built. It would probably be an error for this to be any shorter than the original value of macroSoFar.

That should not be an error. Some people may want to create entirely new macros with no relation to the macroSoFar. In those cases any comparison of the size is irrelevant.
 

jasonharper

Developer
If the script created an entirely new macro, it has just thrown away the entire contents of the CCS prior to the employ command - and any subsequent contents will fail to work, due to loss of the subroutines like macroround that they were expecting to be present.
 

zarqon

Well-known member
Interesting. You're talking as though a script would be part of making the macro -- but I see a macro as being a really handy part of a consult script. I'm not sure about this "employ" concept -- I'll wait and see -- but I know for a fact that I would definitely like a buffer macro(string) ASH command for use by consult scripts. Right in there with attack(), throw_item(), and run_away() (or however you decide the series of actions should be expressed -- whether it's exactly KoL syntax or abstracted somewhat). It should be able to include the same "mafiaheader" subroutines, perhaps as a second boolean parameter, or perhaps as a keyword in the string, whatever.

Such a command would be quite useful for consult scripts, not only for the obvious case of DB combos, but also for stasis situations (stasising until a specific message, then performing an action). And having a consult script calling the macros makes a lot of sense since ASH knows a lot more than the fledgling KoL-side scripting commands make available. In the case of BatMan, I'd like to be able to hand the combat off to a macro once there's nothing else special that needs doing.

Slightly related: are you planning to have mafia auto-macrofy remaining actions after a consult script is finished, rather than treating the whole combat as un-macrofyable if a consult script is included? Sometimes consult scripts do nothing, and they are followed by just "attack" -- macrofying the rest of the combat here would be quite helpful. I'm pretty sure you've already considered this, just mentioning it to be safe.
 
Last edited:

Bale

Minion
I'm wondering if a combat script that can edit a macro is still an intended feature for KoLmafia.

If it's on the table, but you've been busy, that's cool. I'm just curious if this is still being worked on, even if only sporadically.
 
Last edited:

jasonharper

Developer
I'm not even currently playing the game, so don't expect this any time soon. (Originally, a deteriorating net connection made it almost impossible for me to successfully log in with mafia; that seems to have cleared up, but I have no time due to a new job.)
 

Bale

Minion
Thanks. I kinda figured that you were busy based on the commit logs, but I'm glad to know for certain.

Good luck with your job. I hope things get less hectic and I hope you return to KoL someday, regardless of what you do with mafia.
 

StDoodle

Minion
I hope things get less hectic and I hope you return to KoL someday, regardless of what you do with mafia.

Speak for yourself! I hope both V & J give up on this silly "Reality" idea and get back to mafia! I kid, I kid... sorta. ;) BTW, your efforts have been greatly appreciated; far more than I'm capable of showing, I'm afraid, but they are nonetheless.

Back on topic; we should try to find another way forward for this. Because I've had a few ideas on how, if such a feature was implemented, I could make one combat script to rule them all! And save server hits. Which would be awesome.
 

zarqon

Well-known member
I think this is already moving forward -- Theraze is blowing away BatMan obstacles, which in turn is giving me more incentive to work on it.

Unfortunately, supporting my existing scripts is first and there have been enough changes to KoL that I'm behind in keeping up. (I wish the blasted crown never existed, to be honest.)
 
Round 0: darkcodelagsniper wins initiative!
Round 1: darkcodelagsniper casts THREAD NECROMANCY!

Employ scripts sound pretty useful to me. I've been playing around with consult scripts recently, but find combat takes a lot longer now that my fights aren't single macros. Sure, I could shunt everything into a single consult that spits out a macro - but then making minor changes is nowhere near as convenient as the CCS gui.

Might any of the current devs be interested in revisiting employ scripts and making them a thing?
 
Top