Bug - Fixed Florist Friar showing in queue

bordemstirs

New member
While doing some work with the new get_florist_plants, I saw this:
Code:
Returned: Cobb's Knob Harem
nocombats => false
zone => Knob
parent => Knob
parentdesc => Cobb's Knob
bounty => none
combat_queue => Knob Goblin Harem Guard
noncombat_queue => The Florist Friar's Cottage

Pretty sure that last piece of info isn't quite right.
 

Rinn

Developer
The Florist Friar's Cottage is being added to the noncombat_queue setting

For example:

> ash $location[the haunted library]

Returned: The Haunted Library
nocombats => false
zone => Manor1
parent => Manor1
parentdesc => Spookyraven (First Floor)
environment => indoor
bounty => none
combat_queue => Bookbat; Bookbat; Banshee Librarian; Bookbat; Bookbat
noncombat_queue => Take a Look, it's in a Book!; Take a Look, it's in a Book!; Take a Look, it's in a Book!; Take a Look, it's in a Book!; The Florist Friar's Cottage
 

lostcalpolydude

Developer
My first thought for fixing this was to add a check of ChoiceManager.canWalkAway() to AdventureRequest.registerEncounter() where AdventureQueueDatabase.enqueueNoncombat() is called. However, registerEncounter() is called from GenericRequest right before ChoiceManager.postChoice1(), which is where setCanWalkAway() is called. enqueueNoncombat() depends on ChoiceManager.lastChoice not being set yet, and canWalkAway() depends on it already being set, so I'm not sure how to rearrange things to make that work.

At least I now understand why my initial placement of setCanWalkAway() didn't work.
 

Crowther

Active member
I see that fake non-combats from outside a zone are showing up in the last zone's non-combat queue. How do we know this isn't the way KoL works too? ;)
 

lostcalpolydude

Developer
I see that fake non-combats from outside a zone are showing up in the last zone's non-combat queue. How do we know this isn't the way KoL works too? ;)

The "encounter" isn't in any zone, so there's no queue to add it to. I suppose mafia could recognize that the initial URL isn't for a location, but I'm not sure how to check that.
 

Veracity

Developer
We don't quite model KoL's new usage of choice.php correctly yet. We can also see that in the swimming pool, which will register "Screwing Around" encounters. I'll see if I can rationalize that and take care of both the Florist Friar and the Swimming Pool - and make it easy to deal with new choices that aren't really "encounters" more consistently.

We manage it with the folder holder. Huh.
 

lostcalpolydude

Developer
Every place where the queue seems at all relevant is adventure.php. (Mafia currently tracks it for other locations, but for all of them it's clear that there's no gameplay relevance, and I don't think it's even known if the queue exists outside of adventure.php.) That could probably be used to help handle things somehow.
 

Veracity

Developer
OK, there was already a method - AdventureRequest.parseChoiceEncounter - which decides whether you got an "Encounter" back from a choice adventure. It was called with a potentially bogus choice # - which I fixed - but there is a switch statement there for choices to exclude from being considered encounters.

I added the Florist Friar and Screwing Around! in the swimming pool and it no longer logs those as encounters or adds them to the non-cambat queue of your last location.

I just noticed that lost mentioned the fire-starting kit. I didn't fix that, so I guess I'll leave this open so that people can list other choice.php things that should be added to that switch statement.

Revision 13292.
 
Top