GT Calculations: Difference between revisions

From GT New Horizons
Content added Content deleted
No edit summary
No edit summary
Line 2: Line 2:


Along your GT journey you'll eventually start setting up full processing setups. This might start as early as LV, if not even in steam. A key part of any GT setup is processing speed. This will dictate how many of each machine you need, how much power you will need to route to it, and most importantly, your output. While often times you can simply wing it on quantities and tier, there's times you're looking for a specific output, or simply want to know how much fuel your power gen will produce. When it comes to calculations around GT, there's a few simple equations that will come in handy. Most are easy enough to derive yourself through how overclocking works, but this section is dedicated to laying them out for you to use. Most of these equations will be written in the syntax of excel, as it's a useful tool for GT math. However this can be done with anything that can handle rounding and logs.
Along your GT journey you'll eventually start setting up full processing setups. This might start as early as LV, if not even in steam. A key part of any GT setup is processing speed. This will dictate how many of each machine you need, how much power you will need to route to it, and most importantly, your output. While often times you can simply wing it on quantities and tier, there's times you're looking for a specific output, or simply want to know how much fuel your power gen will produce. When it comes to calculations around GT, there's a few simple equations that will come in handy. Most are easy enough to derive yourself through how overclocking works, but this section is dedicated to laying them out for you to use. Most of these equations will be written in the syntax of excel, as it's a useful tool for GT math. However this can be done with anything that can handle rounding and logs.



=== ''' Important variables ''' ===
=== ''' Important variables ''' ===
Line 7: Line 8:
When calculating any GT values, there's a few important variables you'll need to get.
When calculating any GT values, there's a few important variables you'll need to get.


RecipeTime, simple the time in ticks of the recipe. This should be calculated with ticks being a constant 20tps. If you wish to account for a lower tps, I'd recommend setting your tps to a variable, and using that instead.
Recipe_Time, simply the time in ticks of the recipe. This should be calculated with ticks being a constant 20tps. If you wish to account for a lower tps, I'd recommend setting your tps to a variable, and using that instead.


RecipeVoltage, simply the voltage of a given recipe. This is used to calculate power used, as well as set tier for overclocking. Don't account amps in this, as amps don't set tier but rather power needed to run.
Recipe_Voltage, simply the voltage of a given recipe. This is used to calculate power used, as well as set tier for overclocking. Don't account amps in this, as amps don't set tier but rather power needed to run.


RecipeAmps, this is just the amps of a recipe. Things such as the thermal centrifuge using 2, or arc furnaces using 3.
Recipe_Amps, this is just the amps of a recipe. Things such as the thermal centrifuge using 2, or arc furnaces using 3.


Input quantity, simply anything you want to measure in some way. This is mostly for calculating needed inputs for chains of machines, however it can be for anything you just want to know the rate of input on. For fluids it's easiest to measure in L, and dusts in full dust quantities.
Input_quantity, simply anything you want to measure in some way. This is mostly for calculating needed inputs for chains of machines, however it can be for anything you just want to know the rate of input on. For fluids it's easiest to measure in L, and dusts in full dust quantities.


output quantity, same as input, except for outputs.
Output_Quantity, same as input, except for outputs.


parallels, this can be defined by a value in the case of some PA calcs, but this will usually be something you'd want to define with an equation. Things like ++ machines have varying numbers here, as well as PAs having ~2 values for a spectrum of machine efficiency vs power efficiency. For simple calcs this is easiest input as a value.
Parallels, this can be defined by a value in the case of some PA calcs, but this will usually be something you'd want to define with an equation. Things like ++ machines have varying numbers here, as well as PAs having ~2 values for a spectrum of machine efficiency vs power efficiency. For simple calcs this is easiest input as a value.


speed bonus, this is simply a multiplier on machine speeds. Sometimes it'll vary, such as the case of the pyro coil bonuses, but can be found simply or calculated easily from coils/etc.
Speed_Bonus, this is simply a multiplier on machine speeds. Sometimes it'll vary, such as the case of the pyro coil bonuses, but can be found simply or calculated easily from coils/etc.


