Feature - Implemented Fortune Cookie Counter

[SittenSpynne]

I ended up duplicating this in a thread of my own.

I've looked over this thread and it looks like the issue is the same thing I identified when justifying the counter: it's difficult for mafia to tell when your first adventure.php encounter occurs, particularly if you fire up mafia mid-run. I focused a lot of thought on scenarios where you share two machines and decided that if that behavior were rejection criteria then mafia would have no counters. This leaves the "when do I fire the first ascension counter" problem. Here's some arguments I've seen and my responses. (I'm ignoring paths that can eat a fortune cookie, though you could consider a fortune cookie reminder.)

The user might spend adventures outside of mafia and the counter would be inaccurate.
There's lots of things in mafia that don't work right if you take a hybrid mafia/no mafia approach. A short list: flyer tracking, battlefield counters*, user-created counters, mushroom plot automation. Should those features be removed?

*The battlefield can remain somewhat precise thanks to the progress indicators in the UI. This is relatively unique.

Path drop interferes.
I'm not sure what the discussion is. There's three phases:

1. Drop before first adventure.php.
2. Drop after first adventure.php and before first SR.
3. Drop during some SR after the first.

#3 and #2 are similar. If I understand, dropping doesn't affect the *current* SR counter but the *next*. If this is true, no action is required. If not, the algorithm would be "On drop, if SR counters are active, adjust them." This is not a difficult implementation.

#1 is irrelevant if mafia checks the path when setting the counter. I'm assuming this is true, because if it isn't then it should be fixed to support path dropping.

Starting mafia mid-run is wonky.
This is more difficult.

• The SR trigger could be "If $turns > 1 at startup don't trigger". That would cause a user that spent a few turns outside of mafia to not get the first SR counter.
• The trigger could be "If $turns > 100 don't trigger". If someone spends 100 turns in the sewer, the counter won't work.
• The trigger could be "If $playerLevel > 1 don't trigger." There's plenty of ways to get to level 2 without adventure.php.

I think all of these are close enough to edge cases to ignore. For the first, I've already pointed out there are other mafia functions that punish you for spending turns outside of mafia. For the second, a user doing such an action is likely either a newbie who won't care about the SR counter or someone performing a stunt run. I'd argue mafia doesn't seem designed for newbies, and players performing stunt runs can live without the first SR counter. The third seems like stunt runs too. Anything I missed?

I'm not going to drag it out further; if you disagree you disagree and I can always try to write a script that auto-sets the counter for me (I am dedicated oxycore and never play without mafia, so I don't have the edge cases.) Did I properly interpret the arguments in the thread so far, or did I miss something?

 

[slyz]

You know can create your own custom counter? Just make one after you hit adventure.php for the first time (or 2 if you want a window). Type help counter in the gCLI for more info.

 

[SittenSpynne]

I'm aware of that, and still do it when I miss an SR but want to keep track of when the next one might show up. It's not much trouble to make one myself (short of making myself remember to do it on the first adventure.php). Nor would it be much trouble for me to make a shore counter, manually track flyers, or count soldiers on the battlefield for myself.

"You can do it manually" is a poor argument against a feature in a program designed to automate tedious tasks.

 

[Fluxxdog]

I see the argument like this:
For: Mafia should automatically track your semi-rare windows, including your first.
Against: Mafia has no way of knowing when your first semi-rare window would start if you played in a hybrid method.

The major problem is the Against argument is moot. Mafia shouldn't be expected to gather information outside of itself. That is a feature request beyond the scope of programming. However, it can notice outside behavior, just like the island war battlefield. In a character's information screen, there is a counter:
Turns Played (this run): x
If no turns have been spent on signing in, it can watch for the next adventure.php and set its approximations accordingly. This would be completely unambiguous.
If even one turn has passed, it can handle it as if a semi-rare window ended without finding a semi-rare: don't make a counter at all since we have no freaking idea. And the neat thing is, it collects this information already on logging in. And once the counters are set, it's business as usual anyway. Using a hybrid method can already cause errors. At least this way, the risk of incorrect information is cut.

 

