Bug - Waiting for Info Turn counting problems?

[fronobulax]

r8630, I believe.

Three data points which may or may not indicate a problem.

I am trying to obtain a deck of lewd playing cards. In my sub-optimal fashion, I eat a fortune cookie and note the count. I auto adventure for count minus one turns. I then manually adventure twice. On the second adventure I get the counter expired warning. I then manually adventure in the Purple Light District or somewhere else depending upon where the last semi-rare occurred.

1) At a time when I did not care about the counter because it expired after "today's" turns, I wanted to adventure in one place leaving 10 turns which I would use elsewhere. I set the count appropriately and saw the "X of Y" messages in the gCLI. However it did not stop and continued to burn adventures until I stopped manually.

2) Yesterday I did my usual procedure, but when I did my two manual adventures I did not get a semi-rare or any indication that the counter had expired.

3) This post on the main forum suggests that something similar has happened to at least one other person.

I don't recall exactly when 1) occurred but it was definitely recent enough that the Hipster count could be related. However, I don't have a Hipster.

 

[Theraze]

In the case of number 3, hipsters may +- the count... fairly easy to test by eating 2 cookies to make the number guaranteed, then hipster-combatting and eating another 1-2 to check if the number still matches expected.

In yours... I'm confused by both. For the first, are you saying that it went up to 15 of 10 combats, or went to 10 of 10 and kept fighting, or that it said 1 of 10 and then stopped saying the number, or kept giving the same number? For the second, are you certain that it was the right semi-rare number (2 cookies), or was there a chance it was just the RNG hating you and that the number shown was wrong in both cases?

 

[Veracity]

I finished a run last night. I had stopped eating cookies at some point, since I wanted to get more turns from my food, but after I freed the king, I decided to use cookies again and do my usual aftercore semirare routine.

eat 2 fortune cookie
You gain 2 Adventures
You lose some of an effect: Got Milk
You gain 2 Adventures
You lose some of an effect: Got Milk
Lucky numbers: 201, 253, 57
Lucky numbers: 289, 40, 169

Six different numbers, three of them obviously too big. Since the accepted wisdom is that if you don't get the semirare counter nailed down with two cookies, it's ready to go THIS TURN, I adventured once:

[1220] Haunted Billiards Room
Encounter: chalkdust wraith

Nope! How about another cookie?

eat 1 fortune cookie
You gain 2 Adventures
You lose some of an effect: Got Milk
Lucky numbers: 168, 200, 14

Ah, guess what: that 168 matches the 169 from before that adventure. So, it took THREE cookies to nail down the real semirare counter this time.

Given all that, a couple of comments:

1) Nothing has changed in how KoLmafia counts turns for a long time.
- It numbers your turns based on Charpane refreshes.
- Semirares are (fortune cookie counter ) + (turn count)
- It updates the turn count when the Charpane gives a different turn count.
- Other than that, it does not "count" turns. It does not add one to the turn counter for any reason other than the Character Pane telling it to do so.
2) Fortune Cookies are, as my experience of last night shows, funky.

Regarding the Hipster: Here is a log that shows something of it:

[558] Haunted Bathroom
Encounter: toilet papergeist
...
[559] Haunted Bathroom
Encounter: evil ex-girlfriend
...
[559] Haunted Bathroom
Encounter: Don't Hold a Grudge
...

Notice that the Charpane did not update the turn counter after the Hipster combat. In other words, that combat did not use a "turn". And therefore, since KoLmafia does not "count" turns, it did not change the semirare counter.

I'd be interested to see if the fortune cookie counter was "off" somehow after that encounter. If so, it would imply that KoL itself uses something other than raw turn counter to tag when the next semirare comes. That would surprise me. (That run was HCO, so no cookies were used, so my log can't tell me.)

 

[fronobulax]

Thanks.

Missing the semi-rare could be operator expectation error. My experience had been that if there was any doubt mafia put multiple expiration counters in the status pane and I know there was only one. However veracity's experience suggests that one cookie plus the information from the previous semi-rare is not guaranteed to correctly predict the drop so it sounds as if my expectations need to be adjusted.

On my point 1) above, to clarify:

I have 50 turns left. I want to spend 40 in the PostWar Frat house and ten in the Unlucky Sewers. I enter 40 in the turn spinner and make sure no conditions are checked. I watch the gCLI output count X of 40 turns. It shows 40 of 40 and then kept adventuring with the next adventures lacking any "X of Y" annotation. I Stopped mafia after the second one and the turn count showed I had 8 turns left. As far as I can recall, I did not have UR or any recovery options set in such a way that recovery would trigger and burn turns.

 

[Theraze]

Do you have the CounterChecker script or anything like that? I find that will burn turns outside of the directed count... not sure what else would make it keep going. Haven't had that experience myself yet.

 

[fronobulax]

Do you have the CounterChecker script or anything like that? I find that will burn turns outside of the directed count... not sure what else would make it keep going. Haven't had that experience myself yet.

No.

 

