Feature - Implemented lunar lunch-o-mat availability

[roippi]

Right now mafia does not know if the lunar lunch-o-mat coinmaster is available. It becomes available iff the shield generator quest (questF04Elves) is finished.

-Mafia should detect the completion of that quest, and set the preference accordingly
-Concoctions should know about the availability of the lunch-o-mat
-(optional) the appropriate coinmaster gui should somehow be disabled until the quest is completed

There is also some undesirable behavior with not detecting failure to purchase an item, which I would consider a Bug:

Visiting the Lunar Lunch-o-Mat...
Lunar Lunch-o-Mat successfully looted!

> inv isotope

lunar isotope (5)

> refresh inv

Refreshing closet...
Examining consumables in closet...
Examining equipment in closet...
Examining miscellaneous items in closet...
Updating inventory...
Requests complete.

> inv isotope

lunar isotope (10)

 

[slyz]

We used to be able to buy from the lunch-o-mat regardless of the state of the quest by using directly the correct URL (we only needed the transponder effect). Apparently it was fixed on KoL's side.

 

[roippi]

Guess we can call that bit New Content then

 

[slyz]

I'll try my hand at this, it's the first time I jump into QuestDatabase.

Here is the patch I'm about to test.

 

[Bale]

You added this in r10881, right? I'm marking this implemented and hoping you don't tell me I'm wrong.

 

[slyz]

There was something else I wanted to look at - manually setting/unsetting questF04Elves to "finished" with the get CLI command doesn't have the effect I was expecting on is_accessible( $coinmaster[ Lunar Lunch-o-Mat ] ).

I also didn't check if changing the preference updated concoctions.

 

[Bale]

My bad!

 

[roippi]

There was something else I wanted to look at - manually setting/unsetting questF04Elves to "finished" with the get CLI command doesn't have the effect I was expecting on is_accessible( $coinmaster[ Lunar Lunch-o-Mat ] ).

I noticed that

 if ( Preferences.getString( QuestDatabase.GENERATOR ) != QuestDatabase.FINISHED )

checks to see if they're the same object, not the same string. Using getString().equals() would work better.

I'm not sure if that addresses the end problem, just looked through the commit real quick. Other changes look good.

 

[slyz]

I spend way more time doing stuff with ASH than with any other language, including Java

 

[slyz]

r10884

 

[Rinn]

That reminded me to submit some fixes to a few more string comparions I found with FindBugs yesterday.