Feature - Implemented Custom combat disable for fully scripted KoLMafia users

[Magus_Prime]

As a USER my preference is to use my own CCS to handle combat BUT if a script author wants, or needs, to handle that then that's okay with me. What I dislike, as a USER, is when a script that supplants my CCS can't finish a combat and sends me to the relay browser to continue.

I realize that there are some cases, and situations, that can break both CCS and consult script logic but 99%+ of the times a script aborts a combat and sends me to the relay browser the combat is almost won and a single round of manual combat ends the fight.

As a USER it would be very nice if a script that wants to handle combat would allow the USER to supplement that, or if need be, replace combat handling with a, user-supplied, CCS as a preference.

 

[fronobulax]

Yes this is a convenience. It doesn't really affect script authors though, its a convenience for script users to not have loads of useless empty ccs files in their list.

Must be a different style of interaction. I have CSS files for each character and one named default.css. The later dates to 2011 which may be the last time I did a clean mafia install in my playing directory or it may be leftover from a script that didn't clean up after itself. The [default} sections are identical and only one has monster specific sections in addition to [ default ]. These are because WHAM/SimpleSmack/BatBrain wasn't making the right choices if the goal was to "kill the darn thing ASAP before it kills me". Point being just that I don't normally use a GUI element that displays a list of CSS files or the scripts I now use are not creating loads of useless empty files as clutter.

Is the "useless empty css files" the result of script authors who don't have an agreed upon standard? If there were an empty CSS file that did nothing and had a published name and location, could a script author take responsibility for installing that file (or using it if it was already present) instead of rolling their own?

 

[gausie]

Is the "useless empty css files" the result of script authors who don't have an agreed upon standard? If there were an empty CSS file that did nothing and had a published name and location, could a script author take responsibility for installing that file (or using it if it was already present) instead of rolling their own?

Yeah another solution is for one script author to maintain a known empty ccs and everyone else to use it as a dependency. Still seems like we could just provide something native that does that though

 

[fronobulax]

As a USER what would you prefer frono?

I tend to be a minimalist. I don't like clutter and it makes me sad that I have to deal with three different schemes for "preferences" and don't really have a good tool that tells me that a preference is actually being used by something I am doing.

If something is a mafia preference then I would prefer that I could live with the setting no matter what script I was using. If I have to toggle the preference when I switch scripts I am less pleased. I would prefer that the script author accepted responsibility for toggling and restoring or that it wasn't a mafia preference at all. Did that help?

 

[fronobulax]

Yeah another solution is for one script author to maintain a known empty ccs and everyone else to use it as a dependency. Still seems like we could just provide something native that does that though

I am absolutely in favor of having mafia deploy with a empty css that does nothing and has a known name that script authors can use. The responsibility to switch and restore remains with the script author. That said, since mafia tells me I am about to do something that might be stupid (drink without ode, etc.) it could tell me I am about to use The Empty CSS. If similar warnings were enabled could we suppress that warning if a script was running or would that still fail if state preservation and restoration were not perfect?

 

[reverkiller]

As a script USER if the script advertises it knows best and then aborts after combat that to me is a script problem. The script clearly does not know best or know enough. As a USER I would expect the script author to fix their script or amend their advertising. If the solution is for the script author to relax a "minimal configuration" goal/requirement then that's fine. As a USER I have seen solutions that work well - the script saves my state, replaces my CCS etc. with theirs, and restores things when the script is done. The good scripts use a try/catch/finally construct to guarantee restoration and have checks in place to try and detect a catastrophic restoration failure. My recollection is somewhere in the autoascend forks this was done quite satisfactorily.

Since one of my philosophies for adding features to mafia includes asking whether a script could accomplish the same thing, it seems like this is more of a convenience than a necessity.

Since "minimal configuration" is a goal I have to ask whether making this preference-based makes a script minimally configured at the cost of increasing the complexity of mafia configuration? If this feature is behind an opt-in preference the burden is now on the user to opt-in when running running some scripts but opt-out before running others. I'm sure a user's failure to opt-out would also have the potential to burn thousands of meat and hundreds of turns and the blame could clearly, if unfairly, be laid on the user and not script authors.

