GTNewHorizons / GT-New-Horizons-Modpack

New Modpack with Gregtech, Thaumcraft and Witchery
https://www.gtnewhorizons.com/
Other
948 stars 296 forks source link

Planet Cyclone Multiblock (Planet Stone Dust Overhaul Part 1) - Bartworks Multiblock Addition #4890

Closed ScriptedPiky closed 3 years ago

ScriptedPiky commented 5 years ago

As of right now, planet stone dusts are in a particularly strange spot of either being entirely pointless to go for or a necessity at very specific moments in one's base developments for one or fewer materials or fluids/gases. Some of them are also generally more tedious to obtain and require far more waiting to acquire even the tiniest amounts of resources.

In order to combat this issue, I present the Planet Cyclone multiblock that we may use to help rework the entire Planet Stone Dust issue. First off, let us discuss the overall general idea of this.

Planet Cyclone (New multiblock)

The Planet Cyclone is a new addition of a multiblock that takes the role of consuming planet stones to gather outputs far greater than the previous outcome of using a centrifuging process. Taking a rather meticulous process. Up to 16 dusts per output and perhaps 1-3 or even 4 liquid outputs maximum. It is a 7x5x7 multiblock, hollow except for the 4 pillars 3 block tall pillars; 1 block off from each other within near the center. Please see screenshot below to understand the concept of the building structure.

Now the processing concepts & scaling.

Pictured recipes of each one in order in terms of casings & controller recipes, as well as the structure of how it may look.

Structure of the multiblocks (casings are meant to show progression, not as a final product). In order from left to right: Tier 1 EV or higher glass (reinforced glass counts as EV and may be used instead of the Borosilicate Glass), Tier 2 LuV or higher glass, Tier 3 UV glass. Please note that the minimum glass tier is required and only affects the multiblock structure, not the processing recipes 2019-07-30_17 55 18

Mountainous Separator Controller recipe. In order: 1 EV Centrifuge, 2 EV Emitters, 2 EV Sensors, 8 EV Superconductor Wires, 16 Small Titanium Gears, 4 Long Titanium Rods, 4 EV Pumps, 1 60k He Coolant Cell, 4 Data Orbs, and 16 Soldering Alloy in fluid (2304L). EV voltage, 60-second process. Cyclone1

Reinforced Prototype Space Casing recipe. In order: 1 Titanium Frame Box, 4 Long Vibrant Alloy Rods, 8 Yttrium Rings, 16 Magnetic Neodymium Bolts, 4 Titanium Gears, 6 Niobium-Titanium Plates, and 8 Lead in fluid (1152L). EV voltage, 10-second process. CycloneCasing1

Spiral Extractinator recipe. In order: 1 Titanium Frame Box, 4 Long Tungstensteel Rods, 16 Yttrium Rings, 8 Tungstensteel Rotors, 16 Tungsten Steel Bolts, 12 Double Niobium-Titanium Plates, and 12 HSLA Steel in fluid (1728L). EV voltage, 30-second process. CycloneRotor1

Continent Cracker Controller recipe. In order: 1 LuV Centrifuge, 2 LuV Emitters, 2 LuV Sensors, 8 2x LuV Superconductor Wires, 8 Osmiridium Gears, 32 Small Iridium Gears, 16 Long Osmiridium Rods, 8 LuV Pumps, 1 360k He Coolant Cell, 16 Data Orbs, and 12 Double Oriharukon Plates. 32 Soldering Alloy in fluid (4608L), 8000L of Lubricant, 12000L of Helium. Assembly Line recipe, LuV voltage, 120-second process. Cyclone2

Exotic Galatic Casing recipe. In order: 1 Osmiridium Frame Box, 12 Long Duranium Rods, 24 Trinium Rings, 6 Magnetic Samarium Rods, 8 Osmiridium Gears, 24 Osmiridium Screws, and 24 Oriharukon Foil. 12 Lead and Oriharukon in fluid (1728L and 1728L), 4000L of Lubricant. Assembly Line recipe, LuV voltage, 15-second process. CycloneCasing2

