Stones are tool materials and I find them easier to make in bulk than flint from gravel - they aren't as durable (unless you got Basalt/Granite), but you can make many of them easily.
You are correct that it's doing this because there isn't enough space in the central pipe. However, replacing the section attached to the Tank Extender with a larger pipe just makes it pressurize to 4467/4800L instead of 867/1200L, so it's not fixing the issue.
(I could replace the whole pipe with larger pipes and it would work, but the central issue here is that 600L/t pipes aren't working as advertised since they fail to be carrying 512L/t steam...)
My SMP setup pipes steam into an Ender Garbage Bin and it has the same overpressurizing problem - so I don't think the problem solely lies with the pressure valve. (Although to get the same behavior, you need a longer pipe - 2 pipes into Ender Garbage Bin flows fine.)
Just when I thought I finally understood how fluid pipes work I found out that I was wrong again.
Setup should work, right? WRONG! The boiler on the right (or left, one of them) overpressurizes, and the merged pipeline doesn't get the expected 512 Steam/t!
As far as I can tell, what happens is the following:
- Merged pipe pressurizes partially.
- One of the pipes above the boilers ticks first, and fills the merged pipe.
- The other pipe ticks, can't fill the merged pipe because there isn't enough space for all the steam, and the steam gets stuck.
I tried a bunch of different pipe sizes, nothing worked.
Honestly at this point it feels like the pipe tooltip capacity is false advertising, because I pretty much haven't gotten the advertised bandwidth ever...
I was under the impression that tanks did fill with half the fluid in a pipe, because of this tidbit:Quote
Fluid Pipes have their Tank Capacity halved, but they still transfer the same amount of Fluid per Tick.
DRAINS NEED TO BE ON PIPES TWICE THE SIZE TO WORK PROPERLY!!! (unless they are in an Ocean, Swamp or River)
This will also affect filling of vanilla Cauldrons (334L) and Advanced Worktables, as you need a Pipe twice the size for that now.
But filling tanks with half the fluid in a pipe would cause bandwidth issues if I understand it correctly:Code
- - Assuming 200L pipes
- - Pipe 2 is attached to something that can fill it entirely
- - Tank values taken after distribution but before filling tank
- Current impl: ||| Filling tanks with half the fluid in a pipe:
- Tick | Tank | Pipe1 | Pipe2 | EBW ||| Tick | Tank | Pipe1 | Pipe2 | EBW
- 0 | 0 | 200 | 200 | - ||| 0 | 0 | 200 | 200 | -
- 1 | 200 | 100 | 200 | 200 ||| 1 | 100 | 150 | 200 | 100
- 2 | 300 | 100 | 200 | 100 ||| 2 | 175 | 138 | 200 | 75
- 3 | 400 | 100 | 200 | 100 ||| 3 | 244 | 134 | 200 | 69
- 4 | 500 | 100 | 200 | 100 ||| 4 | 311 | 134 | 200 | 67
- 5 | 600 | 100 | 200 | 100 ||| 5 | 378 | 134 | 200 | 67
- 6 | 700 | 100 | 200 | 100 ||| 6 | 445 | 134 | 200 | 67
So, if tanks filled with half the fluid in a pipe after distribution, it would mean the bandwidth gets cut to 1/3 the tank capacity.
The posted solution worked though: using two pipes throttles the fluid per tick to expected values. So if fluid pipes don't change, I can effectively "abuse" this to get an additional set of pipe bandwidths to play with.
A steam turbine has an internal fluid tank whose capacity being 4x larger than the maximum steam/t input of the turbine. Fluid pipes try to fill up this tank whenever possible.
When ticked, a turbine tries to consume the entire steam its tank has without regard to the fullness, as long as the amount is not less than the minimum input rate. The consumed steam turns into RU. And if the amount of RU just produced exceeds the maximum output rate, the turbine gets overloaded and shrieks.
This mechanic makes sense to me, but what doesn't make sense is the fact that it implies the turbine is getting more than 192 Steam/t.
The setup is like this:
= Invar Steam Turbine (accepts 48-192 Steam/t)
= Tiny Steel Fluid Pipe (100L/t)
= Steel Fluid Pipe, full of steam (600L/t)
I see no way for the Invar Steam Turbine to get more than 100L Steam per tick, because the steam input per tick is bottlenecked by a Tiny Steel Fluid Pipe - and yet it "overloads" and shrieks.
Yeah exactly, it does notify of neighbour changes, but the range is only adjacent blocks, not really going through opaque Blocks
Old post, but this is a bug isn't it? It makes the following setup not work:Changelog 6.07.17 wrote:
[ADDED] The Thaumometer can now be Shelved too. However its Stupid about it and doesnt wanna let you rightclick it...
Isn't that caused by this?Changelog 6.06.07 wrote:
[CHANGED] Any Rightclick on a GT6 TileEntity with a Thaumometer will be ignored entirely, so you dont have to hold shift for scanning GT6 Stuff anymore.
One boiler for each machine. This may seem costly but is way easier to setup and operate.
Well, the cost is not a big issue - I just think it's odd that fluid pipes, which supposedly can go in numerous directions, don't work as advertised unless you only use them in a straight line or build with a massive number of tank extenders/shutter covers (which require Aluminium for whatever reason and you are no longer building intricate steam networks when you can craft them.)
Can shutters be moved down the tech tree a bit, so that they are in the same tech level as drain covers (or at least, a one-way valve)? Shutter technology definitely predates distillation towers IRL.
Why is the Invar Steam Turbine not getting a required amount of steam (it makes screeching sound)? The Tiny Steel Fluid Pipe is consistently full of 200L steam, so it should be pushing 100L/t to the Steam Turbine, but the turbine keeps whining.
What's the general approach by which people ran multiple machines off the same main Steam supply? Or did everyone just rush Distillation Tower to store energy?
The Extender points to the RIGHT on this Picture, is that correct? Otherwise the Setup wouldnt work at all.
There's a straight line of steel pipes behind the boilers that the Extender is pointing to, unfortunately I didn't take a good screenshot.
And as an added Bonus, never connect two Fluid Pipes with an Extender, the Pipes are made to tick depending on their Coordinates (Even Pipes and Odd Pipes), so in this case they will work unpredictably in regards of Tick Order.
seregheru said earlier that "To combine two pipes use an extender - the extender ensures that both inputs are credited to the same face of the attached pipe section." - is that not correct?
Holy crap what kind of janky as hell Setup is that?!? This will cause all kinds of weird interactions depending on how full the Pipes are at the beginning.
The idea was to have a 600L/t pipe which will be fed up to 512 Steam/t, then I can branch off the main setup 100L/t at a time with tiny Steel Fluid Pipes to power up to 5 machines simultaneously - kind of like this:
Unfortunately since I apparently do not understand Fluid Pipes the setup does not work as I expected.
There you go. The pressure valve only opens when the pipe is full, and that means some steam is sloshing back towards the boilers. Add another tank extender before the pressure valve to stop that.
That's... unintuitive. But it does work, so thank you.
I ran into an unrelated problem though, and I was able to reproduce it in single player, but not consistently:
The Invar Turbine should work flawlessly, but instead it makes this absolutely horrendous screeching sound of a machine not getting enough energy and spams it every tick or something.
The only issue is I don't know what causes it. If I break the pipes and place them again, the problem sometimes goes away and sometimes doesn't. (In single player this sometimes fixes the problem and sometimes doesn't, in multiplayer I disassembled the whole thing multiple times and it never got fixed.)
What's even more confusing is the following:
psusi The wood pipe is distilled water in.
The extender goes into another Steel Fluid Pipe. I'm not sure what you mean by "configured", it's pointing at the steel fluid pipe.
The output is a straight line of regular steel pipes terminating with a pressure valve.
The pipe distribution code is only fully stable if each section of pipe receives input
from only one direction. If it receives input from 2 directions in a single tick then
it forgets the first one and only remembers the second. When it distributes its
contents, some will be distributed back in the first direction. Mostly, when you run
a pipe along the top of a row of boilers you will be saved by the fact that the boilers
tick first and that a pipe cannot distribute steam back into the boiler. However, it's
still possible to get instability. For a pipe running left to right to a consumer on the
far right, rightward distribution runs all the way to the consumer with constant
throughput, while leftward distribution can run only as far as the dead end.
Whether you get some initial leftward distribution, whether this leftward distribution
persists after the first few ticks, whether it all averages out to a constant rightward
output, or whether it creates an oscillation, all depends highly on the order in which
the pipe sections tick.
To avoid this, ideally limit steam carrying pipes to simple straight lines
with no branches, and if you must branch, only do so on the output side, never on
the input side. To combine two pipes use an extender - the extender ensures that
both inputs are credited to the same face of the attached pipe section. This way
it doesn't matter which input is most-recent or second-most-recent, as the pipe
section will remember the same input face either way. For extra safety, always place
a pressure valve on the section of pipe immediately above the boiler.
I did exactly this (merged steam input pipes with tank extender) but my boilers still overpressurize:
Each boiler is running off Distilled water and outputting 128L/t, Steel Fluid Pipes should have capacity of 300L/t, and yet left boiler pressure keeps increasing meaning steam is not being carried away quickly enough.
There are some Botania integrations that got missed out:
- Mana Pearl (mana-infused enderpearl) got missed out as a new Material
Elementium is Lv4 with 102400 durability and Terrasteel is Lv3 with 51200 durability, but this is backwards
- Elementium is very cheap to make, Terrasteel is the endgame ingot that takes a lot of effort to craft.
Elementium tools are also 720 durability in Botania whereas Terra tools have 2300, more than 3 times as much
(Terrasteel tools also do ridiculous stuff like mine 11x11x11)
- Elementium is very cheap to make, Terrasteel is the endgame ingot that takes a lot of effort to craft.
There may be more, but I have to go through the whole mod.
Plunger does not actually plunge fluid from pipes. It works on barrels but not pipes.
Scanned it afterwards, same deal.
The full setup:
That 1L of water is sloshing back and forth between those 3 pipes infinitely; if I hold down right click, it looks like the water does not move, because debug scanner scanning frequency matches up with how fast the water is sloshing around, but if I just right click scan same pipe with random intervals I can see the pipe is in one of those states.
I accidentally got water into my steam pipes (just a straight line of steel pipes with "branches"), so I attached a barrel to one end and allowed fluid to flow in.
However, the pipe was still clogged - I went and loaded a backup in single player, scanned the pipe and found that there was 1L of water flowing back and forth in the pipes but never entering the barrel.
For situations like this, is my only remedy to dismantle the whole pipe network, or is there a block/tool to clean out pipes that I am not aware of?
I don't think I tried it again after the first time. I will start adding in the mods I don't have in the current pack (IHL, Better Records, Qwertech, Minechem, Balkon's WeaponMod, Enviromine, etc.) and see if things work.
Greg, do you have any immediate plans for updating the GT6 Thaumcraft researches?
I was thinking of porting some of the Minetweaker changes I made for KR, but realized that I have to rewrite them for GT6 (due to different progression) and figured that it's probably best I asked you about it first since you will know how to balance your mod better than I would.
I'm in the GT Discord. I do not see your username there however.
I did not report it, because I don't know if it's a problem with the mod or my configs, and I was trying to get modpack into a working state.
I assume the "casing sharing" mechanic from previous versions of GT no longer works in GT6, because now you can actually pipe stuff into/out of the "casings"?
I had some Coke Ovens set up as follows, but only the rightmost one worked.
EDIT> GT adds these research to the Thaumonomicon right? I think they haven't been updated since at least GT5 (maybe GT4 even), and as a result there are some mismatches. It also seems like it is a bit incomplete, because Advanced Metallurgic Transmutation still unlocks only Aluminium and nothing else.
For example, Cupronickel is now Constantan, and the duplication recipes directly make nuggets which allows skipping of crucible smelting for a lot of the materials.
Chocohead I almost can't believe it, but I am absolutely elated to report that the patcher has completely eliminated the Thaumometer scanning lag; smooth 60FPS no matter what I'm doing now, and it scans GT items with 0 issues! I'll put it into my pack (which has the commonly used TC addons) and see what happens.
Even when I deliberately cause rendering lag (like looking at a cube of vanilla fences), my FPS is completely identical whether I am holding the Thaumometer or not, so it looks like the scanning lag is completely gone.
Thank you so much for the
magicalthaumaturgical patcher, you are amazing
EDIT> Minetweaker (Modtweaker?) does not like the patcher it seems - if you try to give an item aspects with their scripts (like Aspects.set(<Thaumcraft:blockTube:0>, "metallum 5, permutatio 2, vitreus 5, vinculum 2");), this happens:Code
- ERROR: Error executing TwilightAspects.zs: objectTags
- java.lang.NoSuchFieldError: objectTags
- at modtweaker2.mods.thaumcraft.handlers.Aspects$Add.apply(Aspects.java:57)
- at minetweaker.runtime.MTTweaker.apply(MTTweaker.java:70)
- at minetweaker.MineTweakerAPI.apply(MineTweakerAPI.java:169)
- at modtweaker2.mods.thaumcraft.handlers.Aspects.set(Aspects.java:31)
- at TwilightAspects.__script__(TwilightAspects.zs:10)
- at __ZenMain__.run(TwilightAspects.zs)
- at minetweaker.runtime.MTTweaker.load(MTTweaker.java:163)
- at minetweaker.MineTweakerImplementationAPI.reload(MineTweakerImplementationAPI.java:656)
- at minetweaker.MineTweakerImplementationAPI$1.execute(MineTweakerImplementationAPI.java:83)
- at minetweaker.MineTweakerImplementationAPI$19.execute(MineTweakerImplementationAPI.java:642)
- at minetweaker.mc1710.server.MCServer$MCCommand.func_71515_b(MCServer.java:124)
- at net.minecraft.command.CommandHandler.func_71556_a(CommandHandler.java:94)
- at net.minecraft.network.NetHandlerPlayServer.func_147361_d(NetHandlerPlayServer.java:739)
- at net.minecraft.network.NetHandlerPlayServer.func_147354_a(NetHandlerPlayServer.java:718)
- at net.minecraft.network.play.client.C01PacketChatMessage.func_148833_a(SourceFile:37)
- at net.minecraft.network.play.client.C01PacketChatMessage.func_148833_a(SourceFile:9)
- at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212)
- at net.minecraft.network.NetworkSystem.func_151269_c(NetworkSystem.java:165)
- at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:659)
- at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)
- at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:186)
- at fastcraft.u.a(F:289)
- at fastcraft.H.aq(F:36)
- at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:396)
- at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)