Implement unregister functions in CraftingManager

[ShockedPlot7560]

Introduction

Actually, if we want to delete or replace a recipe, we have to go through Reflection.
This PR provides a means of deleting a recipe to make it disappear, or replacing it by register it immediately afterwards.

There's no need to provide any functions other than this one, as the rest does the job:

• Find a recipe from its output
• Add a recipe
• Delete a recipe (allowing replacement by combining the two)

Relevant issues

• Fixes Allow removing crafting recipes #5664

Changes

API changes

Add the following functions to the CraftingManager class:

• unregisterShapedRecipe
• unregisterShapelessRecipe
• unregisterPotionTypeRecipe
• unregisterPotionContainerChangeRecipe

Add the following function to the FurnaceRecipeManager class:

• unregister

Backwards compatibility

I didn't want to do it directly, to get an opinion, but the observers should be renamed. It now only listens to the registration but also to the deletion.

Follow-up

• Renaming observers?

Tests

Will remove all craft for Crafting table

$craftingManager = $this->getServer()->getCraftingManager();

foreach($craftingManager->matchRecipeByOutputs([
	VanillaBlocks::CRAFTING_TABLE()->asItem()
]) as $recipe){
	if($recipe instanceof ShapedRecipe){
		$craftingManager->unregisterShapedRecipe($recipe);
	}elseif($recipe instanceof ShapelessRecipe){
		$craftingManager->unregisterShapelessRecipe($recipe);
	}
}

[dktapps]

Code looks OK, although I haven't tested this myself.

[dktapps]

Things to watch out for:

• This code permits recipes to be unregistered at runtime. This might be fine, but we need to make sure that looking up a recipe that's been unregistered doesn't cause anything to crash (e.g. ItemStackRequest).
• Recipe net ID generation in CraftingDataCache must continue to use the existing keys. The existing keys of the index must not be changed by any recipe being unregistered.

[ShockedPlot7560]

Does this PR require any further development action or is it just testing?

[dktapps]

no, I think the PR code is probably okay.

[ShockedPlot7560]

Fixed #5286

[dktapps]

The code in the PR looks functional.

The thing I'm dubious about is that this code expects plugin devs will have to get the exact instance of the recipe they want to unregister, in order to unregister it. I'm not sure this is the best way to go about it.

May well result in some painful headaches if someone does something like this:

$craftingManager->unregisterShapedRecipe(new ShapedRecipe(
    [
        "WWW",
        "W W",
        "WWW",
    ],
    [
        "W" => new ExactRecipeIngredient(VanillaBlocks::OAK_PLANKS()->asItem()),
    ],
    [VanillaBlocks::CHEST()->asItem()]
));

This code looks fine, but it would not produce the intended result.

Basically, I think we need a better way to compare recipes before implementing this.

[ShockedPlot7560]

For me, this is blocked until we find a way to compare recipes (probably in an other Pr, this is why I labelled this one as blocked).

[ShockedPlot7560]

@dktapps I've implemented a new way to compare ShapelessRecipes (for the moment) to make the unregister function accurate. Do we follow the same for others recipes or another system need to be found.

[dktapps]

@dktapps I've implemented a new way to compare ShapelessRecipes (for the moment) to make the unregister function accurate. Do we follow the same for others recipes or another system need to be found.

Not sure. I'll have to dig into the shapeless logic a bit further, but I'm hoping there's a way to simplify this.

I really don't like using __toString() for the RecipeIngredient comparisons though...

[ShockedPlot7560]

For RecipeIngredient, this is the only solution i've found to limit BC breaking. Probably, it's not possible and we need to enforce a new method into this interface to force developpers to provide a way of comparison.

[dktapps]

I don't think it's reliable for custom recipe types. Best we push this back until PM6 if that's going to be a problem.

[ShockedPlot7560]

Sadly it will be the solution, I don't see a better way to do it without breaking BC.

The base branch was changed.

[ShockedPlot7560]

We could probably say that in pm6, we are introducing a new method in the ingredient interface to allow two recipes to be compared with each other? This remove the use of __toString