Exotic & Amplified Separator recipe. In order: 1 Osmiridium Frame Box, 16 Osmiridium Long Rods, 32 Trinium Rings, 16 Trinium Rotors, 8 LuV Motors, 2 IV Field Generators, 32 Osmiridium Screws, Small Oriharukon Springs, and 64 Oriharukon Foil. 24 HSLA Steel and 24 Soldering Alloy in fluid (3456L and 3456L). Assembly Line recipe, LuV voltage, 60-second process. CycloneRotor2

Planetary Cyclone Controller recipe. In order: 1 UV Centrifuge, 4 UV Emitters, 4 UV Sensors, 16 4x UV Superconductor Wires, 16 Neutronium Gears, 64 Small Naquadah Alloy Gears, 64 Long Neutronium Rods, 16 UV Pumps, 4 separate 360k He Coolant Cells, 64 Data Orbs, 1 UV Field Generator, and 8 Dense Neutronium Plates. 18 Blocks of Soldering in fluid (216 ingots or 31104L), 24000L Lubricant, 64000 Helium. Assembly Line recipe, UV voltage, 360-second process. Cyclone3

Spatial Quantum Casing recipe. In order: 1 Neutronium Frame Box, 24 Tritanium Rods, 64 Trinium Rings, 12 Magnetic Samarium Rods, 16 Naquadah Alloy Gears, 48 Naquadah Alloy Screws, and 64 Adamantium Foil. 24 Adamantium and 48 Orihakuron in fluid (3456L and 6912L). 20000L Lubricant. Assembly Line Recipe, UV voltage, 30-second process. CycloneCasing3

Gravitational Void Anomaly recipe. In order: 1 Neutronium Frame Box, 32 Long Neutronium Rods, 64 Naquadah Alloy Rings, 16 Naquadah Alloy Turbine Blades, 16 UV Motors, 4 ZPM Field Generators, 64 Naquadah Alloy Screws, 64 Adamantium Springs, and 64 Adamantium Foils. 12 Blocks of HSLA and 12 Blocks of Soldering Alloy and 40 Adamantium in fluid (108 ingots both or 15552L and 15552L and 5760L). Assembly Line Process CycloneRotor3

So, what are your overall thoughts on this? Is the cost worth it compared to the guaranteed drop probability for dusts as well as the increased parallel processing per increased voltage tier and upgraded multiblocks? Are the benefits far greater than they should be? Should there be any adjustments?

I dearly hope that you read through, and please put your comments & thoughts down below.

noobyaran9 commented 5 years ago

100% output might not be the best idea for the outputs. I would suggest have it like 50%/25%/12.5%/6.25%/3.125% and etc for each of the outputs from the dust. So it wouldn't break the balance for the rarer output from the dust.

ScriptedPiky commented 5 years ago

100% output might not be the best idea for the outputs. I would suggest have it like 50%/25%/12.5%/6.25%/3.125% and etc for each of the outputs from the dust. So it wouldn't broke the balance for the rarer output from the dust.

The overall idea for the multiblock was to have a specific static time (in this case, Moon dust with 60-second requirement) that cannot have its time be reduced or overclocked by upvolting or upgrading tiers. However, it will offer a guaranteed drop for those specific dusts or items. I do see the potential balance-breaking issues involving the 100% drop chance though. Although, balancing around time values might solve this issue in some capacity. I may tinker around with certain drop chances not always being 100% to drop and perhaps lower their chances if they may become an issue when I begin to balance out the real planet stone dusts.

ghost commented 5 years ago

I think this might be a good change, but I think another major problem, which contributes with planet dusts' uselessness is the inability to easily automatically mine them before fusion tier. While ores have the drilling rigs and miners, the only early option I'm aware of for planet stones is robots. I'd prefer to see a simple planet stone miner (possibly like a bedrock miner type of thing?) added and some buffs to the centrifuge recipes before adding new multis and totally revamping the system. However if these multis are all fully balanced with appropriate recipes for centrifuging the planet stones then I would be happy with this change as well.

