Issue Description

Weighted output functions can be circumvented by "Q drop crafting"

What Happens

Assuming a recipe such as this, by pressing Q (or drop) on the recipe output, you would always get the first result, ignoring any weights.

RecipeBuilder.get("basic")
  .setShapeless([<minecraft:iron_ingot>])
  .addTool(<ore:artisansBurner>, 10)
  .addOutput(<minecraft:iron_ingot>.withTag({Worked: 10}), 25)
  .addOutput(<minecraft:iron_ingot>.withTag({Worked: 15}), 25)
  .addOutput(<minecraft:iron_ingot>.withTag({Worked: 20}), 50)
  .create();

With a recipe like this one instead, the result of Q crafting would always be just 1 item from the first result, no matter how many is specified.

RecipeBuilder.get("basic")
  .setShapeless([<minecraft:bone>])
  .addTool(<ore:artisansHammer>, 10)
  .addOutput(<minecraft:dye:15> * 2, 25)
  .addOutput(<minecraft:dye:15> * 3, 25)
  .addOutput(<minecraft:dye:15> * 4, 50)
  .create();

What You Expect to Happen

Either using Q to craft should be disabled entirely, or the result should still pull from the weighted options.

Affected Versions

• Minecraft: 1.12.2
• Forge: 14.23.5.2844
• CraftTweaker: 2-1.12-4.1.19
• Artisan Worktables: 1.12.2-1.21.7
• Athenaeum: 1.12.2-1.17.3

Addendum: I also have the following mods that may be relevant, but I just tested that the issue does still occur without either of them.

• InventoryTweaks-1.63.jar
• MouseTweaks-2.10-mc1.12.2.jar

If the table supports vanilla crafting, it will match against a vanilla recipe (ie. bone to bonemeal) first, before matching any custom AW recipes added via CrT. I noticed this when testing with the second recipe provided because I changed the dye colors and couldn't get it to use the CrT recipe over the vanilla recipe.

After disabling vanilla recipes for the table used, I am able to reproduce this.

Oh right, this was the version right before vanilla crafting was introduced