Bug - Fixed Previous noncombat retained in certain circumstances

[Captain Kirk]

So if I am auto adventuring and I hit a choice adventure

e.g.

[8775] The Sunken Party Yacht
Encounter: Yachtzee!
Manual control requested for choice #918
choice 1: Raid a minifridge (get cocktail ingredients (sometimes Ultimate Mind Destroyer))
choice 2: Dig through the wreckage (get 5k meat and random item)
choice 3: Give that guy some beads, for crying out loud (get Beach Bucks)
Click here to continue in the relay browser.

And I type in the CLI

> choice 1

You acquire an item: bottle of gin
You acquire an item: boxed wine
You acquire an item: orange
You acquire an item: lemon
You acquire an item: strawberry
You acquire an item: coconut shell
You acquire an item: little paper umbrella
You acquire an item: magical ice cubes

Now the next time I hit a choice adventure in the relay browser, it will display the previous choice adventure, in this case Yachtzee!, I can click a button and even see the previous
results, and then it will give me the real choice adventure I am currently supposed to be facing.

It's kind of like the choice adventure gets buffered somehow and you only notice it when switching between the CLI and the relay browser. This can happen with any choice adventure
I'm just showing one for example purposes.

Another way to see this is right after you type choice 1 in the CLI menu, go to the relay browser and click on the main link. You will
see the results of the choice show up instead of the main map.


Any idea?

 

[lostcalpolydude]

It's intentional that mafia stores the results of the page that triggered a manual control stop, so that you can immediately go to the relay browser and see that page. I guess the choice command could clear that state.

 

[Veracity]

I've seen something like this in the Relay Browser by itself.

For example, I automate enough turns to get to my semirare number. I then go to the Relay Browser and I go to a location which is supposed to give me a choice adventure to get the semirare - in Hobopolis, for example. KoL will then display for me the result of my LAST choice adventure, wherever it might have been. If I click on the "Last Adventure" in the charpane (not the adventure location - those actual words, which take you to the "container" in which the last adventure zone was in), KoL refreshes the actual choice adventure.

That doesn't always happen. The last time it did happen, here is what I saw in my session log:

[180998] Dreadsylvanian Woods
Encounter: The Tallest Tree in the Forest
Took choice 725/6: Leave this noncombat
choice.php?whichchoice=725&option=6&pwd
...
[180998] Dreadsylvanian Woods
Encounter: Sweaty-Teeth, Traveler Render
...
[181002] Dreadsylvanian Woods
Encounter: Garbage Juice for Blood
...
clan_hobopolis.php?place=2
clan_hobopolis.php?place=4

[181003] Burnbarrel Blvd.
Encounter: A Tight Squeeze

[181003] Dreadsylvanian Woods
Encounter: A Tight Squeeze
Took choice 291/1: jar of squeeze
choice.php?whichchoice=291&option=1&pwd
You acquire an item: jar of squeeze

The adventure in Dreadsylvania was automated; I had told it to go for X adventures, where X was my semirare counter. When automation stopped, I switched to the Relay Browser, navigated to Town Square and Burnbarrel Blvd., and clicked.

As you can see, it logged it correctly, but showed a weird result - most likely the result of leaving The Tallest Tree in the Forest, my last choice adventure. When I refreshed, it logged it again - as if it were Dreadsylvania - and showed me the choice adventure. I took the option to get the item. And when I typed "counters", it told me that my last semirare had happened -1 turns ago in Dreadsylvanian Woods.

This sounds pretty much exactly like what you observed, with the added twist that it screwed up my semirare tracking.

 

[Crowther]

I've seen something similar for aborts during combat. If I don't look in the relay browser, next time I might see the old combat when I first do something in the relay browser.

 

[Captain Kirk]

It's intentional that mafia stores the results of the page that triggered a manual control stop, so that you can immediately go to the relay browser and see that page. I guess the choice command could clear that state.

So maybe this is a place to start? Won't fix the other issues mentioned, but it does fix an issue.

 

[Darzil]

You can also get it if you are playing entirely in relay browser, are in a fight, and run a CCS which aborts. You get a link to open in the relay browser to continue in chat, and if you don't do so, the page is likely to appear again when you put your first attack on the next fight.

 

[Darzil]

Is there a reason not to clear that information next time you start a new combat or non-combat? Or would we struggle to tell ?

 

[Veracity]

And I saw this repeatedly recently when I was getting spinning wheels for my multis.

Go to the Portal in the Relay Browser (choice 844)
Walk away from the choice by, for example, simply autoadventuring in The Olde Medievale Villagee with the GUI
Go to the Rumplestiltskin map in the Relay Browser. It displays.
Go to the Workshop (or even the Portal) in the Relay Browser and you will see the last response from the Portal.
(Note that even if you went to the Portal again, it shows you your previous stash of crafting materials.)

I'm done with spinning wheels, but, hey - that's what test multis are for.

I'll try to look at this soon in a debugger to fully understand why we are showing the last page in this case (and not others) and what we can do about it.

 

[Veracity]

Turns out that in order to reproduce this I had to attempt to manually adventure in the Portal and get an "unsupported choice adventure". That's the exact same situation as the "manual stop requested" leaving the request available for looking at in the Relay Browser.

Is there a reason not to clear that information next time you start a new combat or non-combat? Or would we struggle to tell ?

Yeah, this is exactly what needs to be done, somehow.

Pondering.

 

[Veracity]

The issue is that we call RelayAgent.setErrorRequest, but the only place which ever clears it is in the RelayAgent itself. I.e., you HAVE to handle it via the Relay Browser. If you handle it elsewhere, the saved request lurks and pounces the next time you visit the same URL as the error request.

So, the "choice" command should obviously clear the error request, since you just handled it in the gCLI.
In my case, the choice adventure was "canWalkAway" and I did exactly that - I just started adventuring elsewhere.

I'm going to create RelayAgent.clearErrorRequest and figure out when, exactly, that should be called.

 

[Veracity]

Revision 15145 should take care of this.