On the topic of the multis themselves, I think that if the planet stone recipes remain similar (i.e., 1a per recipe), then having the top 2 tiers do 12 and 32 items per tier parallel essentially just means that they can perfectly overclock almost as much as you want, because you are very unlikely to reach that limit. With a LuV energy hatch on the LuV multi, 12 items per tier means it can do 72 recipes in parallel. Only when centrifuging the HV dusts would you even be able to reach that cap with your power input, and presumably the HV tier dusts would be much less relevant by LuV so you would never hit the cap. I would suggest not using the different multi tiers for different parallel processing values but rather for some other purpose, such as gating higher tier planet stones to be only processed with the higher tier multi.

Also, if you could make those things suck up large amounts of acids and stuff to run that would be cool thematically and for gameplay. Could even add a use for some of the ignored fluids like phosphoric acid, although that might not be too realistic so maybe stick to sulfuric/nitric/etc.

repo-alt commented 5 years ago

While ores have the drilling rigs and miners, the only early option I'm aware of for planet stones is robots.

You can use ic2 advanced miner to excavate anything.

boubou19 commented 5 years ago

So if those multiblocks will added, will the regular stone dusts' recipes remain in the single block centrifuge? I mean the player could have two choices: 1) use regular recipes in the centrifuge and will have very low chances of getting the rarer dusts 2) make the multiblocks and have 100% of the output

Bluebine commented 5 years ago

Sounds really cool! I think it would also help get around the problem of renewable planet stone- you can easily just mine a few thousand, and it'll last a long while because you'd get so much from one stone. Also, should probably gate the planet stone processing by their tier- T1-3 stone can be done in any tier of multiblock, T4-5 need the second one, T6-8 need the final one.

richardhendricks commented 5 years ago

@repo-alt What tier is the Advanced Miner in GTNH?

botn365 commented 5 years ago

advacend miner is LuV

0lafe commented 5 years ago

I'm confused why it's broken into 3 tiers instead of scaling stone dust with rocket tier, and requiring the right glass tier for that. HV for moon, EV for Mars shits, etc.

Also, simply changing it so it does 100% outputs seems like a terrible idea. Planet stone as it is has some use, increasing some of the outputs to 100% would make it a god tier mat gen for things like Os/Ir/IC/D*/SpNt/naquadria. Probably more but that's what I remember off the top of my head, not including the other resources you'd be generating from each tier of stone.

You can gen planet stone kind of early. Aren't there planet stone bees? But also you can auto mine planets using RC, OC, AE, and probably some other things. If it's 100% drops, mining manually would also be incredible. Using a hammer with some haste you'd be getting 9 ingots of 6 mats every click pretty much, in terms of planet stone. Do that for like a min and you'll have thousands of tier mats.

Imo, the best thing it should do is perfect overclock, either through parallel or speed, doesnt matter too much. If you want it for planet stone, remove the centrifuge recipes and put them in this instead. However, this is kind of a boring solution to planet stone. It keeps it as a 1 step process, while slightly raising the startup cost, and significantly reducing the power per output. Look at the rates of the drops of things atm, and change the %s to make them useful, then make the recipes use this multi instead of a centrifuge. The usefulness of the dusts is almost not tied to this machine, you're really just dealing with the % outputs.

What other outputs do you intend to add for each tier?

noobyaran9 commented 5 years ago

Also, simply changing it so it does 100% outputs seems like a terrible idea. Planet stone as it is has some use, increasing some of the outputs to 100% would make it a god tier mat gen for things like Os/Ir/IC/D*/SpNt/naquadria. Probably more but that's what I remember off the top of my head, not including the other resources you'd be generating from each tier of stone.

The original outputs of the planet dust will be rework-ed so it doesn't give something out of tier.