[Theraze]

Next time it happens, session log maybe?

 

[fronobulax]

Next time it happens, session log maybe?

The information I would want is not in the session log.

[406683] Frat House (Stone Age)
Encounter: caveman frat pledge
Round 0: fronobulax wins initiative!
Round 1: fronobulax executes a macro!
Round 1: fronobulax attacks!
Round 2: caveman frat pledge takes 2310 damage.
You gain 42 Meat
You acquire an item: cup of primitive beer
After Battle: PeggyLee bends its brim into an approximation of a smile.
You gain 45 Fortitude
You gain 72 Magicalness
You gain 24 Smarm

cast 1 Leash of Linguini
You acquire an effect: Leash of Linguini (duration: 10 Adventures)

[406684] Frat House (Stone Age)
Encounter: caveman frat pledge
Round 0: fronobulax wins initiative!
Round 1: fronobulax executes a macro!
Round 1: fronobulax attacks!
Round 2: caveman frat pledge takes 2309 damage.
You gain 40 Meat
After Battle: PeggyLee bends its brim into an approximation of a smile.
You gain 34 Beefiness
You gain 90 Enchantedness
You gain 20 Cheek

[406685] Frat House (Stone Age)
Encounter: caveman frat pledge
Round 0: fronobulax wins initiative!
Round 1: fronobulax attacks!
Round 2: caveman frat pledge takes 2310 damage.
You gain 36 Meat
You acquire an item: chunk of rock salt
After Battle: PeggyLee bends its brim into an approximation of a smile.
You gain 26 Strengthliness
You gain 89 Mysteriousness
You gain 30 Roguishness

[406686] Giant's Castle
Encounter: All The Rave
You acquire an item: Mick's IcyVapoHotness Inhaler

The above shows 1 automated turn followed by three manual turns, the last one giving me a semi-rare. (Things worked as expected.) I don't find anything that tells me when the semi-rare counter expired or anything that shows whether the turn was taken by automation or manually. That or similar information is in the gCLI but not in my session log. Are there settings I should use to get the information or are you just assuming the information is there? Perhaps a feature request might be a mode where everything in the gCLI is also in the session log?

 

[xKiv]

Perhaps a feature request might be a mode where everything in the gCLI is also in the session log?

It's called "mirror".
The "help" command is your friend.

...

(well, okay, it's not really in your *session* log, but would you really enable this forever (and break log parsers)?)

 

[fronobulax]

It's called "mirror".
The "help" command is your friend.

...

(well, okay, it's not really in your *session* log, but would you really enable this forever (and break log parsers)?)

To step away from the problem, it is frustrating to see something happen in the gCLI and then find out it is not in the session log when everyone who wants to help immediately asks for session logs.

A robust parser should not break if new information is added to the log file. I'm not saying all parsers are robust but I would almost rather have a log file that contained what I needed to debug mafia and help teach people how to write robust parsers than the current situation. But I'm not going to advocate such a change so this is a philosophy discussion and not one about a proposed feature.

Short term, it sounds like I will mirror the next few days to files just in case something turns up.

 

[Terion]

I finished a run last night. I had stopped eating cookies at some point, since I wanted to get more turns from my food, but after I freed the king, I decided to use cookies again and do my usual aftercore semirare routine.

(201, 253, 57) (289, 40, 169)

Six different numbers, three of them obviously too big. Since the accepted wisdom is that if you don't get the semirare counter nailed down with two cookies, it's ready to go THIS TURN, I adventured once:

(Encounter: chalkdust wraith)

Nope! How about another cookie?

(168, 200, 14)

Ah, guess what: that 168 matches the 169 from before that adventure. So, it took THREE cookies to nail down the real semirare counter this time.

You say you had stopped eating cookies prior to this; how's this for a possible scenario? It uses one big assumption that I'm not sure of -- that the NS battles don't use adventure.php (and thus wouldn't set the semirare counter):

Your previous semirare (unknown to you, as you had stopped eating fortune cookies) had come up during a hedge or tower or NS fight adventure. Since this occured on a non-adventure.php turn, the counter was not immediately recalibrated; when you then ate a fortune cookie after freeing the King, it gave you random numbers because of a null semirare counter. When you adventured in the Billiards Room, that caused the semirare counter to get set, and your next cookie reported the now-valid semirare counter value of 168. (The 169 from the previous cookies was a fluke coincidence.)

Along with the semirare counter = 0 case you mentioned above, having a null semirare counter would be the other possible case of six unique numbers from two cookies... and I think your situation (as I understood it from your report) may fall into that case.

 

[Theraze]

She had 6 unique numbers with 2 immediately eaten (no break) cookies... how does that relate to your scenario? If your scenario is true, she got NINE unique numbers, two of which just happened to be one number apart... -_- That's even worse for player luck.

 

[Terion]

She had 6 unique numbers with 2 immediately eaten cookies -- which only can happen if: a) the semirare counter is 0, meaning the semirare is ready to occur on the next adventure; b) the semirare counter is null, meaning the character is either newly ascended or had spent the last semirare adventure in a non-adventure.php location and has not spent an adventure in adventure.php yet; c) some wacky semirare thing we don't know about.

