Feature - Implemented Fortune Cookie Counter

Also, HC Oxy is a perfect way to not have to spend more than roughly 40-50 adventures per day :)
I've never oxydropped, otoh I've not been in oxy for a while either. I mainly go teet in order to not have to bother with getting a mixer and to not have to bother about making drinks...
 
You don't have to use your pixie and you don't have to use it to farm !pipes :)
I think I would be more inclined to use the sandworm in that case since it gives turns for spleen without me having to go out of my way to actually farm the darn item first...
 
If you ascend HCoxyNP and drop it in the account menu you get downgraded to HCNP
I answer rhetorical questions too. I seem to recall the reason to do it is that to have the steel item that has the most benefit for the remainder of the run.
 
I answer rhetorical questions too. I seem to recall the reason to do it is that to have the steel item that has the most benefit for the remainder of the run.

You lose the item (if you have it in inventory) or the skill (if you have that) if you drop path (before breaking prism), so it can't be that.
The reason is semirares. When you hit your first adventure.php in oxy, your first semirare counter is set to be something like between 102 and 120 adventures later, unlike any other path, where it's ~160-200.
Then you drop by your friends, eat their ox and drink their booze.
 
To be fair, it is hard to tell on a forum whether the smiley was "pardon my noobisnhess" or "heh I really know what it means, I'm kidding." But yeah, as xKiv said, the only reason to oxy-drop is to get your first SR to show up ~40 turns earlier (nice in HCNP so you can get knob seltzer day 1).
 
<veer>I guess the question was not as rhetorical as I thought. Was my answer correct once in the distant past, say NS-11, or am I just losing whatever is left of my memory?</veer>
 
Yeah, I used to teet-drop all the time in NS11 to get the benefits of stomach of steel in an unrestricted ascension. *sigh*
 
SR counter does not work for the first SR.

KoL Mafia does not display a semi-rare counter for the first semi-rare of an ascension. It knows everything it needs to know to make this work, but doesn't do it. It knows when to decrement the counter and when to leave it alone. It knows that different paths have different SR counters.

(Skip to the TL;DR if you want; I had to write a lot of bug reports today and I'm used to providing a lot of justification to force people to put my fixes over other, less eloquent requests.)

I mentioned this on the game forums and someone pointed out that the counter doesn't start until the first adventure.php location. I haven't fiddled with the source (I'm a .NET programmer but have always meant to peek at Mafia's source) but this led me to a psychic debugging session. Here's what my crystal ball says:

The code that maintains the SR counter is triggered when you encounter an SR adventure. When this happens, Mafia creates the new counters with appropriate values for your current path. Since the counter is triggered on an SR adventure, this cannot happen until you have your first SR encounter.

At this point my crystal ball started picking up some kind of fetish porn so I quit looking. My guess is that somewhere in the code there is a long list of "do this every adventure". To make the first SR counter work, this list would have to include this algorithm:
Code:
If adventure.php has not been accessed yet and the current request is adventure.php:
    Set the SR counters
(That turned out less involved than I originally thought!) This, of course, has issues since it introduces some global state mafia must track. And it's going to get hosed if your settings file gets replaced or if you play on multiple computers; in these cases it could display a completely incorrect counter, which is worse than no counter at all. I'm not going to speculate on solutions yet because I just realized this problem and haven't given it any thought.

TL;DR
It'd be neat if Mafia started counters on the first adventure.php location in an ascension. This only works correctly if the ascension state can be recorded. In the worst case, implementing my proposed fix will display incorrect counters. There may be a better solution, but because of this issue I'm open to the idea that it doesn't work for the first one by design and I chose "feature" instead of "bug".
 
*edit* After some thought I realized it would be better to move any replies into the thread I duplicated.
 
Last edited:
Back
Top