Bug Can't re-adventure in Whitey's Grove

Theraze

Theraze

Active member
[1375] Whitey's Grove
Encounter: whitesnake
Strategy: C:\Program Files\KoLMafia\ccs\default.ccs [default]
Round 0: Theraze wins initiative!
ATT: 45 (5.64% × 5.69, death in 303)
DEF: 40 (95.45% × 57.26, win in 1)
HP: 32.55, Value: 214.44 μ
WHAM: Monster HP is 32.55.
WHAM: Running SmartStasis
Profit per round: ActionProfitDamageOtherbase; Ninja Pirate Zombie Robot (27.9μ)92.67μ5.28 (-5.28 μ/dmg)Att: -1.65 (-0.01 DPR) Def: -1.65 6% stun chance HP: -2.78 MP: 7.78
Round 1: Theraze executes a macro!
KoLmafia declares world peace.
Round 1: Theraze tries to steal an item!
You acquire an item: white snake skin
You lose 4 hit points
You're on your own, partner.
Click here to continue in the relay browser.


> adventure whitey

KoLmafia thinks it is round 3 but KoL thinks it is round 2
Guild already unlocked.
KoLmafia thinks it is round 4 but KoL thinks it is round 2
That area is not available.
Click to expand...
Accidentally did this, thought it was just me, found it was repeatable. Attached a debug log of that adventure which makes it appear that it's not my scripts... mafia is just checking for grove availability on each adventuring segment, despite its availability being stored through level 11 and citadel quest status.
 

Attachments

11278 adds a check for questG02Whitecastle != unstarted. However, it seems like the real issue is that mafia thinks it needs to check that in the middle of a combat. Assuming it's intended that adventure does anything when you're in the middle of a combat.

I suppose your current combat could be in a different zone from where you tell mafia to adventure, so just assuming that you can adventure in that location when you're in a combat (or choice adventure) probably isn't the way to go.
 
Well, adventuring once while in combat basically just runs ashq run_combat() once. What actually happened initially though is that I was on a lousy connection and had forcibly disconnect laggy connections on, because my connection would just randomly drop without warning and mafia would sit there for 10 minutes waiting for a response that would never come. When it dropped during Whitey's Grove adventuring and mafia tried to recover by adventuring again, it gave that error. Ah well. Thanks for the fixings. :)
 
Sure, but it looks like you could be in a fight in the Giant's Castle and type "adventure 10 whitey's grove", and it would finish the fight followed by 9 turns at Whitey's Grove. At least, that's what I would expect without looking at the code.
 
Exactly. I was just giving the reasoning behind why I realized the bug. Not trying to make a weird use-case or suggesting a change in behaviour.

Anyways, just validated about 30 seconds ago that aborting adventuring and re-adventuring in Whitey's Grove no longer provides the fail. Thanks!
 
So the underlying issue here is that KoLAdventure.validate() is called before adventuring. Some zones use a server hit to the container zone to make sure everything is kosher before going ahead with the adventure. Sometimes an item needs to be used, etc. Problem is that validate() has no idea if you're in a fight or not, so when it posts requests and gets fight pages back, bad things happen.

I'm not aware of any function that straight up tells me if I'm in a fight. One can probably be constructed in FightRequest. That may be outside my expertise, I am rather uncomfortable with that subsystem.
 
Couldn't the message being printed (You're on your own, partner. Click here to continue in the relay browser.) also set some kind of internal setting to indicate that you are still in a fight, and then clear the variable if you finish the fight?
 
You could open up a fight in the relay browser, run a couple of rounds manually, then try to do a CLI adventure.
 
FightRequest.clearInstanceData() could set a new FightRequest.inCombat = false. I'm not sure where it would be set to true though. Maybe FightRequest.registerRequest()?

There would also need to be a ChoiceManager.inChoiceAdventure. I think that would be set to true in preChoice() and maybe set to false at the end of postChoice2().
 
Doesn't FightRequest get cleared when the fight ends, and its very existence is proof of being in a fight?
 
Theraze said:
Doesn't FightRequest get cleared when the fight ends, and its very existence is proof of being in a fight?
Click to expand...

I'm still picking up some Java stuff, so maybe the rest of this post is missing your point...

I guess instanceof FightRequest could be a thing that checks if it's a FightRequest. However, it seems like the code calling validate() isn't coming from FightRequest, so that wouldn't help anyway.
 
FightRequest maintains a reference to a single static request object that gets reused endlessly. It doesn't get destroyed ever.

Anyway yes, setting those boolean flags sounds good, I wasn't entirely sure where to put them. Now the tricky part is to defer the call to validate(), run the single combat if necessary, then validate() and go on as normal.
 
Council check stops adventuring in eXtreme Slope

> adventure extreme slope

KoLmafia thinks it is round 3 but KoL thinks it is round 1
council.php: redirected to a fight page.
Click to expand...
Similar to the one with Whitey's Grove, if you change your mind on an eXtreme Slope combat, you can't resume by starting to adventure there again.
 
Heh. Yeah, the specific-bug on Whitey's Grove had been fixed, but the generic bug had remained, so I wasn't sure whether it should get tacked on or not. Thanks for the merge. :)
 
For tracking whether a fight is in progress, it looks like FightRequest.haveFought might already be tracking that. It's set up for some specific purpose that might need some refactoring to make it more general.
 
You must log in or register to reply here.
Back
Top