She ruled out a) by adventuring in the Haunted Billiard Room and not getting the semirare there. (Well, to be honest, there's an assumption there, as well; if the last semirare she had obtained -- however long ago -- was in the Billiard Room, that would also cause it not to show up even if she was on a scheduled semirare. If her last obtained semirare was somewhere else, then she did rule out a).)

c) is always possible, but we hope not. If we assume c) doesn't exist, for the sake of sanity, then we are left with b); her semirare counter was null because she spent her most recent semirare in the non-adventure.php hedge/tower/(NS?). When she then adventured in the adventure.php Billiard Room, KoL saw her semirare counter was null and set it; then, when she ate a fortune cookie afterwards, there was a valid semirare counter (168) to show up in the lucky numbers.

tl,dr: In my scenario, the first six numbers (two sets) are all random and had no bearing to anything, due to a null semirare counter; only the third set -- after an adventure.php call -- had a valid semirare counter within it. I'm just suggesting a reasoning for her situation other than "Fortune Cookies are funky."

 

[Theraze]

So it's basically the "9 unique numbers, and 2 of them happened to look right because of random change" which is possible, but as her explanation (bad luck is possible though unlikely to cause 3 cookies to be needed) explains fronobulax's initial problem of semirare not being where it was supposed to be with 2 cookies ...with an example that in her case, 3 were required... what's your answer for his problem?

 

[Veracity]

Actually, I misremembered. My session log says that I ate fortune cookies on my last day while I was still in the Island War, after I determined that I was going to have plenty of turns left to get to Her Naughtiness even with a little bit of crappy food.
My immediately previous turn was spent Wokking something - which certainly is not adventure.php. And I had consumed various other turns doing crafting, too, I think.

Yikes.

(And yes, my turncount was poor on that run - but getting a Wossaname does tend to add to turncount...)

 

[Darzil]

Maybe if a null counter is encountered, eating a fortune cookie sets it after the numbers are seen ?

Easiest way to prove it would be to eat several cookies on a newly ascended character. If the first one shows different numbers, but there is a consistent number in the rest, it'd be proved.

So on the first one - It was null, but then set to 169.
On the second one - It was shown as 169.
On the third one (after another adventure) - It was shown as 168.

 

[Terion]

So it's basically the "9 unique numbers, and 2 of them happened to look right because of random change" which is possible, but as her explanation (bad luck is possible though unlikely to cause 3 cookies to be needed) explains fronobulax's initial problem of semirare not being where it was supposed to be with 2 cookies ...with an example that in her case, 3 were required... what's your answer for his problem?

Not quite; it was 2 cookies that gave random useless numbers due to a null counter, then an adventure that called adventure.php and set the counter, then a cookie that gave the now-valid counter (168). It wouldn't have mattered how many cookies V had eaten before the adventure in the Billiard Room; they would have all given random numbers, as the semirare counter would have been null until that adventure.

Maybe if a null counter is encountered, eating a fortune cookie sets it after the numbers are seen ?

I think that has been tested and discounted.

The current understanding is that the counter is set (if it is null/invalid) when you call adventure.php. This is why people can hit their first semirare on turn 220; the semirare counter is not set when you first ascend (or start a new life) , and they had spent 20 or 30 turns in the sewer and whatnot before ever going to an adventure.php location.

OK, quick rundown of the semirare counter and fortune cookies:

If the SR counter is a valid and positive value, a fortune cookie will always return that value as one of its three numbers.
- If the SR counter is 0 (meaning the SR will occur on the next adventure), all three numbenrs will be random.
- If the SR counter is invalid, all three numbers will be random.

The SR counter is set when calling adventure.php. All SR locations are also adventure.php locations, so obtaining a SR also sets the counter for the next one.

The SR counter is invalid in two cases:
1. New or newly ascended characters.
2. When spending the SR turn without calling adventure.php (such as crafting, shoring, sewer fishing, Barrels, DD, hedge, tower, etc.) <-- This is what I think may have occured to Veracity; not something "funky" about fortune cookies.

In both cases, the counter is only invalid until adventure.php is called; but until then, fortune cookies just return random numbers.


Oh, yeah, there was an OP somewhere... I've had the occasional glitch where a combat result page never got returned (which I chalked up to network issues somewhere in the vast virtual miles between KoL and myself), but Mafia always got sorted on the next adventure, when the current adventure number got passed in the page information. SR counters have never been affected by other adventure-less adventures (like seals, bricko monsters, or Eau de Tortue taming attempts) so I find it unlikely that the hipster combats would do so.

 

[Theraze]

Just random luck that one of the 6 earlier matched... Always fun.

So with fronobulax and his initial problem, why all this series of posts began... are we blaming random RNG-hate, client-bug, or some sort of non-adventure turn?