You can gen planet stone kind of early. Aren't there planet stone bees? But also you can auto mine planets using RC, OC, AE, and probably some other things. If it's 100% drops, mining manually would also be incredible. Using a hammer with some haste you'd be getting 9 ingots of 6 mats every click pretty much, in terms of planet stone. Do that for like a min and you'll have thousands of tier mats.

Have u considered the processing time for those material? And I believe the output will be changed such that it only gives tiny piles or small piles instead of full dust. Auto mining of sorts is quite late into the game which itself is already not a problem. Stone bees are also out of question, they're so hard to get and you don't really get a large amount of stone dust from them, unless u do WA on quite a few bees.

Imo, the best thing it should do is perfect overclock, either through parallel or speed, doesnt matter too much. If you want it for planet stone, remove the centrifuge recipes and put them in this instead. However, this is kind of a boring solution to planet stone. It keeps it as a 1 step process, while slightly raising the startup cost, and significantly reducing the power per output. Look at the rates of the drops of things atm, and change the %s to make them useful, then make the recipes use this multi instead of a centrifuge. The usefulness of the dusts is almost not tied to this machine, you're really just dealing with the % outputs.

I wouldn't mind it being a multi-step process. However, i'm totally against it if the process before the dust is passed into the machine takes like hundreds of seconds just to process a single dust, while the machine can process a stack within 1 minute. And the machine will be designed in such a way that is similar to assembly line, which is hard and complex to obtain and giving use to some of the un-used or rarely used material. Basically, you have an upfront cost for this multiblock and it will reward you by giving you a decent resource output from the multi.

You won't be able to skip tier with this machine and at the same time gives u a supplement of resources from the basically useless planet dust ATM.

0lafe commented 5 years ago

The original outputs of the planet dust will be rework-ed so it doesn't give something out of tier.

Gonna have to see what it gives, but even in tier options would be OP here.

Basically, you have an upfront cost for this multiblock and it will reward you by giving you a decent resource output from the multi.

You won't be able to skip tier with this machine and at the same time gives u a supplement of resources from the basically useless planet dust ATM.

It seems like you give a fairly small upfront cost, and it gives you quite a lot of output. Granted I'll need to know what items/% get choosen, but something dropping a bunch of tier mats at a really fast rate doesn't at all sound like a good idea. Seems like just a super easy way to do no setup and use a little power to make all your resources.

observeroftime02 commented 5 years ago

How about a rotor in there somewhere with a durability so it's not just "build it and never worry about maintaining it again"?

Seeing how it's some type of a cyclone vortex, I think adding a turbine would even make sense, thematically. Turbine stats and efficiency could also factor into outputs somehow, maybe. Don't know if this is a good idea at all, but might be worth a thought.

0lafe commented 5 years ago

Turbine count determines max parallel ;D overclocks as it can otherwise?

ScriptedPiky commented 5 years ago

How about a rotor in there somewhere with a durability so it's not just "build it and never worry about maintaining it again"?

Seeing how it's some type of a cyclone vortex, I think adding a turbine would even make sense, thematically. Turbine stats and efficiency could also factor into outputs somehow, maybe. Don't know if this is a good idea at all, but might be worth a thought.

Turbine count determines max parallel ;D overclocks as it can otherwise?

That sounds like an incredibly fun concept idea to work around with. Hmm, just had a thought. Assuming that overclock works normally (50% time reduction, 4x energy), would a turbine add more benefit or add just pure benefit to the output chance? Turbine stats could factor into a multiple of things. Where efficiency could increase the probability of obtaining something. Durability depends on how long the turbine will last of course. Small, Medium, Large, or Huge could determine the amount of parallelization? Or could efficiency also determine parallelization? I am unsure whether or not the separate multiblocks could come into effect. But let's assume that the multiblocks offer no increased parallel and that we're starting with quite literally a regular multi with no special things yet. Should there be only 1 multiblock or 2 other multiblocks that have slightly better advantages?

observeroftime02 commented 5 years ago

