Feature Custom combat disable for fully scripted KoLMafia users

katyarn

New member
There's a growing prevalence of scripts using either KoL's autoattack system, or passing in macro strings or functions to adv1 and runCombat. Personally I'm a big fan of the design to passing in a macro to adv1/runCombat since it lets you keep all combat code in one logical grouping there's no surprise how combat functions get called back from KoLmafia.

The big consequence of this design is that all the scripts using this system want to set KoLmafia's builtin CCS to do nothing. The solution right now to do that is to distribute your own empty CCS file, with a line like scrollwhendone or twiddle. This is not really a problem now, but I don't think it's a very good scalable solution. Users will find themselves with an ever growing list of CCS files that do nothing as they download these projects.

While I think KoLmafia will generate its own default.ccs file, I imagine a lot of users are accustomed to actually modifying it when writing their own combat macros so relying on that isn't a viable solution. Instead, I propose that KoLmafia that needs a preference to disable the builtin custom combat system and graphically show the user it is disabled when they look at that tab.
 

MCroft

Developer
Staff member
There's a growing prevalence of scripts using either KoL's autoattack system, or passing in macro strings or functions to adv1 and runCombat.
[...]
I propose that KoLmafia that needs a preference to disable the builtin custom combat system and graphically show the user it is disabled when they look at that tab.
Would it make sense to selectively disable CCS when passing in a macro to those functions? If you don't have it, go ahead and CCS. If you do have it, it's like a command line override.

If we wanted to be even more explicit, we could have a version of those commands that has an extra boolean parameter for bypassing CCS.
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
Would it make sense to let users include the statement disableccs; or something to their macro which we can read out and follow?
 
Would it make sense to let users include the statement disableccs; or something to their macro which we can read out and follow?
Problem there is if you do something like
Code:
use(1, $item[photocopied monster]);
It will still call your CCS to handle the fight as it won't have got to your
Code:
run_combat("your macro here");
call yet.

Also note I am not the target demographic for this change. My default.ccs looks like
Code:
[ default ]
consult oracle.ash
So I can handle all combat in my consult script. This however was the best solution many years ago which handled all types of combats which is no longer the case with all the exceptional work done to improve scripting in the last year.

autoscend however is one of those scripts which supplies an "empty" .ccs file as Katarn mentions above (it simply contains a "scrollwhendone") as it uses combat filter functions in ASH for all combat handling.
 

katyarn

New member
I should have actually listed some of the edge cases that scripts handle currently:
  • Using an item that leads to a fight (BRICKOs, fax, desk bells, Seal Clubber figurines, etc.)
  • Casting a skill that leads to a fight (Evoke Eldritch Horror)
  • Entering a fight via a choice adventure that isn't in a zone (science tent, Witchess)
  • Entering a fight via a URL that isn't any of the above (Chateau painting, God Lobster challenge)

Setting a KoL autoattack solves most of these, unless the enemy is a boss (such as God Lobster) and you lose initiative. In that case, KoL's built-in autoattack won't trigger and KoLmafia will run CCS. That said, I don't think setting autoattacks for every fight is a perfect solution to avoid CCS, sometimes you want to react to events in combat with different decisions that BALLS macros can't handle.

Would it make sense to selectively disable CCS when passing in a macro to those functions?
This covers some cases, I think it'd actually be a good thing in general to do that although it could be a breaking change for some scripts that depend on the current behavior (I hope not but, it's possible). Although I haven't experienced it, I imagine that passing in a callback to adv1 and having CCS trigger is highly undesirable.

The other case of using an item or visiting a URL and then calling runCombat needs some other handling. I think adding an additional boolean to all the various ways of entering combat wouldn't really make sense, especially for visitUrl which has two optional booleans already.
 
Last edited:

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
I'd be happy for now to make an inbuilt noop CCS
 

katyarn

New member
One more quick thought: Having an API to switch to a temporary disabled CCS could solve things cleanly.
So a code solution in js might look something roughly like:

JavaScript:
const oldCCS = getProperty('customCombatScript');
const ccsName = `${projectName}Temp.ccs`
const ccsData =
'[ default ]\
scrollwhendone';
try {
    setCCS(ccsName,ccsData);
    restOfScript();
} finally {
    removeCCS(ccsName);
    setProperty('customCombatScript', oldCCS);
}
 
Top