Bug - Fixed Mafia tries to use the beer garden's crafting when it isn't there

[Theraze]

Searching for "can of Drooling Monk"...
Search complete.
Creating 1 can of Drooling Monk...
Creation failed, no results detected.

Acquire and retrieve_item will try to create the 3 new beer garden drinks when you don't actually have the garden, making it fail. The crafting method should probably only be available if it's actually available to the character.

 

[Bale]

Are you saying that purchasing hops and barley isn't enough to make "let's Brew" available? You actually need to have the garden? Please confirm that, specifically.

 

[heeheehee]

I can visit shop.php?whichshop=beergarden directly, despite having none of the ingredients.

 

[Bale]

Whelp, that means there's a different reason for the creation to fail. Theraze, did you have the ingredients in inventory?

 

[Theraze]

I was running Donavin's Omnivore script. It suggested the 3 alcohol options, which each failed to create. I tried them manually as well (create 1 can drooling monk).

Possibly a better way to describe this would be, mafia tries to use the beer garden's crafting without acquiring the necessary ingredients first? The script just does retrieve_item, which is what was failing... mafia decided that it was cheaper to craft than buy, but however it tried to craft, failed.

 

[slyz]

I tried doing "create 1 can of Drooling Monk" in the gCLI without the ingredients on hand, with r12809. Mafia visited

shop.php?whichshop=beergarden&action=buyitem&whichrow=215&quantity=1

but since it didn't try to gather ingredients first, the result was:

You don't have enough clusters of hops for that transaction

I can't look at the code now, so I don't know if it's only for BEER recipes or if there is something wrong with concoctions in general.

 

[lostcalpolydude]

Very early in CreateItemRequest.run() there should be a call to makeIngredients(), so I don't understand why that is happening.

 

[Veracity]

Very early in CreateItemRequest.run() there should be a call to makeIngredients(), so I don't understand why that is happening.

It doesn't do it if this.mixingMethod == CraftingType.SUBCLASS.
CreateitemRequest.constructInstance returns a BeerGardenRequest - a subclass - for crafting type BEER.

It meeds to do its own makeIngredients. grep for "makeIngredients" in the request directory shows this:

ChefStaffRequest.java:83:		if ( this.makeIngredients() )
CreateItemRequest.java:418:		     !this.makeIngredients() )
CreateItemRequest.java:994:	public boolean makeIngredients()
Crimbo05Request.java:64:		if ( !this.makeIngredients() )
Crimbo06Request.java:65:		if ( !this.makeIngredients() )
Crimbo07Request.java:78:		if ( !this.makeIngredients() )
Crimbo12Request.java:78:		if ( !this.makeIngredients() )
GnomeTinkerRequest.java:93:		if ( !this.makeIngredients() )
GrandmaRequest.java:65:		if ( !this.makeIngredients() )
JarlsbergRequest.java:75:		if ( !this.makeIngredients() )
KOLHSRequest.java:101:		if ( !this.makeIngredients() )
MultiUseRequest.java:93:		if ( !this.makeIngredients() )
PhineasRequest.java:80:		if ( !this.makeIngredients() )
PixelRequest.java:79:		if ( !this.makeIngredients() )
SingleUseRequest.java:107:		if ( !this.makeIngredients() )
StarChartRequest.java:80:		if ( !this.makeIngredients() )
SugarSheetRequest.java:72:		if ( !this.makeIngredients() )
SushiRequest.java:550:		if ( !this.makeIngredients() )

I think it is clear that BeerGardenRequest.run() needs that too; compare to GrandmaRequest.run().

 

[lostcalpolydude]

12846 fixes that. Now to figure out why CraftingType.SUBCLASS exists.

 

[Veracity]

If you can refactor it away and do makeIngredients for everything, go for it.

 

[Veracity]

Actually, here's a simpler first step:

Figure out if there are ANY "SUBCLASS" methods which do NOT want an automatic makeIngredients.
If none, then do makeIngredients for everything.
If there is one or two, figure out why - and figure out how to to do makeIngredients for everything except the tiny handful of exceptions, rather than every SUBCLASS, most of which do not want to be exceptions.

Looking at the list of classes from that grep that I gave you and the list of mixing types in CreateItemRequest.constructInstance that are handled by subclasses, the only one which does not do "makeIngredients" is CLIPART and ClipartRequest. No surprise, since that class creates things by summoning from a tome, rather than using ingredients, per se. Perhaps CreateItemRequest.run() should have:

		if ( this.mixingMethod != CraftingType.CLIPART &&
		     this.mixingMethod != CraftingType.ROLLING_PIN &&
		     !this.makeIngredients() )
		{
			return;
		}

instead of

		if ( this.mixingMethod != CraftingType.SUBCLASS &&
		     this.mixingMethod != CraftingType.ROLLING_PIN &&
		     !this.makeIngredients() )
		{
			return;
		}

... and all the simplification that would entail in the run() methods of the various subclasses.

Go for it.

 

[lostcalpolydude]

The harder part to get rid of SUBCLASS is understanding combineItems() compared to code that's checking responseCode (from the switch statement), and that's where I decided to leave it for another day. I think that would require taking stuff that's mixed into CreateItemRequest and moving it to new Request classes.