For what its worth, garbo does almost exactly what you are describing - it cleans up everything it touches, and it doesn't even leave you in combat if it crashes in combat (most of the time). There are some mafia preferences that you need to change to accomplish goals, but one of the philosophies of garbo is that everyone should be able to use it no matter what state their mafia was in before they used it, and it should put it exactly back in that state when it is done.

(this is a bit of a tangent, but I wanted to make it clear).

 

[fronobulax]

For what its worth, garbo does almost exactly what you are describing - it cleans up everything it touches, and it doesn't even leave you in combat if it crashes in combat (most of the time). There are some mafia preferences that you need to change to accomplish goals, but one of the philosophies of garbo is that everyone should be able to use it no matter what state their mafia was in before they used it, and it should put it exactly back in that state when it is done.

(this is a bit of a tangent, but I wanted to make it clear).

Something that has happened very often to new users of garbo is that they will have a user defined CCS that says something like "attack, repeat", and for some reason garbo fails to disable that CCS (or they have a misconfigured CCS which will interpret itself as attac, repeat). One thing that garbo will do is attempt to free run away from some monsters, like crates in Noob cave in order to set up combat that allows for the use of replacing skills (Macrometeorite, REPLACE ENEMY) into a Knob Goblin Embezzler using the "Be Gregarious" skill. If a user has a custom combat script enabled, sometimes the script will just repeatedly fight the crates, hit them, and waste a turn.

I understood the above quote as saying garbo sometimes failed to replace a user's CSS and thus running with the user's CSS caused problems.

If doing so is a garbo Bug and not Feature then we are entirely in agreement

 

[katyarn]

I think it's too narrow of a view to prefer to fall back to an arbitrary user defined CCS.
Some examples of where this does not do what the user wants:

• Free fight farming: running a random custom combat script can end up spending turns which lose effects and are counter to the goal.
• Minimum turn ascension: running a random custom combat script can likewise spend turns, losing effects and making it harder to complete quests.

Just killing a monster by any means is harmful in these cases.

Falling back to CCS not only occurs because combat goes unhandled by scripts but because of complex issues like:

• KoL built-in autoattack does not trigger when losing initiative against a special monster/boss. (Could be regarded as a KoL bug, but has to be handled regardless)
• Order of operations, where a script may want to call run_combat() after entering combat. For example, if you want KoLMafia to receive the combat history AND use the force, you need to split these operations in two.

 

[Malibu Stacey]

As a script USER if the script advertises it knows best and then aborts after combat that to me is a script problem. The script clearly does not know best or know enough. As a USER I would expect the script author to fix their script or amend their advertising. If the solution is for the script author to relax a "minimal configuration" goal/requirement then that's fine. As a USER I have seen solutions that work well - the script saves my state, replaces my CCS etc. with theirs, and restores things when the script is done. The good scripts use a try/catch/finally construct to guarantee restoration and have checks in place to try and detect a catastrophic restoration failure. My recollection is somewhere in the autoascend forks this was done quite satisfactorily.

Ironically, your example of autoscend is one of those scripts which ships with an "empty" CCS containing only a "scrollwhendone" (as I said in my earlier post in this thread) so it can "workaround" this issue in the first place because it uses combat filter functions to handle combat.

Also autoscend is not a good example of anything. It is horrible at combat and even though it uses combat filter functions it will just give up with an abort when it thinks it can't kill the monster (even when the monster is on a trivial amount of HP which a cast of the level 0 combat skill will kill the monster).

 

[fronobulax]

Ironically, your example of autoscend is one of those scripts which ships with an "empty" CCS containing only a "scrollwhendone" (as I said in my earlier post in this thread) so it can "workaround" this issue in the first place because it uses combat filter functions to handle combat.

