Delete ThreadedSuperBuffer

[D-Cysteine]

Discussion thread: GTNewHorizons/GT-New-Horizons-Modpack#8324

Changes:

• GT++ threaded Super Buffer code deleted
• Existing threaded Super Buffers will be replaced by a copy of the regular GT Super Buffer, but still with the GT++ metadata ID
  • This should prevent bases from being broken by the change. I checked that Super Buffer inventory is preserved, and I think even the NBT data (redstone settings, stack size, etc.) should be preserved.
  • These items have a deprecation notice added to their name
• Pulverizer recipe added to let players convert these Super Buffers with the wrong metadata ID, back into Super Buffers with the correct GT metadata ID. These recipes will also refund the data orb and conveyor belt that were previously used to craft the GT++ Super Buffer.

I wasn't able to get automatic metadata ID updating to work, so players will need to manually update all of their threaded super buffers. Let me know if you have any better ideas on how to do this!

[TimeConqueror]

Code is good. If it was tested, then ok.

One thing: why pulverizer? Doesn't it break the logic? Maybe Assembler?

[Dream-Master]

Indeed assembler sound more logical. In the pulverizer you never get back whole parts @D-Cysteine

[D-Cysteine]

I just picked it because it was easy to add a recipe for, and it met these criteria:

• Enough output slots to hold all the recipe outputs
• It's a common machine that everyone will have

Agreed that thematically, other machines like the assembler would make more sense for a recipe of this type. The assembler only has one output slot, though, so using it would result in losing the data orb and conveyor belt (in which case may as well just make it a hand-crafting recipe).

I looked around at the other machines, and unfortunately, very few seem to have 3 output slots. The only one I found that had enough slots and made sense was the disassembler, but unfortunately it looks like the disassembler has some hard-coded logic which:

• Sets recipe duration to (I think) 30 sec, which is kind of long for something like this
• Prevents inputs containing machines of higher tiers from working. So if you want to reclaim a LuV super buffer, you need a LuV or better disassembler.

So unless I missed a machine with enough output slots (which is very possible), I think we have to choose between using a non-thematic machine, losing some output ingredients, or using the tier-gated and slow disassembler. Which of these would be preferred?

[Dream-Master]

@D-Cysteine that is true. Maybe we need to add some kind of dissasembler device with more outputs, Not sure if we can add recipes to the dissasembler.

[repo-alt]

Why not just add shapeless recipe converting GT++ super buffer to GT one?

[Glease]

I wasn't able to get automatic metadata ID updating to work

What did you tried? I want to have a look at it for fun, but don't want to repeat a failure that can be avoided.

[D-Cysteine]

@D-Cysteine that is true. Maybe we need to add some kind of dissasembler device with more outputs, Not sure if we can add recipes to the dissasembler.

We can add custom recipes to the disassembler, but they are subject to the same hard-coded restrictions: duration set to 30 sec (reduced by OC I think), and the input cannot be of a higher tier than the disassembler. I'm checking if I can add in a way to bypass these restrictions for custom recipes.

Why not just add shapeless recipe converting GT++ super buffer to GT one?

It's one possible solution, but we won't be able to return all ingredients back to the player in this case. The original recipe is (data orb + GT super buffer + conveyor belt) = GT++ super buffer, so we need something that supports 3 outputs to give everything back.

What did you tried? I want to have a look at it for fun, but don't want to repeat a failure that can be avoided.

I tried two things:

1. Modifying the GT++ super buffer's newMetaEntity() method to return an instance of the GT super buffer instead
2. Setting GregTech_API.METATILEENTITIES[<GT++ super buffer ID>] = ItemList.<GT super buffer>

though it's definitely possible that I made a mistake when trying the above. I have one more idea that I didn't try, which is using World.setBlock() to have the GT++ super buffer forcibly replace itself with the GT one. This approach does mean that we'd need to copy over the inventory and other state (like selected stack size) to the new machine ourselves, and by default, the other ingredients (data orb, conveyor belt) will be lost. But if we did this in onWrenchRightClick() or something else player-triggered, then we could return those ingredients by dropping in the world or something.

[D-Cysteine]

I got the disassembler restrictions bypass working:

• Add disassembler restrictions bypass GT5-Unofficial#626

This PR has been updated to use the disassembler instead of the pulverizer.