Bug - Fixed Mafia miscounts used bowls in bowling alley (in Ed?)

xKiv

Active member
I have noticed this in several past few ascensions - mafia will tell me that there are N visits left in the bowling alley, where N is too low.
So I decided to put a breakpoint to it and ...
... it's increasing hiddenBowlingAlleyProgress when I am fighting a pygmy bowler. I haven't even won the fight yet, or gotten the bowling ball to drop.

In GenericRequest, line 2320+:
Code:
		if ( ChoiceManager.handlingChoice && !this.isChatRequest && !this.isDescRequest )
		{
			// Handle choices BEFORE result processing
			ChoiceManager.postChoice1( this );
		}

For some reason, ChoiceManager.handlingChoice is true.


...
Yeah, looks like in GenericRequest.retrieveServerReply, this.responseText contains the page where I got beaten up, and it contains '<a href="choice.php" id="againlink">Continue to the Underworld</a>' - the choice.php in there maybe makes something think that it's now in a choice, which is correct for the next page.
But I am already on the page after that - I chose UNDYING, got a new "You're fighting ..." page (it's already showing in the browser)??? That's probably irrelevant, isn't it? The breakpoint got hit while processing results of being beaten up as Ed, and the next page(s) load in a different thread.
So the problem is that mafia is still processing the choice as if it was my previous choice encounter?

This looks like it would have other sideeffects too (from doubleprocessing choice encounter results when Ed undies on the next encounter).
 
Last edited:

Darzil

Developer
Something strange going on there.
What should happen is:
On choice 787, Fire when ready, if decision 1 is taken (unlocking Alley), set hiddenBowlingAlleyProgress to 1.
If you're adventuring in the alley and hiddenBowlingAlleyProgress is 0, set to 1.
On choice 788, Life is like a cherry of bowls, if decision 1 is taken and hiddenBowlingAlleyProgress is below 2, set to 2. If it is between 2 and 6, add 1.
If you are fighting the spirit and progress is below 6, set to 6.
On choice 788, Life is like a cherry of bowls, if decision 1 is taken but spirit is already defeated, set hiddenBowlingAlleyProgress to 7.
If the Scorched Stone Sphere drops, set hiddenBowlingAlleyProgress to 7.
On choice 787, Fire when ready, if decision 2 is taken (placing sphere), set hiddenBowlingAlleyProgress to 8.
If the Ancient Amulet drops, set hiddenBowlingAlleyProgress to 8.

It sounds like somehow it thinks it is in choice 788 having hit choice 1, rather than choice 1023 having not yet hit anything.
 

xKiv

Active member
It sounds like somehow it thinks it is in choice 788 having hit choice 1, rather than choice 1023 having not yet hit anything.

My current understanding:
It's not in 1024 (or 1023) yet. It's in a fight, in the round where I got beaten up. The link to underworld is "choice.php" which I believe confuses mafia into thinking it's in a choice encounter, and makes it reuse numbers from last choice.
First hiddenBowlingAlleyProgress got set to 2 when I hit choice 788, then the fight made mafia think it's in 788 again, and hiddenBowlingAlleyProgress got increased to 3.


I got confused into thinking that this is from processing "like a bat into hell" because I already saw text from returning to the page before I noticed the breakpoint got hit. What I didn't realize is that requests are processed in threads.
 

Darzil

Developer
It's not even related to Underworld, there is something strange going on here.

I just started looking into it. Logged into a new mafia session, so never visited Underworld. Had a bowling ball, so got the encounter first up. Processed that ok. Then I got a fight. My first action was casting Lash, and the choice parsing happened then!
 

Darzil

Developer
Ok, this looks, to me, like not strictly an Ed bug, it's just that hitting a fight with a choice.php link in it is far, far more common in Ed.

Line 3598 of FightRequest sets ChoiceManager.handlingChoice to true if it finds "choice.php" in the html. This doesn't seem right to me, as we see that usually (only?) when we encounter a choice link at the end of a fight, and we aren't actually handling a choice at that stage.

Line 2320 of GenericRequest then sees that we're handling a Choice, and calls ChoiceManager.postChoice1, which should only be called after a decision is made in a choice, and that takes actions based on the most recent choice visited.
 

lostcalpolydude

Developer
Staff member
That was added to handle bedroom fights going into choices, to prevent post-adventure scripts and such from triggering maybe? Apparently it needs some work.
 

Darzil

Developer
Maybe just set FightRequest.inMultiFight ?
Edit - Though we'd have to unset it too.

Or create a new one - ChoiceManager.choiceNext, which we unset when we parse a choice, and set when we see that in fight, and we put appropriate checks wherever else we need them (basically same places as inMultiFight and handlingChoice.

Edit Again - Looking at where FightRequest.inMultiFight is used, I think we need a new thing.
 
Last edited:

Darzil

Developer
r15640 might fix this. Only did some light testing. Not 100% that I got the code for ash run_combat, run_choice and run_turn, as I'm not 100% on what they do, so would appreciate someone running their eyes over it.
 

Ensiferum

Member
I just completed the Bowling Alley with several visits to the underworld in the process - the tracking seems to work properly now.
 
Top