If the controller somehow functioned like a turbine where you put a turbine In the Gui and it takes damage over time as the block is running this could be a cool idea. Let's see, turbines have tiers associated with them (depending on material) , as well as efficiency (based on material and size). Maybe that could be worked with somehow, though I'm not sure how exactly.

It would mean the block has a concrete running cost associated with it. Maybe not all materials could work, and only specific ones (depending on tier). It would allow for a finer controll over what materials can be processed and what the outputs are like.

ScriptedPiky commented 5 years ago

That idea I greatly enjoy. Although, having the controller GUI required for the input slot for the turbines might have some side effects, mostly no automation involved with controllers through normal means such as conveyors, pipes or the alike (unless that is possible to code in). But yeah, those ideas are excellent.

noobyaran9 commented 5 years ago

Small, Medium, Large, or Huge

Maybe this can determine the amount of parallelization.

Efficiency

This could probably affect the chance for item drops or even affect the recipe time. Recipe time formula: (60second / efficiency^2) or something else OR Item drop chance formulae: (percentage / efficiency^2) or something else

overclocks as it can otherwise?

Strictly no overclock.

It seems like you give a fairly small upfront cost, and it gives you quite a lot of output.

Depends on how u define "fairly small". The output starts to ramp up when you start able to automine. Normal mining won't get you as much.

Should there be only 1 multiblock or 2 other multiblocks that have slightly better advantages?

Maybe all 3 multiblock can exist, but they process different tiers of planet dust and possibly we can use the 3 tiers to buff the drop chance of the previous tiers multiblock.

0lafe commented 5 years ago

I'm still on board with tiering recipes mostly with glass tier, so less need for more than 1. The more multis the better cost wise, as glass tiers aren't much compared to making a new multi.

For turbines I more mean the # of them you input into the multi is the parallel count. Eff could do output buffs, or reduction of recipe times if you want to keep the stone:output ratio constant and only give eff to power instead of both. Tiering through turbine mats could work, but idk.

