A Combat Filter is, essentially, a scripted CCS: it returns successive lines that are treating like successive lines from a CCS.
It is called with a "round index" which is the requested line #.
If it returns something that KoLmafia decides is invalid, it will be called again with the next "round index".
Now, if it is coded to return things strictly based on the index it is passed, it will, presumably, send something different back. But what if it is coded to return the same thing back until (something) happens?
For example, I added a new ASH function: can_still_steal(), which will return true if submitting a steal request to KoL is permitted.
1) If KoLmafia thinks the monster has no drops or that it is not "safe" to steal, it will reject the "steal" command. If your combat filter stubbornly requests another steal, Java will take a stack overflow:
We have special code to handle a "consult script which does nothing". Perhaps we need something similar for a "combat filter hich does nothing". That would abort rather than causing a stack overflow, but, it still won't force a steal.
2) So, I changed the filter to return "pickpocket". Unfortunactely, KoLmafia treats that the same as "steal". I changed it to return ""pickpocket"" - which is to say, something that a CCS script would treat as a BALLS directive. Still no joy: KoLmafia aborted with something like "You don't have enough null to continue". Which is to say, it somehow decided it was an item, rather than treating it as a BALLS macro.
Since a combat filter can be a BALLS macro - if it has a ; in it - I wonder if passing back "pickpocket;" would have worked?
In any case, passing back a line that, if it had come from a CCS would be treated as a native-KoL macro request, does not work.
It is called with a "round index" which is the requested line #.
If it returns something that KoLmafia decides is invalid, it will be called again with the next "round index".
Now, if it is coded to return things strictly based on the index it is passed, it will, presumably, send something different back. But what if it is coded to return the same thing back until (something) happens?
For example, I added a new ASH function: can_still_steal(), which will return true if submitting a steal request to KoL is permitted.
1) If KoLmafia thinks the monster has no drops or that it is not "safe" to steal, it will reject the "steal" command. If your combat filter stubbornly requests another steal, Java will take a stack overflow:
Code:
at net.sourceforge.kolmafia.combat.Macrofier.macrofy(Macrofier.java:160)
at net.sourceforge.kolmafia.request.FightRequest.nextRound(FightRequest.java:713)
at net.sourceforge.kolmafia.request.FightRequest.updateCurrentAction(FightRequest.java:966)
at net.sourceforge.kolmafia.request.FightRequest.nextRound(FightRequest.java:826)
at net.sourceforge.kolmafia.request.FightRequest.updateCurrentAction(FightRequest.java:966)
at net.sourceforge.kolmafia.request.FightRequest.nextRound(FightRequest.java:826)
at net.sourceforge.kolmafia.request.FightRequest.updateCurrentAction(FightRequest.java:966)
...We have special code to handle a "consult script which does nothing". Perhaps we need something similar for a "combat filter hich does nothing". That would abort rather than causing a stack overflow, but, it still won't force a steal.
2) So, I changed the filter to return "pickpocket". Unfortunactely, KoLmafia treats that the same as "steal". I changed it to return ""pickpocket"" - which is to say, something that a CCS script would treat as a BALLS directive. Still no joy: KoLmafia aborted with something like "You don't have enough null to continue". Which is to say, it somehow decided it was an item, rather than treating it as a BALLS macro.
Since a combat filter can be a BALLS macro - if it has a ; in it - I wonder if passing back "pickpocket;" would have worked?
In any case, passing back a line that, if it had come from a CCS would be treated as a native-KoL macro request, does not work.