GT++ Multiblocks

Introduction

GT++ introduces a vast number of new multiblocks that functionally act as a more efficient version of their single-block counterpart. As of GT:NH 2.0.4.6, there are the following multiblocks:

• Industrial Centrifuge (125% faster, 90% eu/t, 6 operations per tier)
• Industrial Material Press (500% faster, 100% eu/t, 4 operations per tier)
• Industrial Electrolyzer (180% faster, 90% eu/t, 2 operations per tier)
• Industrial Mixing Machine (250% faster, 100% eu/t, 8 operations per tier)
• Industrial Sifter (400% faster, 75% eu/t, 4 operations per tier)
• Industrial Thermal Centrifuge (150% faster, 80% eu/t, 8 operations per tier)
• Industrial Ore Washing Plant (400% faster, 100% eu/t, 4 operations per tier)
• Industrial Extrusion Machine (250% faster, 100% eu/t, 4 operations per tier)
• Industrial Cutting Factory (200% faster, 75% eu/t, 4 operations per tier)
• Large Processing Factory (250% faster, 80% eu/t, 2 operations per tier)
• Maceration Stack Controller (60% faster, 100% eu/t, 8 operations per tier)
• Wire Factory Controller (200% faster, 75% eu/t, 4 operations per tier)
• Amazon Warehousing Depot (???% faster, 75% eu/t, 5 operations per tier)
• Cryogenic Freezer (100% faster, 100% eu/t, 4 operations at all tiers)
• Advanced EBF
• Advanced Implosion Compressor
• Zhuhai Fishing Port
• Large Scale Auto-Assembler (currently broken)

Note that this is not a complete list of GT++ multiblocks. This is a list of those multiblocks that exist to be a better version of either their singleblock counterpart, or their normal Gregtrech multiblock counterpart.

How to Build

Every multiblock has their own strict set of construction rules described in the controller block. Some key things to note are:

• A large ore washer requires water in its input hatch (this will physically fill the ore washer with water).
• An industrial extruder cannot have buses/hatches in the edge casings.
• Some multiblocks require a very specific location for their maintenance hatches.

Multiblock Calculations

The aforementioned list of GT++ multi's have their own speed bonus, eu discount, and number of parallel operations per Gregtech voltage tier. Here is an incredibly informal explanation of how exactly the multiblock logic works (from https://github.com/draknyte1/GTplusplus/wiki/Multiblock-Processing-Logic):

GT++ machines can have EU_DISCOUNT ("only uses x% of the eu/t normally required"), MAX_PARALLEL ([your tier] * [# parallel items per tier]), and SPEED_BOOST ("x% faster than using single block blah blah").

First, apply EU_DISCOUNT to the recipe's EU/t value. Call this value x.

Second, calculate xy, respecting these two conditions:
  -y is, at most, MAX_PARALLEL
  -xy must be less than the input voltage of your machine

Let's call xy, TOTAL_EU_PER_TICK.

Third, apply SPEED_BOOST to your recipe's time. In this code, if something says "x% faster", we mean multiply the recipe time by 100/(x+100). Let's call the new recipe time, NEW_RECIPE_TIME.
 
Assuming a new recipe EU/t value of TOTAL_EU_PER_TICK, try to GT overclock as many times as you can, starting from a base recipe time of NEW_RECIPE_TIME. The resulting EU/t and time taken are what is reported by a scanner. Another important thing to note is that recipe times cannot be reduced below 1 second after all of this logic. If a resulting recipe time goes below 1 second, it gets set to be 1 second.

Here's an example:

A Large Thermal Centrifuge has: 80% eu discount, 8 items per tier, and 150% faster. 

You are doing a recipe that is 48 EU/t and 25 seconds long, at UV tier.

So we have MAX_PARALLEL = 64, EU_DISCOUNT = 0.8, SPEED_BOOST = 0.4
x = 38.4 eu/t
y = MAX_PARALLEL in our case, so x * y = 2457.6 eu/t
NEW_RECIPE_TIME = 25 * 0.4 = 10 seconds, TOTAL_EU_PER_TICK = 2457.6 eu/t
Now, we GT overclock from these base numbers as many times as possible:
9830.4 eu/t, 5 seconds, LuV tier
39321.6 eu/t, 2.5 seconds, ZPM tier
157286.4 eu/t, 1.25 seconds, UV tier

So the large thermal centrifuge should do 64 operations every 1.25 seconds at 157286.4 EU/t at UV-tier

Comparison to a Processing Array

When comparing to a processing array, the most important thing to take away from the GT++ multiblock algorithm is that a recipe time cannot be reduced below 1 second. This means that when looking at a graph of Operations per second vs Gregtech Tier, a GT++ multiblock will inevitably flatline. On the other hand, a Gregtech Processing Array has no such restriction and can theoretically work even faster than a GT++ multiblock. However, this only really happens when a player is at or above ZPM tier (it's actually difficult to pinpoint where exactly this breakoff point is due to the variability of recipe times and eu costs, as well as the different speed bonuses, eu discounts, and parallel operations that differs from multiblock to multiblock).

For example, let's compare a maceration stack to a PA full of pulverizers. A standard ore pulverization recipe is 2 eu/t at 20 seconds per operation. A UV-tier maceration stack will get GT++ boosted to have a recipe cost of 128 eu/t and base time of 12.5 seconds. This means at UV-tier, at best, it will GT overclock to 64 ores per second. This is because the recipe time cannot be reduced below 1 second. Note that if the 1 second recipe time limit were not in place, the UV maceration stack would be doing an operation every 0.1953125 seconds, which would be equivalent to 327.68 ores per second.

A ZPM-tier PA can hold 64 LuV-tier pulverizers. This is because the eu cost of pulverizing ores is 2 eu/t. This means that it can do 64 ores every 0.625 seconds, or 102.4 ores per second.

The result is that a ZPM-tier PA can give a faster operation rate than a UV-tier maceration stack. Similar results will inevitably happen to all other GT++ multiblock vs PA comparisons.

Around the time a player unlocks the GT++ multiblocks, it is in his or her favor to build one of these multiblocks because of their spike in efficiency and speed compared to PA's around the IV/LuV tiers. Once a player hits ZPM or UV, however, it might be better to recalculate their desired operations per second because it might be more space and power efficient to switch over to a PA.