overclock factor, this is a value to use for how speeds change with overclocking. Easiest to set to 2 for most machines with 2/4 overclocking, and 4 for perfect OCs like the LCR. Sometimes this needs a dynamic calc for machines like the ebf with both 2/4 and 4/4 OCing, but can also be set as a value most of the time.
Overclock_Factor, this is a value to use for how speeds change with overclocking. Easiest to set to 2 for most machines with 2/4 overclocking, and 4 for perfect OCs like the LCR. Sometimes this needs a dynamic calc for machines like the ebf with both 2/4 and 4/4 OCing, but can also be set as a value most of the time. Essentially it is the speed multiplier a machine gets when overclocked. It will be used to apply the same overclock function to all machines, despite having different overclock mechanics.

Overclock_Power, this value is the increase in power associated with an overclock. This will be 4 for the majority of machines, however some have values of 2, such as the massfab or fusion reactor.

One value you will need to manually set/change will be Tier. This will be the value you choose to run your machine at. This value is used to overclock recipes.


Then anything else you might need. This could be something such as the pipe tier of a chem plant, the heat of an ebf recipe, EU reduction of ++, or anything that doesn't fit into the above categories. Usually these will be machine specific.
Then anything else you might need. This could be something such as the pipe tier of a chem plant, the heat of an ebf recipe, EU reduction of ++, or anything that doesn't fit into the above categories. Usually these will be machine specific.



=== '''Calculating recipe tiers''' ===
=== '''Calculating recipe tiers''' ===
Line 29: Line 35:
Finding the tier of a recipe is simple enough, however it's a little more complex when you try to use equations. We all know 1-32v is LV, 33-128 is MV, and so on, but putting this in a formula is a little more complex. The basic idea is to use something that equates to a base 4 log to calculate amounts of times that the voltage is 4x over 8v. Rounding this value up will give you the tier, for values 8v and above.
Finding the tier of a recipe is simple enough, however it's a little more complex when you try to use equations. We all know 1-32v is LV, 33-128 is MV, and so on, but putting this in a formula is a little more complex. The basic idea is to use something that equates to a base 4 log to calculate amounts of times that the voltage is 4x over 8v. Rounding this value up will give you the tier, for values 8v and above.


Roundup(log((RecipeVoltage/8), base 4)). This applies a tier value of 1 to anything 9-32, a value of 2 to anything between 33-128, and so on. The one fault here comes with how values of 8 and below behave. One option is to use a max value function, to keep the tier value always at 1 or above.
Roundup(log((Recipe_Voltage/8), base 4)). This applies a tier value of 1 to anything 9-32, a value of 2 to anything between 33-128, and so on. The one fault here comes with how values of 8 and below behave. One option is to use a max value function, to keep the tier value always at 1 or above.


Max(Roundup(log(RunningVoltage/8, 4)), 1) will work as a tier defining function for any recipe. Remember not to not factor in amps here, as those don't define tier, just power consumed.
Max(Roundup(log(Running_Voltage/8, 4)), 1) will work as a tier defining function for any recipe. Remember not to not factor in amps here, as those don't define tier, just power consumed. This results in us defining Recipe_Tier based on the voltage of any given recipe.




=== '''Calculating Recipe time with variables''' ===
=== '''Calculating Recipe time with variables''' ===
The next important value to calculate will be the length of a recipe. This will be accounting overclocks, speed bonuses, and parallels. This value is equated to Recipe_Time/(Speed_Bonus*Parallels*Overclock_Favtor^(Recipe_Tier/Running_Tier)). Running_Tier is whatever tier you choose to run the process at. We will call this value Real_Recipe_Time as it's the time you will be experiencing with any given process.
The next important value to calculate will be the length of a recipe.
It's important to keep the quantity of machines out of this calc, as we will be using the Real_Recipe_Time variable to define the quantity of machines.

