GT++ Multiblocks

Introduction
Around EV/IV tier, a player will suddenly have access to GT++ multiblocks. These multiblocks 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 (200% faster, 100% eu/t, 2 operations per tier; this multi will work with a GT++ version newer than 1.7.02.02-fresh)

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.

Many GT++ multiblocks also create pollution, usually stated on the controller block.

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).
 * Some multiblocks require a very specific location for their maintenance hatches.
 * Most GT++ multiblocks need muffler hatches now
 * Some multiblocks have multiple modes, that replace different GT machines. You can see this in the NEI description under Machine Type. They can be cycled by using a screwdriver on the controller. In case of the Large Processing Factory you also need a numbered circuits in the input busses to select the mode for that specific bus.

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 64 operations 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.

How to Get More Performance
Just like a PA can be optimized to use all of its input voltage (via higher tier machines), so can a GT++ multiblock.

Here's an example:

Ore processing is 2 eu/t at 20s.

The maceration stack is 60% faster, no eu discount, 8 operations per tier.

Let's say we have an HV maceration stack. This means it will do 24 operations simulaneously with a base recipe of: 48 eu/t at 12.5s, mv tier 192 eu/t at 6.25, hv tier

So it does 24 operations every 6.25s or 3.84 ores/s.

You'll notice it only eats 192 eu/t, far from the given input of 512 eu/t. We can actually make it eat more voltage at HV tier by doing the following:

Instead of feeding the maceration stack 24 ores, feed it 16 ores. This will make it so the base recipe is now:

32 eu/t at 12.5s, lv tier 128 eu/t at 6.25s, mv tier 512 eu/t at 3.125s, hv tier

So it does 16 operations every 3.125s or 5.12 ores/s.

If you noticed, I forced the base recipe to be 1 tier lower than usual by lowering the amount of items I fed it. This forced an additional overclock, making it faster than the "default" HV rate.

This is actually possible to do right now. By rate limiting the amount of input your GT++ machines take (via something like SFM), the GT++ multi can make the most out of your amp.

This is based off the idea that: if the number of parallel operations at your current tier is not DOUBLE the previous tier's number of parallel operations, then it's better to force a GT overclock (via underfeeding) from the previous tier rather than use the increased number of parallel operations at your current tier (since, in general for all gt++ machines, the number of parallel operations per tier increases linearly not exponentially, so you'll run into this case quite often for almost all the machines)