[lostcalpolydude]

If no turns have been spent on signing in, it can watch for the next adventure.php and set its approximations accordingly. This would be completely unambiguous.

Not quite. One could hit adventure.php outside of mafia, use a free runaway (so they're still at 0 turns played), and then switch to mafia. This exception could probably be ignored though.

 

[Bale]

If no turns have been spent on signing in, it can watch for the next adventure.php and set its approximations accordingly. This would be completely unambiguous.
If even one turn has passed, it can handle it as if a semi-rare window ended without finding a semi-rare: don't make a counter at all since we have no freaking idea.

An elegant solution.

Perhaps not absolutely free of the slightest out-of-mafia edge case as lostcalpolydude points out, but elegant.

 

[slyz]

"You can do it manually" is a poor argument against a feature in a program designed to automate tedious tasks.

I was just pointing out the manual solution because the main "against" argument is that it would take some developer time, for something that you can make a simple alias for, and that you will use once per Oxy or Booze ascension. We aren't arguing whether this is a good feature or not.
If Jason or Veracity decide it would be interesting, I don't see any reason why they shouldn't go ahead.

 

[yueli7]

moral: dont play outside of mafia? who actually ascends out of mafia and uses in mid-run?
post-ascension script set to about 85-90 turns with oxy-drop (140-ish otherwise) pretty much does the job nicely. couldnt it be part of the default post-ascension with mafia? in that case, the user must have ascended with mafia and have not spent turns? (eat cookie/be cautious of SR reminder instead of SR beginning window)

 

[DoctorRotelle]

Additionally, anyone poking in the code for this issue might want to correct the expected range for a fortune cookie after an oxy-drop/king-liberation thingy. Ok... to be explicit: oxy ends for whatever reason. Mafia had already marked possible semi-rares in a certain window. Now that you can eat, it changes the "possible window" to an inaccurate one as opposed to using the already calculated window (which had been accurate until eating that fortune cookie). The side effect is that, instead of catching the proper SR, it gives an improper one, if any at all, after the proper one as it claims "semi-rare to low" (probably cause you are not in oxy any longer).

Well, it keeps me on my toes!
-=DoctorRotelle

 

[Bale]

I'm puzzled. You're saying that after mafia has already marked a semi-rare window, it will change that window when you drop oxy? Or are you saying that it will ignore that window when it eats a fortune cookie because it just doesn't like those values?

 

[Veracity]

Ok... to be explicit: oxy ends for whatever reason. Mafia had already marked possible semi-rares in a certain window. Now that you can eat, it changes the "possible window" to an inaccurate one as opposed to using the already calculated window (which had been accurate until eating that fortune cookie).

KoLmafia does not "mark possible semi-rares in a certain window" until you eat your first fortune cookie.
You can only eat your fortune cookie after you drop oxy.
Therefore, what you describe is not possible with the code as-written.

I always oxy-drop, these days. I don't always eat a fortune cookie right away. In fact, today, I screwed up and didn't eat one until turn 114. The fortune cookie numbers were 20, 156, 5. KoLmafia did not reject any of them - and the semi-rare turned out to be 5 turns later. Whew.

I'm very curious to learn how you get an "already calculated window" before you have eaten your first fortune cookie, since I don't see any mechanism in the code to calculate such - which is the whole point of this thread, is it not?

 

[Bale]

He's talking about dropping oxy after freeing the king at the end of his oxycore run. I assume he has a semi-rare window because he got a semi-rare while adventuring. (Mafia sets upper and lower bounds when you encounter a semi-rare advenure.)

 

[DoctorRotelle]

Yes: It will ignore that window when it eats a fortune cookie because it just doesn't like those values. And the values are correct.

Many apologies for thread jacking.
-=DoctorRotelle

 

[Veracity]

Near as I can tell, this feature is now implemented, ever since they made oxy dropping useless and started setting the semirare number at ascension, not on the first adventure.php. Since we now start up with an accurate fortune cookie window showing, I'm marking this implemented.