There is however a small issue with this calculation as it is. Single recipe time before parallels can only function within ticks. As the time is defined in ticks, we can simply apply a roundup function on it to always give a full tick time, as well as cap recipes at 1t. This gives us roundup(Recipe_Time/(Speed_Bonus*Overclock_Favtor^(Recipe_Tier/Running_Tier)))/Parallels = Real_Recipe_time.


==='''Initial machine quantities'''===

Now it's time to give a start point to your processing chain. You can do this by manually setting a desired output rate, setting a specific machine quantity yourself, or accounting for a given input. For something such as ore processing, it could be easier to account for an input rate, while something like power gen would function best with setting a desired fuel output. If you have one particularly expensive machine in your chain, it could be best to set the quantity of those, in order to maximize efficiency of a set amount of that machine. If you want to put more work into it, you could give a setup a fixed power usage, and calculate everything based on that, however that is more complex. Whatever you do, you'll need to set one value in order to calculate everything else.

If you choose an output/input rate, the calculation of Machine_Quantity for that step will be your next goal. Here is where Input_Quantity and Output_Quantity come into play. Say you're defining an output, we will lable that Set_Output_Rate. What you will do next is define a value in ticks, for example 500 L/t. Then you will use Output_Quantity/(Real_Recipe_Time*Set_Output_Rate) to define Machine_Quantity. What this does is tell you how many of that machine you will need to reach your desired output. With this value, you can start calculating the rest of the chain.

If you were calculating based on an input, you would use Input_Quantity instead of Output_Quantity. If you were setting Machine_Quantity you wouldn't set the output rate, and instead just set the Machine_Quantity to a static value instead of an expression.


=='''Calculating Input/Output rates'''===

This will be almost the reverse of using a fixed output to define Machine_Quantity. Here you will use Input_Quantity and Output_Quantity for each item/fluid in a recipe you wish to evaluate. This number is primarily for calculating other Machine_Quantities, so you can simply calculate values for items you wish to view outputs for, or items you are generating within the processing chain. This value is calculated through

Machine_Quantity*Output(or)Input_Quantity/Real_Recipe_Time. This will provide an input or output value in ticks for any given item. We will ascribe the names Input_Rate and Output_Rate to these values.

==='''Calculating Machine_Quantity'''===

This will be the value that tells you how many machines will be needed. The build requirement at a given tier, to reach a given output. This value is calculated with an Output_Quantity from one machine, and an Input_Quantity from another. If calculating a machine (a) that will input something created by another quantity defined machine (b), it will use the equation of Output_Rate(b)*Real_Recipe_Time(a)/Input_Quantity(a). If you are defining an output based on another machines input, you would simply flip Output_Rate to Input_Rate, and Input_Quantity to Output_Quantity. This will give you a value of machines needing to be built. The small issue here is that machine quantities can be fractional, which doesn't work. Rounding this number up in a 2nd step will display how many you will need, however it's important to keep the fractional values for speed calcs. If you need to run 7.5 machines, then build 8, but supply them with the same input rates the 7.5 needed, you will be running 7 of them constantly, and one 50% of the time, resulting in the speeds of 7.5 machines.

==='''Power calculations'''===

When it comes to calculating power to machines in a setup, you'll need to get a few values. First off, a general overall power usage is important. This is calculated as Recipe_Voltage*Machine_Quantity*Overclock_Power^(Tier-Recipe_Tier) for any machine that doesn't have dynamic parallels. If a machine can run parallels itself, such as ++ multis, you will need another equation to calculate this, as you won't be overclocking as much as normal. Once you calculate this value for each step, simply summing them together gets your average power draw.

However there is more to power than simply your average draw. This is where machine quantities being fractional comes in, as well as values useful for setting up power logistics. Using a rounded up calc on machine quantity, you can find the maximum draw your setup will take, which is useful for skipping battery buffer usage, and wiring for Max draw instead. This value will give you the amount of power each step will require at most, ensuring no machines get stuck/shut off.

Revision as of 16:50, 27 March 2020

Introduction

