Bug - Fixed Loading the quest log clears ghostLocation property

Ezandora

Member
r18112
Loading "questlog.php?which=7" with an active protonic ghost quest active will not parse ghostLocation, and will also clear it if it's been set.

Reproducing (with ghost quest active):

Code:
> get ghostLocation

The Haunted Conservatory

> ashq visit_url("questlog.php?which=7")

> get ghostLocation
Actual quest log text:
Code:
<p><b>Don't be Afraid of Any Ghost</b><br> Investigate the paranormal activity reported at <A class=nounder target=mainpane href=place.php?whichplace=manor1><b>The Haunted Conservatory</b></a>.

This matcher code works fine:
Code:
if ( matcher.find() )
{
	Preferences.setString( "ghostLocation", matcher.group( 1 ) );
}
However, I believe the problem is due to this code, in QuestLogRequest.java:
Code:
private static void handleQuestText( String response, int source )
{
	if ( source == 1 )
	{
		Preferences.setString( "ghostLocation", "" );
	}
Which seems to execute after setting the ghostLocation with the matcher code above. Well, it executes three(?) times, and two of them are after ghostLocation is matched.
 

lostcalpolydude

Developer
Staff member
I expect the entire Quest Log HTML is needed here, since to me it looks like that setting should only be reset immediately before restoring it.
 

Ezandora

Member
I expect the entire Quest Log HTML is needed here, since to me it looks like that setting should only be reset immediately before restoring it.

The quest log html.

I think the bug is because the reset is in handleQuestText instead of parseResponse or somewhere else. handleQuestText is called three times - once for Council Quests:, once for Guild Quests:, and once for Other Quests:. However, only one of those has the ghostLocation match, so the other two trample over that. println log:

Code:
Parsing response:

handleQuestText for Other/Misc quests
Setting ghostLocation to ""
Setting ghostLocation to "The Spooky Forest"

handleQuestText for Council quests
Setting ghostLocation to ""

handleQuestText for Guild quests
Setting ghostLocation to ""

Parsing response core done
Other/Misc is parsed first instead of last, probably because HashMap's iteration order is not in parse order.
 

lostcalpolydude

Developer
Staff member
Other/Misc is parsed first instead of last, probably because HashMap's iteration order is not in parse order.

Weird. The key is an Integer, and I would expect that to guarantee some order (as iterator()'s documentation specifies), but I guess I don't actually understand what that means.

Regardless, 18114 clears the setting just once before doing any quest parsing.
 

heeheehee

Developer
Staff member
If you want iteration order to follow the sort order of the key, then you probably want a TreeMap. The HashMap's iteration order is arbitrary (albeit probably reproducible if dealing with a fixed internal number of buckets).
 
Top