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

  • 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.



    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.

    • Official Post

    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.

    • Official Post

    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.

  • I started with pre5, but it crashed on loading my save.

    So I started loading the game with the Pre1, pre2 and pre3. PRe4 and 5 simply crashes the game (after I chose my save to load, I get back to the tile screen. If i try to load the save again, crashes).

    Well, I try to fix the circuits by myself with minetweaker. It was ages since I used that thought...

  • Looking at circuits, I just noticed something else: there doesn't seem to be a way to produce Bisphenol A (NEI only shows me the recipe for getting it into or out of a cell with a fluid canner). Maybe I'm missing an "optional" mod that would make it obtainable, and it isn't a big deal, since all it seems to be used for is making more phenolic circuit boards per wood pulp than with glue (and it's not like wood pulp and glue are all that hard to obtain in significant quantities). Or is it something that was planned to be taken further but not fully implemented?

  • Anyone know how to input items into the magic energy absorber / magic energy converter?

    It doesnt seem to accept item input from any pipes I've tried. Conveyor Modules also do not help.

  • Just got it tested on .32pre5. Magic Energy Converter accepts items from BC pipes and vanilla hopper, guess it accepts from GT machines too. Just make sure you trying to insert right items (I tested with Netherstar) and not doing it through "face" or output side (output side marked with a dot, while "face" is not so obvious but you can change it with croach+RMB with a wrench).


    Bisphenol A had appeared in large chemistry update, it was a step for making epoxy or something. However chemistry was significantly simplified in last updates so now it seems to be an obsolete (although I think it can be reenabled somewhere in configs).

  • I think I found a bug in Printer: while it is possible to manually place papers in its input slot, no pipes or vanilla hoppers can insert them for me. The machine just doesn't accept paper as a valid input.


    Also, I thought UV and ZPM batteries were uncraftable but I just found "B:EnableZPMandUVBatteries_false=false" in "OverpoweredStuff.cfg". Why are they disabled by default? I don't need them at the moment as I'm still in the IV age, but to me it makes no sense that just a battery is overpowered, unlike things like higher-tier Solar Panels that can actually generate huge amount of power with no running costs.