Along your GT journey you'll eventually start setting up full processing setups. This might start as early as LV, if not even in steam. A key part of any GT setup is processing speed. This will dictate how many of each machine you need, how much power you will need to route to it, and most importantly, your output. While often times you can simply wing it on quantities and tier, there's times you're looking for a specific output, or simply want to know how much fuel your power gen will produce. When it comes to calculations around GT, there's a few simple equations that will come in handy. Most are easy enough to derive yourself through how overclocking works, but this section is dedicated to laying them out for you to use. Most of these equations will be written in the syntax of excel, as it's a useful tool for GT math. However this can be done with anything that can handle rounding and logs.


Important variables

When calculating any GT values, there's a few important variables you'll need to get.

Recipe_Time, simply the time in ticks of the recipe. This should be calculated with ticks being a constant 20tps. If you wish to account for a lower tps, I'd recommend setting your tps to a variable, and using that instead.

Recipe_Voltage, simply the voltage of a given recipe. This is used to calculate power used, as well as set tier for overclocking. Don't account amps in this, as amps don't set tier but rather power needed to run.

Recipe_Amps, this is just the amps of a recipe. Things such as the thermal centrifuge using 2, or arc furnaces using 3.

Input_quantity, simply anything you want to measure in some way. This is mostly for calculating needed inputs for chains of machines, however it can be for anything you just want to know the rate of input on. For fluids it's easiest to measure in L, and dusts in full dust quantities.

Output_Quantity, same as input, except for outputs.

Parallels, this can be defined by a value in the case of some PA calcs, but this will usually be something you'd want to define with an equation. Things like ++ machines have varying numbers here, as well as PAs having ~2 values for a spectrum of machine efficiency vs power efficiency. For simple calcs this is easiest input as a value.

Speed_Bonus, this is simply a multiplier on machine speeds. Sometimes it'll vary, such as the case of the pyro coil bonuses, but can be found simply or calculated easily from coils/etc.

Overclock_Factor, this is a value to use for how speeds change with overclocking. Easiest to set to 2 for most machines with 2/4 overclocking, and 4 for perfect OCs like the LCR. Sometimes this needs a dynamic calc for machines like the ebf with both 2/4 and 4/4 OCing, but can also be set as a value most of the time. Essentially it is the speed multiplier a machine gets when overclocked. It will be used to apply the same overclock function to all machines, despite having different overclock mechanics.

Overclock_Power, this value is the increase in power associated with an overclock. This will be 4 for the majority of machines, however some have values of 2, such as the massfab or fusion reactor.

One value you will need to manually set/change will be Tier. This will be the value you choose to run your machine at. This value is used to overclock recipes.

Then anything else you might need. This could be something such as the pipe tier of a chem plant, the heat of an ebf recipe, EU reduction of ++, or anything that doesn't fit into the above categories. Usually these will be machine specific.


Calculating recipe tiers

Finding the tier of a recipe is simple enough, however it's a little more complex when you try to use equations. We all know 1-32v is LV, 33-128 is MV, and so on, but putting this in a formula is a little more complex. The basic idea is to use something that equates to a base 4 log to calculate amounts of times that the voltage is 4x over 8v. Rounding this value up will give you the tier, for values 8v and above.

Roundup(log((Recipe_Voltage/8), base 4)). This applies a tier value of 1 to anything 9-32, a value of 2 to anything between 33-128, and so on. The one fault here comes with how values of 8 and below behave. One option is to use a max value function, to keep the tier value always at 1 or above.

Max(Roundup(log(Running_Voltage/8, 4)), 1) will work as a tier defining function for any recipe. Remember not to not factor in amps here, as those don't define tier, just power consumed. This results in us defining Recipe_Tier based on the voltage of any given recipe.


Calculating Recipe time with variables

The next important value to calculate will be the length of a recipe. This will be accounting overclocks, speed bonuses, and parallels. This value is equated to Recipe_Time/(Speed_Bonus*Parallels*Overclock_Favtor^(Recipe_Tier/Running_Tier)). Running_Tier is whatever tier you choose to run the process at. We will call this value Real_Recipe_Time as it's the time you will be experiencing with any given process.

