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?
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?