Your GTNH Discord Username
No response
Your Pack Version
2.7.4
Your Proposal
Update the large turbines' code to conform more closely to the descriptions/math on the Wiki.
I would like to hear from the regular devs and veteran players about this. I'm new to GTNH and only at the tail end of HV. Is attempting to change it even desirable?
Your Goal
The math on the Wiki is rather straightforward but code problems cause actual in-game values to significantly diverge from it, in what can be considered rather confusing ways. I am viewing the Wiki descriptions as correct, since they are simple, don't require programming knowledge to understand, and they, rather than the code, face the majority of players.
The large turbine implementation has at least the following problems:
- There are excessive float to integer conversions (in weird spots, too), compounding errors within the math.
- The calculations use only 1 tick of data.
- Bonus: This corner case appears to not honor turbines' overflow tiers. This isn't relevant to the rest of this writeup but is one example of something that can impact players and likely isn't going to be documented anywhere outside the code itself.
Note: I've only really looked at the large gas turbine but comparable issues probably affect all types of large turbines.
The float-int conversions are problematic for a simple reason: the mathematical operations the code performs blatantly mismatch what the Wiki describes, and do so in counter-intuitive ways to non-programmers.
The "only 1 tick" issue is less obvious but it is a problem because of fluid regulators. Basically everywhere I've seen information about large turbines, fluid regulators were effectively spoken of as completely mandatory; the two are tightly tied together. The fluid regulator GUI very plainly offers settings for both volume (in L) and a time window (in t) and even shows the average in L/s. This allows arbitrary fractional rates. Large turbine discussions/information consistently pointing to fluid regulators paired with regulators' GUI allowing fractional rates is very misleading, as the usable rates are far more restricted in ways people don't seem to discuss. Fractional rates simply do not work well but not all turbine/fuel combos land on whole-number optimal rates using the Wiki's math.
To illustrate the current code's weirdness, consider a tight damascus steel turbine with benzene in a large gas turbine:
- Fuel value: 360 EU/L.
- Optimal energy flow: 800 EU/t in, 880 EU/t out (110% efficiency).
- Optimal fuel flow: 800 EU/t * 1/360 L/EU = 20/9 L/t.
With completely unregulated fuel flow, this configuration tops off at 1425 EU/t in-game. The Wiki math indicates 1536 EU/t (3A HV) is possible without even going all the way to the maximum flow.
For optimal flow, exactly 20L / 9t can be set on a fluid regulator. This inserts 20L on every 9th tick and then the regulator idles for the rest of the time. After the benzene is inserted, the large turbine consumes all 20L at its maximum rate of 6 L/t within 3-4 ticks and the remaining 6-5 ticks of the regulator's timing window are completely dry of fuel. Only the current tick matters in the code, which lacks fuel a lot of the time, and thus calculations are thrown off. The result is that power output cycles through several values between 25 and 75 EU/t, or 2.8%-8.5% of the expected 880 EU/t output from optimal fuel flow. As much as I read up about turbines online (a lot), this behavior was completely unexpected to me at first and I was compelled to look at the code and perform many experiments to figure out what happened. It wasn't fun.
I understand that scanning the multi's controller does show the actual, in-game "optimal" flow value. For the example, it is 2 L/t. The scanner showing that information does not remove the issues and simply provides another clear example of the code/Wiki mismatches.
Expected vs. actual:
"Game" was simplified to integer steps since fractions don't have stable output.
There is an insane amount of possible large turbine configurations. The turbine size, turbine material, loose/tight fit, fuel, and fuel flow can all be tailored to specific needs. Theoretically. In practice, the current implementation seems to heavily discourage deviating from the "best" setups, those that happen not to demonstrate the issues or that are still effective despite them. I've already seen, while searching around for information, lots of "just use X" replies to players' questions (including my own). The root issues seem to be getting ignored.
Your Vision
The updates would involve cleaning up float-int conversions and some of the calculations. The high-level design and pure math behind it will remain unchanged; it is only the implementation of the design that is currently at issue. The updates would also involve adding a moving average of the input EU flow. This would stabilize the flow value across more than 1 tick before it is used in the calculations. Further details can be provided if there is actual interest in this.
If updated:
- The Wiki would much more accurately describe the behavior that the machines have, potentially reducing player confusion, particularly so for players new to large turbines.
- Players would be able to choose a turbine and fluid, easily check its curve with some basic math, and then precisely target far more specific points on the curve for flexible power needs (my initial impression of what was possible when first studying turbines).
- Fractional fuel flow rates would be practical and, as a result, the fluid regulator GUI would look less misleading.
- Some niche turbine configurations would probably become useful.
- Some configurations probably would be penalized (if the type casts had erred in the player's favor). On the example graph: where the game's plots lies above the Wiki's.
I can potentially do the updates myself, if needed.
Final Checklist
Your GTNH Discord Username
No response
Your Pack Version
2.7.4
Your Proposal
Update the large turbines' code to conform more closely to the descriptions/math on the Wiki.
I would like to hear from the regular devs and veteran players about this. I'm new to GTNH and only at the tail end of HV. Is attempting to change it even desirable?
Your Goal
The math on the Wiki is rather straightforward but code problems cause actual in-game values to significantly diverge from it, in what can be considered rather confusing ways. I am viewing the Wiki descriptions as correct, since they are simple, don't require programming knowledge to understand, and they, rather than the code, face the majority of players.
The large turbine implementation has at least the following problems:
Note: I've only really looked at the large gas turbine but comparable issues probably affect all types of large turbines.
The float-int conversions are problematic for a simple reason: the mathematical operations the code performs blatantly mismatch what the Wiki describes, and do so in counter-intuitive ways to non-programmers.
The "only 1 tick" issue is less obvious but it is a problem because of fluid regulators. Basically everywhere I've seen information about large turbines, fluid regulators were effectively spoken of as completely mandatory; the two are tightly tied together. The fluid regulator GUI very plainly offers settings for both volume (in L) and a time window (in t) and even shows the average in L/s. This allows arbitrary fractional rates. Large turbine discussions/information consistently pointing to fluid regulators paired with regulators' GUI allowing fractional rates is very misleading, as the usable rates are far more restricted in ways people don't seem to discuss. Fractional rates simply do not work well but not all turbine/fuel combos land on whole-number optimal rates using the Wiki's math.
To illustrate the current code's weirdness, consider a tight damascus steel turbine with benzene in a large gas turbine:
With completely unregulated fuel flow, this configuration tops off at 1425 EU/t in-game. The Wiki math indicates 1536 EU/t (3A HV) is possible without even going all the way to the maximum flow.
For optimal flow, exactly 20L / 9t can be set on a fluid regulator. This inserts 20L on every 9th tick and then the regulator idles for the rest of the time. After the benzene is inserted, the large turbine consumes all 20L at its maximum rate of 6 L/t within 3-4 ticks and the remaining 6-5 ticks of the regulator's timing window are completely dry of fuel. Only the current tick matters in the code, which lacks fuel a lot of the time, and thus calculations are thrown off. The result is that power output cycles through several values between 25 and 75 EU/t, or 2.8%-8.5% of the expected 880 EU/t output from optimal fuel flow. As much as I read up about turbines online (a lot), this behavior was completely unexpected to me at first and I was compelled to look at the code and perform many experiments to figure out what happened. It wasn't fun.
I understand that scanning the multi's controller does show the actual, in-game "optimal" flow value. For the example, it is 2 L/t. The scanner showing that information does not remove the issues and simply provides another clear example of the code/Wiki mismatches.
Expected vs. actual:
"Game" was simplified to integer steps since fractions don't have stable output.
There is an insane amount of possible large turbine configurations. The turbine size, turbine material, loose/tight fit, fuel, and fuel flow can all be tailored to specific needs. Theoretically. In practice, the current implementation seems to heavily discourage deviating from the "best" setups, those that happen not to demonstrate the issues or that are still effective despite them. I've already seen, while searching around for information, lots of "just use X" replies to players' questions (including my own). The root issues seem to be getting ignored.
Your Vision
The updates would involve cleaning up float-int conversions and some of the calculations. The high-level design and pure math behind it will remain unchanged; it is only the implementation of the design that is currently at issue. The updates would also involve adding a moving average of the input EU flow. This would stabilize the flow value across more than 1 tick before it is used in the calculations. Further details can be provided if there is actual interest in this.
If updated:
I can potentially do the updates myself, if needed.
Final Checklist