Also autoscend is not a good example of anything. It is horrible at combat and even though it uses combat filter functions it will just give up with an abort when it thinks it can't kill the monster (even when the monster is on a trivial amount of HP which a cast of the level 0 combat skill will kill the monster).

I used the phrase one of the "autoascend forks" deliberately since I have no specific recollection of whether what I remember was in the current script or something that was abandoned for some reason. My focus was not on the presence or absence of an empty CSS but on the fact that it almost always successfully saved and restored my state, including my CSS. Perhaps incorrectly, I got a sense that the feature under discussion was being requested because scripters could not figure out how to do things without it and cited save/restore as an example of how it could be done. My apologies if I wasn't clear. Wouldn't be the first time.

 

[Magus_Prime]

Autoscend has, for some time, saved, and restored, a number of script settings: pre/post combat, counter, CCS, etc..

 

[katyarn]

So what I hear, is that you believe that your consult script is coded to handle any case, but it fucked up and gave up.

I presented two types of situations:

1. where finishing combat via arbitrary CCS is detrimental to the user
2. where CCS triggers before scripts can continue with additional functionality

Example for case 2:

adv1($location[the dire warren], -1, "skill open a big red present; skill meteor shower");
// CCS triggers here
run_combat("skill use the force");
visit_url("choice.php");
runChoice(-1);

If you want kolmafia to be able to record what occurs in combat before using the force, you have to split them into two macros and run them separately.

I claim that falling into a CCS to take over when your script fucked up is exactly correct.

You claim that the correct response is to abort the script that depended on your buggy scrpt.

That cannot possibly be correct. If I am depending on your script to fight for me and you fail? That’s a “you problem”. And your expectation is to abort MY script?

I will be very happy to never use YOUR script.

There is a userbase that is already using these scripts and this is the current norm. I created this thread requesting to make this cleanier/easier to accomplish. This already being done with KoLMafia currently, so I think you are arguing against a straw man here. I also think that the hostility is uncalled for. I didn't mean to offend by asking for this.

 

[Laserrobotics]

So what I hear, is that you believe that your consult script is coded to handle any case, but it fucked up and gave up.

I claim that falling into a CCS to take over when your script fucked up is exactly correct.

You claim that the correct response is to abort the script that depended on your buggy scrpt.

That cannot possibly be correct. If I am depending on your script to fight for me and you fail? That’s a “you problem”. And your expectation is to abort MY script?

I will be very happy to never use YOUR script.

And as a counter example, I would be significantly less happy to find that a script I chose to run had wasted potentially hundreds of turns accomplishing exactly nothing, than to find that it bugged out on a combat and aborted so that I could resolve / report the issue. Obviously I would be the happiest to find that it worked perfectly, but...

If you don't want to write/use a script that would use an official Mafia-provided empty CCS, that's obviously your prerogative. I don't really understand the objection to the feature request though, since every script that would use that is already using an empty CCS anyways, it's just that each script doing so has provided its own.

 

[phreddrickk]

I feel like I'm missing something here. The request here just seems to be "give people a standard empty CCS to reference, so that scripts that use an empty CCS don't bloat up your file." These scripts are already overriding the user's CCS. Plenty of scripts do this, often times setting up a CCS that points at the script's associated combat consult script.

I do not see the connection between asking for a small feature to prevent the creation of a billion redundant CCSes and a debate over whether someone's consult script is good enough.

None of the requested features would have any impact on existing scripts. I don't see how creating this option for others is somehow creating an imposition for you.

 

[Ryo_Sangnoir]

I think gausie was right earlier in the thread that the better fix is to add a battleAction "do nothing" instead of providing an empty CCS. The CCS has other logic around it (e.g. pickpocketing, autocopy, can be deleted by user), but the aim is to start a combat, but then fall back to ASH, right? If you want to not create a different empty CCS per script, you can just decide to use a reasonably generic name, and communicate it across script authors? You're all in this thread anyway, and would have to be aware of any Mafia-made CCS in order to use it, and recreate it if the user deleted it?

