[GregTech-5][1.7.10-FORGE-1355+][Unofficial but approved Port][Stable] Even GT5 Experimental is slowly getting stable.

  • That’s a lot of reactors. Between the reactors themselves (5x5x5) and turbines, that must have taken up a lot of space. I’m guessing you only needed one heat exchanger even with that many reactors.

    My plan is currently to build just one fluid reactor with 7 quad cells putting out 950 heat / 2600 EU/tick from the turbines. I should make a point of automating the refueling, as you say.

    I may have overestimated how my power production is doing right now, because I noticed that I’m now short of wood. Usually I run a backlog from my multiple tree farms, but the conveyor belt and buffers are empty. The boilers are still running, but I don’t know for how much longer. Hopefully the diesel generators can keep pace if the boilers start stuttering.

    Power consumption is now around 2500 EU/tick, with peaks of 3000-4000. I’m not sure where all the energy is going, though obviously some is running the blast furnace continuously, and some is to running tungsten electrolysis which is 2000 EU/tick. Though that’s not too often since it requires 7 tungstate to run, and it takes about 3.5 minutes for my ore processing line to accumulate that much.

  • I hope you have a couple of blast furnaces because, unless you're ready to wait a lot of time, I've found that one just won't cut it. Between all the other materials, the tungsten which takes 10 minutes and needs to be alloyed again with steel and, once you start needing LuV+ components, alloyed once again to HSS, the blast furnace can become easily the bottleneck. I had 4 MVs that runned constantly and a HV one for the recipes that required it and they felt slow, although i really hate waiting for processing times and someone else might find them plenty of smelting power. Then I built the GT++ advanced one with an EV hatch which is , like the other GT++ multiblocks, a bit overpowered compared to "vanilla" GT, since it processes 8 items at the same time and is really quick. It consumes a lot of pyrotheum though (the thermal expansion stuff).

  • I’ve actually got 3 HV blast furnaces, but only 2 of them are set up to transfer hot ingots to a vacuum freezer. #1 is my steel / general purpose furnace (hooked to oxygen), #2 is my titanium furnace (hooked to titanium tetrachloride), and #3 is my glow stone wafer furnace (hooked to nitrogen). I’ve got 3 because, in my experience, blast furnaces only take one fluid input. You can build multiple input hatches, but the furnace only checks one of them. Maybe that’s changed.

    Anyway, the idea of building additional furnaces makes sense. That 10 minute wait for tungsten’s ridiculous, and tungsten steel and HSS-G are what, 6.5 minutes? I remember looking at them but not checking the precise number.

    Once I’ve made HSS-G coils, I should be able to overclock tungsten and tungsten steel, bringing the time down to 2.5 minutes for tungsten, but HSS-G requires Naquadah coils to overclock. So building an additional furnace or two might still be a good idea.

  • iirc a GT LHE wasn't used with the fluid reactors and it was just a large array of single block ic2 liquid heat exchangers and stirling generators. This simplified the control system. The only LHE I had was used in a lava pump setup. If you have access to chunkloading and tesseracts (there are few mods with enough fluid throughput to max out an LHE) this might be an enticing option for power and gold/tungsten generation.

  • I’m seeing serious water destruction in my boiler -> large turbine loop. I upgraded the rotors the 2x Large Ultimet and 1x Large Vanadium Steel, and the water just started steadily dropping. This isn’t a startup issue, it’s continuous operation. Steam production is closely matched to steam consumption (64,000 L/sec vs. 63,000), and yet the 2x Advanced distilleries could not keep up.

    It was so severe that I gave in and built a distillation tower just to make distilled water. It has no trouble at all keeping up with the water destruction, since it can output 626 L/sec, more than the combined consumption of the two boilers (426 L/sec distilled water). Still, I’m profoundly irritated.

    The turbines are receiving exactly as much steam as they need, I’ve got fluid regulators feeding them 27,000 L/sec for the ultimet rotors and 9,000 L/sec for the vanadium steel rotor. I’ve verified that all 3 turbines are, in fact, returning water while running. Just not enough to match boiler consumption.

    With my prior rotors, the system was stable at ~60,000 L of distilled water in the buffer tank during continuous load. By the time I finished the distillation tower, it was all gone. Fortunately I have shutoff logic on the boilers testing for less than 90% water in the input hatches.

    I’m 70% done with my first fluid reactor. All 3 turbines are built, as is the large heat exchanger and the reactor core. The containment vessel is 80% built. I’ve run no plumbing or control logic yet, and I don’t have a production facility for coolant yet.

    Rather than run all steam through a steam tank, I’m going to connect the steam output directly and attach an expansion tank to hold any excess steam, with some control logic to turn off the reactor if it gets full. It’s not really possible to exactly match steam production and consumption, though you can get close. Unlike the boilers, you can’t really throttle a heat exchanger. That just ends up backing up hot coolant, which is bad.

    I believe my production will be 76,000 L/sec and consumption will be 75,000 L/sec, but we’ll see how it goes in practice. I’ll probably tune the fluid regulators so the excess goes through the turbines, rather feeding the tank, but the tank will give me some leeway to avoid steam destruction (and thus water destruction).

    That is, if the steam turbines behave as expected. I don’t think they will, given what’s happening with my boiler / large turbine setup.

  • Started up my thorium reactor. It’s apparent that my “steam expansion tank” was ill-conceived, it doesn’t behave at all how I imagined it would. Mainly because for it to work, the expansion tank has to empty really, really fast when the exchanger shuts off. The tank needs just as much throughput for dumping steam as a conventional buffer, so I might as well just build a steam buffer tank, the way I did for my boiler setup.

    I need to re-organize my reactor room. Which probably isn’t as big a task as it seems at first, though it does mean re-doing to the redstone logic controlling the various shutoffs.

  • I had a really bad time with my thorium reactor.

    It just wouldn’t work right. The steam reserve kept fluctuating wildly, and the turbines would drift from 100% output to 10% or even stopped seemingly at random.

    I fixated for a long time on the steam delivery, but after far, far too much time going down blind alleys, I finally realized the problem was the large heat exchanger. The steam output was just all over the place, and wasn’t producing nearly as much steam as it should, overall.

    I’d slapped lots of one-way shutters into the steam pipes, which didn’t help. The moment I did the same to the hot coolant pipe, the turbines started delivering reliable power, and the steam buffer went from wild up and down swings to a slow, steady climb.

    I’m not sure exactly why the large heat exchanger is so sensitive to steady flow. You would think that even if the hot coolant delivery were irregular, it would average out to the same rate, but overall steam production was way down with irregular flow. It’s not like I hit the superheated steam threshold, either, since the small steel pipes can’t deliver 4000L in one second, even with sloshing.

    The final layout is a bit inefficient, because there are long (7-15 segment) pipes running steam from the buffer tank to the turbines. If I had put the turbines directly below the steam buffer, instead of on the same floor, I could have eliminated a lot of pipe. I did it this way because I wanted to be able to see everything easily, the reactor, exchanger, steam tank, and turbines, instead of having to run up and down stairs. It was really helpful when diagnosing my steam production problem.

    It doesn’t bother me too much because Huge PTFE pipes are relatively cheap and high throughput. It does make me wonder about the logistics of anything bigger and higher volume, though.

  • I’m not really that thrilled with the inclusion of a steam buffer in my reactor setup. I just don’t see a better solution.

    The way I see it, the problems are:

    1. Reactor heat output is somewhat irregular. My thorium reactor produces about 950 HU/sec, but it’s not a steady figure. Eyeballing it, it appears to be +/- 30 HU/sec.

    2. You can’t safely throttle the hot coolant output of a fluid reactor. If you regulate output to anything less than the actual average, eventually the hot coolant tank fills up and the reactor starts heating up. This is fixable with Nuclear Control - I have a temperature safety on my reactor even though this should never happen - but you’re throwing away heat if you do this.

    One possible solution is an external hot coolant buffer. You can test if that’s nearly full, and shut down the reactor before the internal tank starts backing up.

    3. Steam production is unpredictable because of (1) and (2).

    4. Because turbines lose efficiency if starved, it’s best to have a slight overproduction of steam relative to turbine consumption, rather than a deficit. Matching it exactly isn’t really possible.

    5. You can tune fluid regulators on the turbines to slightly overconsume steam, but that’s almost certainly going to irregularly starve some turbines. The more turbines in your setup, the more likely that one turbine is going to see a significant deficit.

    For example, my reactor appears to produce 76,000 L/sec of steam, +/- 2,400 L. Turbines 1 and 2 consume 24,000 L each, turbine 3 consumes 27,000, for a total of 75,000. If I tune for the maximum (78,400) by adding 1000 L consumption to each, turbine 3 might only get 23,600 L, a shortfall of 3,400 L.

    6. A buffer solves this problem, and lets you run all turbines at exactly 100%. You can easily see if you’re over or under producing steam over time, smoothing over small production irregularities (to a limit, obviously it didn’t solve the huge swings I was seeing).

    7. If the system is tuned to slightly overproduce, eventually you want to shut off for a short period to avoid steam overflow (and destruction). You can’t really test this without a fair sized tank, flow in pipes is too irregular.

    8. Most tank mods are pretty low capacity. Railcraft’s steel tanks hold more than almost anything else, but have a different drawback - a limit of 20,000 L/sec per valve. My setup requires a minimum of 4 input and 4 output valves, which means a 5x5x4 tank, minimum. That’s what I built, and it adds substantially to the bulk of the reactor system.

  • It seems that you've solved all new encountered problems with buffers and automation, good work there. All I can say that IIRC fluctuating HU production is specific to thorium (and may be MOX) fuel, when it's uranium you are using there's no such problem. From another sight, are you really that concerned in misuse of 30-60 HU/s? I think it's nothing when your reactor gets 950 HU/s, I would just make reactor on 1000 HU/s output and let that excess power get partly lost while make a system stable. For a better tanks I have mentioned pressure pipes mod, even without using "pipes" it has quite useful fluid tanks with flexible modular construction (they just don't emit fluid on their own, it solved with GT pump covers or BC pipes It has powered fluid outlet to move fluids to pipes when RS is applied). Also IMHO GT pipes is quite hard in use because of sloshing and therefore not using their full transit potential, that can be solved partly by shutter modules, but also more effectively by pump covers that additionally moving fluid further.

    Also how's your water destruction issue? Was it solved with usage of LHE?

  • The Large Heat Exchanger / Turbine setup does not appear to destroy water. The large boiler / turbine setup does, so clearly the problem is purely large boilers. I don’t think it’s a startup problem with the boilers, I think they just consume more water per L of steam than the turbines return.

    Regarding the LHE / turbine steam supply / demand rate matching, my primary concern is water destruction, rather than loss of power. Though one thing about the steam buffer is that the excess steam eventually converts to power. When the battery gets close to full the system shuts the reactor off, but the steam in the buffer continues to run the turbines for a while, generating power. While the system will also shut off if the steam buffer gets full, in practice I’ve yet to see it get more than about 10% full before the battery is full.

    Of course, if I were to flip the “ignore battery state” lever, eventually it would happen.

    One way-shutters in Gregtech valves are, generally speaking, as effective as pumps in increasing fluid throughput. At least, for a steady flow. Pumps are more effective at the start and end of a cycle. At the start, the flow in a shuttered pipe sequence starts at 1/2 the input rate and builds toward the full rate; at the end, it falls in an inverse geometric rate, so each second the rate is 1/2 what it was in the prior second. Pumps deliver the full rate at both start and end, provided can handle that rate. Shutters, of course, have no rate limit.

  • I think I’m taking a break from Gregtech.

    I starting thinking about this because the only projects on my horizon are building an assembly line so I can make a quantum suit, making a high octane gasoline synthesis line, improving my oil refinery to meet the needs of the gasoline production, and making a large combustion engine to burn it.

    The quantum suit would be primarily to go after the Ender Dragon. That would give me access to naquadah, but I’m not feeling the urgency of that.

    The assembly line requires 4K EU/tick, which means upgrading at least some of my energy storage and distribution to 8kV tech. Which in turn means a lot of waiting for tungsten to smelt.

    Given the output of the thorium reactor, the gasoline stuff would just be for the experience of building it. Right now the reactor is doing a decent job of covering all my energy needs.

    Another issue is that I’m experiencing pretty severe frame rate issues. I’ve got a 8700K CPU and a GTX 1070ti GPU, but I’m seeing frame rates dip to 6-7 FPS. Turning down some of the graphic settings got that up to 10-11 FPS, but it’s a real playability issue. Interactions with chests are very slow when the frame rate drops below 9, and the light flickers.

    I don’t know how to fix it. It’s worse when I’m looking in some directions, but it’s true even if there’s a wall directly in front of me, so it’s not a simple graphical update issue. I’m assuming it’s some entities triggering lots of block updates.

    I’m not sure when, or if, I’ll return.

  • I think it's piping that make FPS drop. I have much weaker PC configuration, so FPS was steadily decreasing to the point I realized that it's on the verge of my tolerance. At first I replaced GT pipes with BC ones, after some time I mostly replaced them with pressure pipes since they can hold multiple liquids and actually don't store them in sections, so now my FPS now fluctuates from 20 on start to 35-40 after some time. Taking into account how vast your plumbing network is it seems expected. It's just unbelievable that coffee lake and nvidia ti was overwhelmed by minecraft.

    Display Spoiler

    I agree, there's no much diversity ahead (maybe except for fusion), there's just waiting for resources being processed, wire/plumbing trifling, repeating operations, EU net expansions and generation upgrading but nothing really new, no horizons ahead. I have last symbolic goal of making 1 neutronium ingot, the moment I'll make it I will delete a game.

    Well, whatever your decision will be I wish good luck to you, seems like this thread will go in desolation once again.

  • Lag is a real problem with this type of mods. They are built around the idea that you need to automate as much as possible and scale things up to progress at a reasonable pace, and while there's nothing wrong with the idea, minecraft just can't handle it. If you pay attention and use the most efficient (hardware-wise) way to gets things done you can get a bit further, but the game will always get worse.

    In my play through I built a void base with everything on it's island and ender chests/tank to move items around; my laptop initially seemed to cope with it well but as I progressed in some areas the FPS would start dropping, and there isn't all that much.

    I tried GT:NH just to see how my computer would handle it: on a fresh world I get around 20 FPS with spikes, NEI takes about 5 seconds to update after I type something and if i go near one of those underground dungeons the FPS don't go above 5.

    While GT:NH isn't the best example since it's a very big modpack, it gives an idea on how things can get. The only solution I know is having a real beefy computer, and even then i don't know how much it helps. Either that or enduring the lag.

  • I suspected the pipes as well, given that every pipe segment is constantly updating, and I’ve got an awful lot of pipes. The hand scanner claimed they weren’t causing delays, but I don’t know if I really trust the scanner on this issue.

    Minecraft’s problem, and the problem with Minecraft mods, is Java. Java’s bytecode is just never going to be as fast as programs compiled to actual machine code. So-called “just in time” compilation can help, but there’s still the overhead of doing the compilation at run time rather than at development time, and that’s never going away.

  • I suspected the pipes as well, given that every pipe segment is constantly updating, and I’ve got an awful lot of pipes. The hand scanner claimed they weren’t causing delays, but I don’t know if I really trust the scanner on this issue.

    Minecraft’s problem, and the problem with Minecraft mods, is Java. Java’s bytecode is just never going to be as fast as programs compiled to actual machine code. So-called “just in time” compilation can help, but there’s still the overhead of doing the compilation at run time rather than at development time, and that’s never going away.

    The Issue with Java isn't that its slow, its that most people who write in it are utterly incompetent. And this includes ALL Modders including myself.

    Right now there is not a single Mod that has an actually performant Pipe System, because people at Forge decided to use very retarded ways of ensuring compatibility between Mods, including in recent MC versions, the prime example of a bad ECS also known as the Capability System.

    Lag comes from incompetence, not from the Languages used.

  • It’s true that I’ve seen things in snippets of code that raise my hackles. I’m thinking specifically of the bit that checks if you’re right-clicking on a machine with a bucket of water, and removes any paint if you are.

    Said code creates a new water bucket object on the heap every time you right-click on a machine, and compares the object to what you’re holding. While I don’t know the details of the API, there has to be a way to do that with a simple comparison against a constant. I.e. get the type ID, or call a method with the type ID as a parameter.

  • It’s true that I’ve seen things in snippets of code that raise my hackles. I’m thinking specifically of the bit that checks if you’re right-clicking on a machine with a bucket of water, and removes any paint if you are.

    Said code creates a new water bucket object on the heap every time you right-click on a machine, and compares the object to what you’re holding. While I don’t know the details of the API, there has to be a way to do that with a simple comparison against a constant. I.e. get the type ID, or call a method with the type ID as a parameter.

    YEP, that is 100% correct. Now that I think of it, I might do a utility function that makes shit like this happen less often. At least for GT6.

  • Hi guys, has been a while!

    So, I have some doubts about circuits: I am using gregtech-5.09.32pre3.jar (the pre4 and pre5 crashes on loading my save) seems that I need a workstation circuit to create the HV circuit assembler, but the only recipe it does is the "mainframe".

    All other recipes that supposedly are HV, require 600 EU which HV doesn't reach;

    Am I wrong?

  • I've got pre5 running (aside from some strange issues with tile entities that I haven't figured out - sometimes exposed GT ores are blank until I stand next to them for a few seconds, and sometimes when I get back home from exploring, some of my JABBA barrels are blank, or some of my GT machines are pink and black, or some of my IC2 crop sticks are unexpectedly empty until I exit to menu and re-enter the world)

    Anyway, as far as I can tell, you are correct about the voltage requirements for building circuits even in pre5, but I haven't figured out the logic behind having the mainframe be the only circuit really in the HV range for making.