Bug - Fixed First semi-rare counter is now about 70-90 turns

Bale

Minion
I got this today, it puzzled me so much that I had to eat a second fortune cookie to convince me:

Code:
[2] Haunted Pantry
Encounter: undead elbow macaroni
Round 0: bale wins initiative!
Round 1: bale uses the seal tooth!
Round 2: undead elbow macaroni takes 1 damage.
Round 2: Yoroids's red eye glances at an ant crawling at your feet. The ant turns red and begins to smoke. Not, like, cigarettes... Like something that's about to burst into flames.
Round 2: bale casts POINT AT YOUR OPPONENT!
Round 3: Yoroids swings his eyestalk toward your opponent, firing a searing ray of heat at it, dealing 216 damage. Man. That was way more entertaining than fireworks!
Round 3: undead elbow macaroni takes 216 damage.
You gain 10 Beefiness
You gain 10 Enchantedness
You gain 10 Roguishness
After Battle: Yoroids gives you an invigorating hot rock massage.
You gain 22 hit points
You gain 23 Mojo Points
After Battle: Yoroids winks at you with his giant central eye.
You gain 12 Meat
You gain 2 Beefiness
You gain a Muscle point!
You gain 2 Enchantedness
You gain 2 Smarm
You acquire an effect: The Magical Mojomuscular Melody (duration: 10 Adventures)

> eat fortune

Since you are not in a Mysticality sign, you may not visit the restaurant.
Searching for "fortune cookie"...
Purchasing fortune cookie (1 @ 40)...
You acquire an item: fortune cookie
You spent 40 Meat
Purchases complete.
Eating 1 fortune cookie...
You gain 1 Adventure
Lucky numbers: 286, 69, 211
Lucky number 286 ignored - too large to be a semirare.
Lucky number 69 ignored - too soon to be a semirare.
Lucky number 211 ignored - too large to be a semirare.
Finished eating 1 fortune cookie.

[3] Haunted Pantry
Encounter: possessed can of tomatoes
Round 0: bale wins initiative!
Round 1: bale executes a macro!
Round 1: bale attacks!
Round 2: possessed can of tomatoes takes 11 damage.
You gain 6 Meat
After Battle: Lllama smiles at you, a knowing gleam in his eye.
You gain 1 Strengthliness
You gain 2 Wizardliness
You gain 4 Sarcasm
You gain a Moxie point!
You gain a Level!

> eat fortune

Since you are not in a Mysticality sign, you may not visit the restaurant.
Searching for "fortune cookie"...
Purchasing fortune cookie (1 @ 40)...
You acquire an item: fortune cookie
You spent 40 Meat
Purchases complete.
Eating 1 fortune cookie...
You gain 1 Adventure
Lucky numbers: 11, 84, 68
Lucky number 11 ignored - too soon to be a semirare.
Lucky number 84 ignored - too soon to be a semirare.
Lucky number 68 ignored - too soon to be a semirare.
Finished eating 1 fortune cookie.

Apparently my first semi-rare is going to be on turn 71! I'll have to add that counter manually.

The glitch led me to the forum where I found THIS thread explaining how things have changed.
 
I just got a Shark's Chum as my first semi, did some investigation and came to the same thread. And then came here to be super-ninja'd in my bug report by Bale
 
According to Hellion, the initial semirare window is 70–80. Here’s a tentative patch. It’s untested, mind—I probably won’t ascend for another couple of days, so I can’t test it myself.
 

Attachments

I think that, with this patch, numbers between 70 and 150 will never be discarded, even if it's not your first semi-rare.

I tried doing one too but the edge cases drove me crazy =)
 
I think that, with this patch, numbers between 70 and 150 will never be discarded, even if it's not your first semi-rare.
You’re right. I misinterpreted the existing code and thought I followed the pattern when in fact I went off on a tangent. :o And I’m having some trouble thinking about it too. I’ll give it another shot in the morning.
 
Does it still have the issue stated above where it always accepts the low numbers, even when it's not your first semirare?
 
Does it still have the issue stated above where it always accepts the low numbers, even when it's not your first semirare?
Not with Veracity's change, although if you get your first semirare and immediately eat a cookie, numbers between 70 and 150 should be discarded, but won't be. The user will have to be careful about those, or the check on line 3602 of UseUtemRequest.java
Code:
if ( KoLCharacter.getCurrentRun() < 80 )
could be changed to:
Code:
if ( KoLCharacter.getCurrentRun() < 80 && KoLCharacter.turnsSinceLastSemirare() == 0 )

