Bug - Not A Bug _saberForceUses increment when visit_url is called

[Thoth19]

mafia version: r26504

When I use `visit_url` to resolve the 1387 noncom, it increments the `_saberForceUses` prefref even if I am not in that noncom. I expect that mafia will notice that I am not in the noncom and therefore not increment the preference.

I noticed this when running my daily script for CS.
```
[65] Combat Lover's Locket
Preference lastEncounter changed from Mother Slime to Using the Force
Encounter: Using the Force
Took choice 1387/3: "You will drop your things and walk away."
choice.php?whichchoice=1387&option=3&pwd
Preference _saberForceUses changed from 1 to 2
You acquire an item: corrupted marrow
Took choice 1387/3: unknown
choice.php?pwd&whichchoice=1387&option=3
Preference _saberForceUses changed from 2 to 3
Preference choiceAdventure1387 changed from 3 to 0
```

The code that generates this part of the output log looks like this

```
set_property("choiceAdventure1387", 3);
cli_execute("reminisce ungulith");
string temp = run_combat();
string page = visit_url("choice.php?pwd=&whichchoice=1387&option=3");
set_property("choiceAdventure1387", 0);
```

I wrote the code this way bc historically I have had issues where I would get stuck in this particular combat, so I just forcibly choose the correct option even when I think it will be handled by the appropriate property.

The impact of this issue is that my saberUses field ends up getting above 5 regularly
```
Preference _saberForceUses changed from 7 to 0
```
and this happens repeatedly in daily logs.

 

[Veracity]

I tried this with two characters:

ashq visit_url("choice.php?pwd=&whichchoice=1387&option=3");

In both cases, even though I did not start in a choice adventure, KoL happily took me to one.

- One character went to whichchoice=1235 - Spacegate Terminal
(But actually in a choice with no options, since the Spacegate was done for the day.)
- One character went to whichchoice=1463 - Reminiscing About Those Monsters You Fought
(and actually in that choice, since I'd not actually reminisced today.)

Chains of choices do exist, so after processing the choice we think you started in, we see what choice you have moved to.
Therefore, since you submitted use the force, we process that, and then detect you have apparently moved to a new choice.

We have no code to detect that you submitted a URL to take a choice option without having submitted a URL to enter that choice.
Because that's not how KOL works.
In fact, KoL itself doesn't seem to notice that and takes you somewhere random.

There are any number of ways you can make your code correct.

For example, assuming your CCS really does have "use the force" in it, don't set a default for that choice and just run it manually, assuming you actually got to use that skill; what happens if you have used all your force uses today?

cli_execute("reminisce ungulith");
string temp = run_combat();
if (handling_choice) run_choice(3);

You are intentionally injecting a bogus URL - and KoL does not react sensibly, to my eye. It put you into a real choice adventure - one you might have encountered earlier that day - which is specifically not the one you requested.

 

[Thoth19]

Fair enough. It feels strange this is fundamentally unsolvable -- especially since the code snippet you posted seems to imply that mafia can detect if we are in a choice and which choice we are in.

I could totally get behind "visit_url" is a force operation and should be used when mafia is out of sync with reality. But it appears that the noncom handling code for mafia works is by saying "when we submit a choice to 1387, increment this pref." Why can't we say "when we submit a choice to 1387, if we are in 1387, increment this pref, otherwise throw an exception." I assume the answer is that we don't actually *know* we are in 1387, we just think that we are in a particular noncom and so this would be unsafe?
The reason this leaves me confused is that I see code (possibly old) that uses a ton of visit_urls, so it seems strange for it to actually be an unsafe hammer command and the proper way of doing things is to use CLI based wrappers.

I've added the handling_choice command and that should fix my issue. I'll find out tomorrow. Thanks for rapid help.

Is there a preference for "tell me if my trackers get out of whack?" For example, getting saber uses above 5, or locket uses above 3 etc. From what I see, there is a default to prefs, but no max to prefs, so this isn't super feasible, but it might be a nice debugging tool. I figure writing such prefs and then asserting with them at EoD would be tiresome to type, but might have some use. I will probably write something like this for my own use if it doesn't exist.

 

[Veracity]

I actually had an error: handling_choice is a function, not a command.

So:

if (handling_choice())

If you submit a URL to enter a choice - or we see KoL redirect to one - we know you are in a choice and expect it when you eventually take the choice.

If we saw you in a choice - like Use the Force - and saw you submit an option and leave it, we expect you are out of the choice, although we do detect choice chains.

If you then, out of the blue, submit a URL that takes a choice option, we trust the URL.

I’ll think about it, but having seen that KoL puts you into some random choice, I’m not sanguine at finding a good solution.

 

[gausie]

I think https://github.com/kolmafia/kolmafia/pull/936 may help with this one a little bit.