Relating parallel to rotor quantity (rotor#), Output boost being efficiency (default*efficiency%?), and throughput being flow rate? Could be some type of tiering to the flowrate then corollate that to the speed of the recipe. I'm not sure how they scale with speed or w/e, but could be like (√speed)/4 or something. Would make If type stuff a little over 2x speed, while most earlier things would give bonuses mostly bound by 1-2. Considering size plays into flowrate, with flowrate also including mat choice, I think it'd be better for determining speed than a flat parallel bonus to size.

Strictly no overclock.

Any reason or do you just hate it? Lol. You'd never overclock if you max turbines, but it would help for making lower tier recipes more viable later on. If parallel is locked to turbines, it'll max, giving each planet stone a max input tier. Seems a little weird.

Depends on how u define "fairly small". The output starts to ramp up when you start able to automine. Normal mining won't get you as much.

If it's small or full dusts, it's kind of a lot at a 1:1 from stone dust. Even manually mining, getting tens of thousands of dusts would be fast enough by planet tiers. Not to mention, you can automine by space tiers. The quarry isn't the only option.

Also by small I mean the setup cost for the multi isn't a lot, if you're gonna be getting the resources used to make it back in a short time frame. All depends on what the outputs and %s I guess.

Stone bees are also out of question, they're so hard to get and you don't really get a large amount of stone dust from them, unless u do WA on quite a few bees.

So unless you make a bee setup lol. Can't you max bees to give you at least a couple dust/min without much difficulty? If you're only processing 1 per voltage tier, that's not much input needed.

noobyaran9 commented 5 years ago

For turbines I more mean the # of them you input into the multi is the parallel count. Eff could do output buffs, or reduction of recipe times if you want to keep the stone:output ratio constant and only give eff to power instead of both. Tiering through turbine mats could work, but idk.

I still think tiering the parallelization through the small/medium/large/huge variant is better as each variant of rotor have their own gate. As i proposed here?

This could probably affect the chance for item drops or even affect the recipe time. Recipe time formula: (60second / efficiency^2) or something else OR Item drop chance formulae: (percentage / efficiency^2) or something else

Any reason or do you just hate it? Lol. You'd never overclock if you max turbines, but it would help for making lower tier recipes more viable later on. If parallel is locked to turbines, it'll max, giving each planet stone a max input tier. Seems a little weird.

Overclocking would make this multiblock too powerful especially with the parallelization that we're going to give it. Locking the recipe time 60s seem to make alot of sense. What do you mean by it'll max? Assuming using a huge rotor gives the multiblock a 16x parallel per tier difference. Moon dust is EV(i think) at UHV, it will only process 16*6 which is less than 2 stacks. And the multi block still eats 1 amps of UHV ignoring how many process it is doing. This gives a heavy cost on energy usage to the machine.

If it's small or full dusts, it's kind of a lot at a 1:1 from stone dust. Even manually mining, getting tens of thousands of dusts would be fast enough by planet tiers. Not to mention, you can automine by space tiers. The quarry isn't the only option.

This is why I question you, have u actually considered the cost on running the multiblock? and how much would the multiblock outputs per hour with the amount of parallelization.

Also by small I mean the setup cost for the multi isn't a lot, if you're gonna be getting the resources used to make it back in a short time frame. All depends on what the outputs and %s I guess.

We could tweak the recipes of the casing cost to make them very expensive and possibly very complex to make to give it a high up front cost.

So unless you make a bee setup lol. Can't you max bees to give you at least a couple dust/min without much difficulty? If you're only processing 1 per voltage tier, that's not much input needed.

Bees are not meant to be a source, they're just a supplement. In order to keep up the amount that the multiblock process, the only viable option is to automine or have a really huge bee setup that could possibly impact server performance.

0lafe commented 5 years ago

I still think tiering the parallelization through the small/medium/large/huge variant is better as each variant of rotor have their own gate. As i proposed here?

It means that all turbines of the same size will give the same throughput, which is weird as they don't have that in any other scenario. Also means pretty much anything with the same eff will give the same running effects, really just giving a slightly fluctuating rod costs for continuous running.

Overclocking would make this multiblock too powerful especially with the parallelization that we're going to give it. Locking the recipe time 60s seem to make alot of sense. What do you mean by it'll max? Assuming using a huge rotor gives the multiblock a 16x parallel per tier difference. Moon dust is EV(i think) at UHV, it will only process 16*6 which is less than 2 stacks. And the multi block still eats 1 amps of UHV ignoring how many process it is doing. This gives a heavy cost on energy usage to the machine.

I assumed it wasn't using the retarded scaling of non costing parallels. Parallels are fine, but you still have to run them. 4x parallel shouldn't mean 4x efficiency, but that this single machine has the ability to process 4 things in parallel if provided the power. Free parallels based on size is incredibly OP, compared to a static parallel count of the rotor count. No reason to give things for free here.

BaseCost*RotorCount would give a running cost, but if it's >4x below the input power tier, I'm unsure why overclocking wouldn't be a good enough option. Usually things take power for tasks they do, but not a static number that's unrelated to the processing being done.

This is why I question you, have u actually considered the cost on running the multiblock? and how much would the multiblock outputs per hour with the amount of parallelization.

well with what you said, almost nothing lmao. Again it really depends on outputs, but if you're using 1A tier to make ~8+ full dusts/min of tier materials, or even tiny piles that's really good. Compare it to the ebf. If you're spending less power on creating the materials than ebfing them, you're not really spending much power on the generation. Imo, 4*EBFPower is a fair power value to assign to a specific output in terms of generation. Encourages running the generation constantly, but gives you enough your usage of the materials post ebf. Granted it always comes down to the specific materials, but for things that aren't currently generated easily, but used heavily, it seems to fit.

We could tweak the recipes of the casing cost to make them very expensive and possibly very complex to make to give it a high up front cost.

Upfront costs are much less impactful than running costs, but I'm not opposed to a cost that resembles the utility of the machine. Would we want to decide cost based on a projected output, or make outputs dependent on an arbitrary machine/running cost?

Bees are not meant to be a source, they're just a supplement. In order to keep up the amount that the multiblock process, the only viable option is to automine or have a really huge bee setup that could possibly impact server performance.

Threw a trash stat makemake bee in an IA with 8 productions and an HV WA and it made the cycle time about 2s, meaning you would get a dust every 6-7s, plus an additional 1 every 12s or so from the combs. Could power 6 IAs on that 1 WA. Assuming a concentration of 1/10 of an output dust per planet stone, you're looking at an easy 1 dust every 5ish seconds if you trait you bees and use more than 1 IA. That's an insane output for less than 2A EV. Considering the scalibility of it as well, I'm very unsure as to how those wouldn't work in any way. If we want to make the planet stone bees a lot worse I guess that's an option, but as they are, they work for this flawlessly.

noobyaran9 commented 5 years ago

I assumed it wasn't using the retarded scaling of non costing parallels. Parallels are fine, but you still have to run them. 4x parallel shouldn't mean 4x efficiency, but that this single machine has the ability to process 4 things in parallel if provided the power. Free parallels based on size is incredibly OP, compared to a static parallel count of the rotor count. No reason to give things for free here.

BaseCost*RotorCount would give a running cost, but if it's >4x below the input power tier, I'm unsure why overclocking wouldn't be a good enough option. Usually things take power for tasks they do, but not a static number that's unrelated to the processing being done.

Scaling according to rotor seems to be a better idea. But i still stand by strictly no overclocking. And this machine won't be using the retard parallel that i'm assuming you're talking about. It's flat out (Tier Difference+1)(Parallel Amount) with Power increase by 4x every tier jump. So you'll be seeing this, `Moon dust is EV(i think) at UHV, it will only process 166 which is less than 2 stacks. And the multi block still eats 1 amps of UHV ignoring how many process it is doing. This gives a heavy cost on energy usage to the machine.` using 1 Amp of UHV/t to process 96 moon dust in parallel compared to 96 EV centrifuge that only uses 196k EU/t

Upfront costs are much less impactful than running costs, but I'm not opposed to a cost that resembles the utility of the machine. Would we want to decide cost based on a projected output, or make outputs dependent on an arbitrary machine/running cost?

We will need to discuss on the cost of the machine and also scale the output such that it's not that OP. I'm suggesting 25% drop for 1st tier multi, 50% for 2nd and 75% for 3rd tier. Or maybe someone have a better number?

Assuming a concentration of 1/10 of an output dust per planet stone, you're looking at an easy 1 dust every 5ish seconds if you trait you bees and use more than 1 IA. That's an insane output for less than 2A EV.

1 dust per seconds means you only process 12 dust per minute from bees, thats only 1.33 full dust per minute from bees. Tile Accelerating is very heavy toll on server performance, maybe not for 1 or 2 but if u have many, and considering on a server, you're going to have Delta performance in hours.

0lafe commented 5 years ago

That doesn't do much compared to a normal GT machine, except you actually gave it a worse overclock than normal GT. T to T+1 is the same, 2x/4x, but it gets worse. Instead of 2^T/4^T, you got a nice (TurbineX)*T/T^4.

I'm not mad at it, more punishing overclocks isn't the worst thing. That said, I'm unsure as to why it's the move here. Again, it really depends on initial output values, but I'm unsure as to how this would be a more beneficial way for the multi to run. I'd like to point out that increasing parallels per input voltage tier is an overclock, just a shitty one if it's linear.

Parallel count from turbine quantity, output boost from efficiency, and speed fluctuation based on throughput covers all the mat differences of turbines. Giving 2/4 overclocks in the absence of turbines makes the multi viable past T+1, and doesn't force building more. Instead you can increase turbine count to keep 100% efficiency, until at least T+3 probably. By that point you would probably be making the next tier of the multi, if that's how it works.