"do nothing" is reminiscent of the classic way of running combats: visit_url the snarfblat URL, then run_combat whatever it is you want to do. Some other things, like the "reminisce" command, also don't run the CCS by default (although that may be considered a bug). visit_url is used when you want to eat the glitch item in standard play.

I have a branch up that attempts to do this at https://github.com/midgleyc/kolmafia/commit/059d563ff4e38c377f72e2f0707498b52d8aaf1c. It doesn't yet work properly, and I'm not sure FightRequest is the right place to process this.

I suspect similar behaviour to be desired for choices: adventure somewhere, and if Mafia gets a choice it doesn't recognise, fall back to ASH instead of aborting. I don't know if library authors have alternatives here other than using visit_url.

 

[fronobulax]

I feel like I'm missing something here. The request here just seems to be "give people a standard empty CCS to reference, so that scripts that use an empty CCS don't bloat up your file."

The original request was to disable CCS under script control and not just to provide an empty CCS.

I propose that KoLmafia that needs a preference to disable the builtin custom combat system

I think there is general agreement that a mafia provided "empty" CSS is a good thing. Script writers who want to disable CSS could use it (as they do now) but by using the same file the proliferation of empty files would be reduced.

 

[SketchySolid]

Did this feature request morph into a different feature request after the suggested solution was not approved? Or did the conversation end, and this issue will not be addressed. I find myself, as a scripter for mostly personal scripts, wanting a solution to this problem also. It's quite inelegant to set an empty CCS.

One solution I could get behind that I haven't seen discussed, though, is dynamically setting the contents of a CCS via script, instead of only being able to change between predefined CCSs.

 

[fronobulax]

Did this feature request morph into a different feature request after the suggested solution was not approved? Or did the conversation end, and this issue will not be addressed. I find myself, as a scripter for mostly personal scripts, wanting a solution to this problem also. It's quite inelegant to set an empty CCS.

One solution I could get behind that I haven't seen discussed, though, is dynamically setting the contents of a CCS via script, instead of only being able to change between predefined CCSs.

My take after rereading through the thread is that no consensus emerged. No one with the right skills cared enough to craft a patch or a PR. No one without the right skills was able to convince someone with the skills that anything was worth doing. Finally the cost of not doing anything was small - merely a lot of small CSS files that did the same thing because script writers were unable to agree on a common script library or convention for empty CSS files.

If this is going to be revived I think the first step is to decide on a specific solution. Candidates include:

• implement a do nothing battleAction
• mafia provided "empty" CSS
• ability to disable all CSS processing completely
• ability of a script to write a CSS before using

 

[Ryo_Sangnoir]

I am in favour of a "do nothing" battle action. I tried implementing it but didn't succeed.

I am neutral towards a mafia provided "empty" CCS because I don't think it offers anything above the current implementation. A user can delete or modify any mafia provided CCS, so scripts still have to check and override the CCS, same as they would do now. If we declare a "blessed name" for people to use (like "noop"), I think scripts could be written to use it in the same way as if we actually provided an empty CCS, with exactly the same implementation.

If the aim is to have a CCS that can't be deleted or overridden that's a much bigger ask.

My perspective on the "name for an empty CCS file" is that script authors should just pick a name for a file that does nothing, not prefix it with their script, then do that. Even if Mafia provided one, people could still define their own.

 

[SketchySolid]

It's not that script writers can't do that. They are doing that. But I have 4 different "do nothing" ccs files that were made by different scripts in my ccs dropdown. And asking all script-writers to get together and commonly decide on a single thing to do does not feel like a solution.

The exact implementation isn't important to me. I'd like to be able to control combat via submission of BALLS macros from within the script, without needing to package an additional CCS file that doesn't contribute anything, or rely on the user having specific settings already in place. If that means a setting to disable the CCS, or a built-in "ccs noop" being a guaranteed no-action CCS, or something else, then that would be fine.

Not sure how a "do nothing" battle action that you propose would work. How would I set that from within my script?