It's important to keep the quantity of machines out of this calc, as we will be using the Real_Recipe_Time variable to define the quantity of machines.

There is however a small issue with this calculation as it is. Single recipe time before parallels can only function within ticks. As the time is defined in ticks, we can simply apply a roundup function on it to always give a full tick time, as well as cap recipes at 1t. This gives us roundup(Recipe_Time/(Speed_Bonus*Overclock_Favtor^(Recipe_Tier/Running_Tier)))/Parallels = Real_Recipe_time.


Initial machine quantities

Now it's time to give a start point to your processing chain. You can do this by manually setting a desired output rate, setting a specific machine quantity yourself, or accounting for a given input. For something such as ore processing, it could be easier to account for an input rate, while something like power gen would function best with setting a desired fuel output. If you have one particularly expensive machine in your chain, it could be best to set the quantity of those, in order to maximize efficiency of a set amount of that machine. If you want to put more work into it, you could give a setup a fixed power usage, and calculate everything based on that, however that is more complex. Whatever you do, you'll need to set one value in order to calculate everything else.

If you choose an output/input rate, the calculation of Machine_Quantity for that step will be your next goal. Here is where Input_Quantity and Output_Quantity come into play. Say you're defining an output, we will lable that Set_Output_Rate. What you will do next is define a value in ticks, for example 500 L/t. Then you will use Output_Quantity/(Real_Recipe_Time*Set_Output_Rate) to define Machine_Quantity. What this does is tell you how many of that machine you will need to reach your desired output. With this value, you can start calculating the rest of the chain.

If you were calculating based on an input, you would use Input_Quantity instead of Output_Quantity. If you were setting Machine_Quantity you wouldn't set the output rate, and instead just set the Machine_Quantity to a static value instead of an expression.


Calculating Input/Output rates=

This will be almost the reverse of using a fixed output to define Machine_Quantity. Here you will use Input_Quantity and Output_Quantity for each item/fluid in a recipe you wish to evaluate. This number is primarily for calculating other Machine_Quantities, so you can simply calculate values for items you wish to view outputs for, or items you are generating within the processing chain. This value is calculated through

Machine_Quantity*Output(or)Input_Quantity/Real_Recipe_Time. This will provide an input or output value in ticks for any given item. We will ascribe the names Input_Rate and Output_Rate to these values.

Calculating Machine_Quantity

This will be the value that tells you how many machines will be needed. The build requirement at a given tier, to reach a given output. This value is calculated with an Output_Quantity from one machine, and an Input_Quantity from another. If calculating a machine (a) that will input something created by another quantity defined machine (b), it will use the equation of Output_Rate(b)*Real_Recipe_Time(a)/Input_Quantity(a). If you are defining an output based on another machines input, you would simply flip Output_Rate to Input_Rate, and Input_Quantity to Output_Quantity. This will give you a value of machines needing to be built. The small issue here is that machine quantities can be fractional, which doesn't work. Rounding this number up in a 2nd step will display how many you will need, however it's important to keep the fractional values for speed calcs. If you need to run 7.5 machines, then build 8, but supply them with the same input rates the 7.5 needed, you will be running 7 of them constantly, and one 50% of the time, resulting in the speeds of 7.5 machines.

Power calculations

When it comes to calculating power to machines in a setup, you'll need to get a few values. First off, a general overall power usage is important. This is calculated as Recipe_Voltage*Machine_Quantity*Overclock_Power^(Tier-Recipe_Tier) for any machine that doesn't have dynamic parallels. If a machine can run parallels itself, such as ++ multis, you will need another equation to calculate this, as you won't be overclocking as much as normal. Once you calculate this value for each step, simply summing them together gets your average power draw.

However there is more to power than simply your average draw. This is where machine quantities being fractional comes in, as well as values useful for setting up power logistics. Using a rounded up calc on machine quantity, you can find the maximum draw your setup will take, which is useful for skipping battery buffer usage, and wiring for Max draw instead. This value will give you the amount of power each step will require at most, ensuring no machines get stuck/shut off.