The only weird edge case I can think of is someone who avoids hitting adventure.php for more than 10 turns, then eats a cookie on turn 81. Mafia will discard a number between 1 and 10 that is the correct one.

I'm not too worried about it though, because I don't think people put off eating a cookie for that long, and players who do this know what they are doing and will know that the correct number has been discarded. Not being a softcore speed ascender, I don't know if shore-buffering is still a relevant strategy, so maybe this doesn't even happen at all anymore.

Plus there would need to be a significant amount of work to track when the semi-rare counter is set.
 
Last edited:
although if you get your first semirare and immediately eat a cookie, numbers between 70 and 150 should be discarded, but won't be.
Good point. Although...

Code:
if ( KoLCharacter.getCurrentRun() < 80 && KoLCharacter.turnsSinceLastSemirare() == 0 )

...is not right; that last function is, as it suggests, turns since you last got a semirare - which is 0, if you just got one. We need a new function - KoLCharacter.semiRareTurn() - which will be the actual turn number from the preference - which is 0 if you haven't seen one yet.

Revision 8672 attempts to handle eating a fortune cookie between turns 70 and 80: if you have not yet seen a semirare, we assume that the next semirare could still be the initial one, whereas if you have seen a semirare, we know that the next one is certainly not the initial one.
 
Not with Veracity's change, although if you get your first semirare and immediately eat a cookie, numbers between 70 and 150 should be discarded, but won't be.
This just happened to me on the first SR itself. With 28 turns played:
Code:
Eating 1 fortune cookie...
You gain 1 Adventure
Lucky numbers: 158, 227, 46
Lucky number 227 ignored - too large to be a semirare.
Finished eating 1 fortune cookie.
The 158 should be ignored too, shouldn’t it?
 
In the current code, the focus is on discarding numbers that are too low. Higher fortune cookie numbers are only discarded if they are higher than your current semi-rare window counter or higher than 205 (regardless of how many turns ago your last semi-rare was). I guess that the idea is that if you try to get a semi-rare each time a counter is up, those higher numbers will be discarded anyway once you get one.

I just wanted to add that the semi-rare counter is now set before ascending, so avoiding adventure.php doesn't change the semi-rare counter anymore. So the current implementation is solid.

Adding a maxCounter variable to discard high semi-rare numbers in cases where you don't have a semi-rare window wouldn't be too challenging and would avoid confusion sometimes, although it wouldn't strictly necessary.
 
Ah, neato. There's a thread here already.

I would like to point out that the SR adventure number is set in Valhalla, and it is already known to be 71-81 inclusive when you come back down from the gash. I propose that when you start an ascension, you should get the SR window begin and SR window end flags immediately, with the range 71-81.
 
Just a bump to say that I just ascended, ate a Fortune Cookie on turn 4 (I had 36 advs left in the charpane), and the number 66 was discarded:
Code:
Lucky numbers: 194, 196, 66
Lucky number 194 ignored - too large to be a semirare.
Lucky number 196 ignored - too large to be a semirare.
Lucky number 66 ignored - too soon to be a semirare.
Finished eating 1 fortune cookie.

I guess KoLCharacter.turnsSinceLastSemirare() behaved strangely, although I don't really understand why.
 
It's the 71-81 range... in your case, it was 70. As such, the 71-81 should probably be changed to 70-80. Or 70-81, if 81 has ever been confirmed.
 
Having the number be 66 *after* spending 4 adventures means that the semirare is after spending a total of 4+66=70 turns, which is on turn 71. Which is the lowest value I have seen reported in the kolspading thread.
The 71-81 is *turn on which the SR happens*, not the correct "lucky number" itself. (in fact, the last post (by stupac2) in that kolspading thread says the same thing as of writing this).
 
The code as is doesn't have a "70-80 range". In this case, the number was discarded because it satisfied this condition:
Code:
number < 70 - KoLCharacter.turnsSinceLastSemirare()
where KoLCharacter.turnsSinceLastSemirare() should return KoLCharacter.currentRun in this case (the semirareCounter property should have been 0).
This would mean that (66 < 70 - 4) was considered true...

I guess the problem was simply that the semirareCounter property wasn't reset when I ascended. Put this one on user error I guess, unless I misunderstood what KoLCharacter.currentRun should be.
 
Back
Top