I recently got back into playing GC and noticed that only the original BC/IC2/GC cables/pipes were supported for sealed versions. This surprised me, as the the modding/modpack landscape has changed quite a bit in the two years since I tried my hand with GC content last and AE2, Thermal Dynamics and Ender IO are the more prominent cables/ducts/conduits used in modpacks now days. Considering IC2 has been on decline for sometime (and isn't even included in some modpacks anymore) and MJ went the way of the dinosaurs over a year ago, would it be possible to see sealed versions of cables/ducts/conduits/etc in GC?
[Suggestion/Request] Sealed pipe/cable support for AE2, TD, EIO, etc
- Thread starter CrazyTolradi
- Start date
This has been requested before ...
I would find it helpful if someone listed the exact cable / pipe types which a player might need in a space base, and explain why there is not another way to seal them.
It doesn't help me to say "EnderIO", because that has many different types of cables and pipes. I'm not going to implement support for them all, and I don't play the mod much myself so I don't know which types players are choosing. Also my understanding is that EnderIO has its own type of sealed block / cable bundle, and also wireless transmission. So the EnderIO guys could support Galacticraft's ISealableBlock API function on that sealed block - did you ask them? Or the player or modpack maker can maybe set the block as a 'sealable block' in Galacticraft's config.
AE2's ME cable is already dormant in Galacticraft 3, not currently enabled but it just needs a small amount of coding to get that working again. I will do that some time soon.
Thermal Dynamics has the Tesseract so I've mostly assumed sealed versions of Thermal Dynamics wires + pipes are unnecessary. Again, that mod has 10 or more different types of pipe, so again I'm going to need suggestions for which ones actually need to be sealed. I'm not going to seal them all, maybe could look at the 3 or 4 most needed ones. I don't promise that any time soon. Again, it's work that could much more easily be done by the maker of that other mod.
I would find it helpful if someone listed the exact cable / pipe types which a player might need in a space base, and explain why there is not another way to seal them.
It doesn't help me to say "EnderIO", because that has many different types of cables and pipes. I'm not going to implement support for them all, and I don't play the mod much myself so I don't know which types players are choosing. Also my understanding is that EnderIO has its own type of sealed block / cable bundle, and also wireless transmission. So the EnderIO guys could support Galacticraft's ISealableBlock API function on that sealed block - did you ask them? Or the player or modpack maker can maybe set the block as a 'sealable block' in Galacticraft's config.
AE2's ME cable is already dormant in Galacticraft 3, not currently enabled but it just needs a small amount of coding to get that working again. I will do that some time soon.
Thermal Dynamics has the Tesseract so I've mostly assumed sealed versions of Thermal Dynamics wires + pipes are unnecessary. Again, that mod has 10 or more different types of pipe, so again I'm going to need suggestions for which ones actually need to be sealed. I'm not going to seal them all, maybe could look at the 3 or 4 most needed ones. I don't promise that any time soon. Again, it's work that could much more easily be done by the maker of that other mod.
Fair reply, I'm kind of surprised no one has given a list before.
EnderIO I don't use myself, I've just had players on my server whine at me about it.
I do have a slight workaround for AE2, using an ME Interface as an entry point into each sealed section/module and using P2P networks. Not ideal as the Interfaces add network overhead, ideally Sealed Dense ME Cables would be a good solution for end-game station/off-world builds.
As for Thermal Dynamics, I'd say the main sealed pipes I feel missing would be power and fluids. Tesseracts are a solution, as is making all the ducts as sealable in config (not workable for AE2 since all AE2 cables are items not blockls), but might not be the best aesthetically speaking.
In order of personal preference, TD sealed blocks that would be ideal are:
Sealed Cryo-Stabilized Fluxduct (Might be a pain to implement with since I've been told by the TARDIS mod dev that this duct is done in a hacky way)
Sealed Super-Laminar Duct
Sealed Resonant Fluxduct
Sealed Impulse Itemduct
There's no real reason for start-game sealed duct versions as by the time you're setting up a decent base off-world, you've very likely advanced past them.
EnderIO I don't use myself, I've just had players on my server whine at me about it.
I do have a slight workaround for AE2, using an ME Interface as an entry point into each sealed section/module and using P2P networks. Not ideal as the Interfaces add network overhead, ideally Sealed Dense ME Cables would be a good solution for end-game station/off-world builds.
As for Thermal Dynamics, I'd say the main sealed pipes I feel missing would be power and fluids. Tesseracts are a solution, as is making all the ducts as sealable in config (not workable for AE2 since all AE2 cables are items not blockls), but might not be the best aesthetically speaking.
In order of personal preference, TD sealed blocks that would be ideal are:
Sealed Cryo-Stabilized Fluxduct (Might be a pain to implement with since I've been told by the TARDIS mod dev that this duct is done in a hacky way)
Sealed Super-Laminar Duct
Sealed Resonant Fluxduct
Sealed Impulse Itemduct
There's no real reason for start-game sealed duct versions as by the time you're setting up a decent base off-world, you've very likely advanced past them.
OK, I'll take a look at some of that.
I can't comment on TD code, the last time I looked at it was almost 2 years ago, and it was a pain because it wasn't open source. I remember being unimpressed by the code at that time, it was laggy and had a lot of chunk loading bugs, so if you had a working network, went away from your base, and came back, you might have to break or wrench a block to get the network working again. I expect they've improved it by now.
It's also not clear why the player doesn't just use Galacticraft wiring? It's better than any Fluxduct, and probably less laggy for your server as well.
Item and fluid pipes (including ME) are more of a priority as Galacticraft does not offer those.
I can't comment on TD code, the last time I looked at it was almost 2 years ago, and it was a pain because it wasn't open source. I remember being unimpressed by the code at that time, it was laggy and had a lot of chunk loading bugs, so if you had a working network, went away from your base, and came back, you might have to break or wrench a block to get the network working again. I expect they've improved it by now.
It's also not clear why the player doesn't just use Galacticraft wiring? It's better than any Fluxduct, and probably less laggy for your server as well.
Item and fluid pipes (including ME) are more of a priority as Galacticraft does not offer those.
Did some testing with the player in question myself, since I haven't really touched this stuff in a while. Everything I've tested with today shows the sealed heavy aluminium wire more or less is as functional as a cryo fluxduct (unlimited pass throw in RF/T), although I did only throw 32k rf/t through it (I have RFTool setups that consume anything from 100k RF/T or more but not in setup in this server). Is this the case or is there an upper limit on how much juice heavy aluminium wires can pass through? The wiki seems to be a bit outdated and shows figures for back when Universal Electricity was a thing. Either way, the sealed wires are functionally fine from my PoV.
TD has changed a LOT since 2 years ago, and it's mostly done by RWTema now (ExUtils dev). I'd say by far they are the best duct to use server performance wise, EnderIO are more convenient but do add about 6us per conduit because of how they are coded (this is a documented issue on the EIO Github IIRC). They're easily on par performance/lag wise with BC pipes and far exceed them in terms of player use as the BC pipes have probably the lowest amount of MB/t passthrough out of the mods that offer transport functionality (BC is also a bit on the wane in terms of popular modpacks). If fluid pipes are a priority, I'd look perhaps at supporting TD Fluiducts over BC liquid pipes or just adding a generic GC fluid pipe in of itself. It's not really much skin off my nose either way personally, I use Extra Cells 2 fluid functionality over an AE network.
TD has changed a LOT since 2 years ago, and it's mostly done by RWTema now (ExUtils dev). I'd say by far they are the best duct to use server performance wise, EnderIO are more convenient but do add about 6us per conduit because of how they are coded (this is a documented issue on the EIO Github IIRC). They're easily on par performance/lag wise with BC pipes and far exceed them in terms of player use as the BC pipes have probably the lowest amount of MB/t passthrough out of the mods that offer transport functionality (BC is also a bit on the wane in terms of popular modpacks). If fluid pipes are a priority, I'd look perhaps at supporting TD Fluiducts over BC liquid pipes or just adding a generic GC fluid pipe in of itself. It's not really much skin off my nose either way personally, I use Extra Cells 2 fluid functionality over an AE network.
There is currently no limit on heavy aluminium wires, unless you are using them with IC2 installed and with IC2 energy sources - with IC2, they will limit themselves to a voltage limit somewhere between gold and glass fibre cable.
In future in Galacticraft's Hard Mode I plan to add a "current based" energy loss in heavy aluminium wires - like in the real world, where energy loss in wires is I squared R. So if you try to put very high amounts of juice through them, they still work but you lose some efficiency. Further reading: http://wiki.micdoodle8.com/wiki/Game_Balance#Hard_Mode
GC Energy Beams: There is a limit on how much energy one Beam Emitter can transmit. But the limit for what a Beam Receiver can receive is higher, so for insane levels of power, you can have multiple Beam Emitters all powering one Beam Receiver.
Most mods' energy systems place an exponentially increasing load on the server if you have a network with multiple energy emitters and multiple energy receivers on the same network.
So builds involving, for example, 100 low-powered generators, such as solar or wind generators or any of TD's generators, powering 30 machines, are usually a lag nightmare for servers. Especially if it's a multi-player server with several players with builds like that. If careful testing shows that the lag problem is reduced by feeding all the generators into one single energy storage box, and then powering all the machines in a base out of that energy storage box, then you know this is an issue.
To get mathematical, with E emitters and R receivers, the per-tick time required in most mods is a function of E x R. So in the above example, the per-tick time is a factor of 3000 higher on a large network with E = 100 and R = 30, compared with a simple 1 generator, 1 receiver network.
Galacticraft's wiring is specifically designed not to have this problem. In Galacticraft the per-tick time required by the wiring is a function of E + R.
If someone wants to run a server load test of a large network of TD ducts compared with Galacticraft wires in the same configuration, I'd be interested in the results. My guess is we will win, easily
But I didn't look at TD's code recently so I can't be sure.I have IC2 installed (purely to use Nuclear Control 2 for the alarms and displays) however IC2 hasn't had e-net limitations in terms of eu/t or power loss over cable for about 2 years now (e-net is apparently in the process of being rewritten).
You're right about the 100 low powered generators causing huge amounts of server lag, but it isn't just the power network that causes that. Usually it's the fact you have 100 odd tile entities stacking up what would be normally a small amount of lag into something of a major horrible mess, adding to the power network lag. This is always my reasoning for why Big Reactors and Advanced Generators were inevitable and, at least on my server, preferable. Anyone on my server who did a such a laggy build would login to find it removed and a note saying "Build a damn BR if you need that much power". TD dynamos can at least be upgraded to output 640RF/t each IIRC, so aren't as much of a problem with people spamming them.
I'd be happy to set up a test server at some point in the next few days and try out a comparison with 100 low power generators and 30 power using blocks using GC cables and TD ducts if you'd like. It might not be until after the weekend as a supercell storm is hitting my area in the next day or two and it's possible there will be some interruptions to power/net.
You're right about the 100 low powered generators causing huge amounts of server lag, but it isn't just the power network that causes that. Usually it's the fact you have 100 odd tile entities stacking up what would be normally a small amount of lag into something of a major horrible mess, adding to the power network lag. This is always my reasoning for why Big Reactors and Advanced Generators were inevitable and, at least on my server, preferable. Anyone on my server who did a such a laggy build would login to find it removed and a note saying "Build a damn BR if you need that much power". TD dynamos can at least be upgraded to output 640RF/t each IIRC, so aren't as much of a problem with people spamming them.
I'd be happy to set up a test server at some point in the next few days and try out a comparison with 100 low power generators and 30 power using blocks using GC cables and TD ducts if you'd like. It might not be until after the weekend as a supercell storm is hitting my area in the next day or two and it's possible there will be some interruptions to power/net.
Ok, did a test run today. The setup was 100 Magmatic Dynamos in ten vertical rows of ten (100 x 80rf/t for 8000rf/t) powering 15 Redstone Furnaces (15rf/t per) and 15 Pulverisers (40rf/t per) processing cobble into stone, then the stone into cobble, etc. I made two of this setup, each in it's own chunk with no differences except one would only use Heavy Aluminium Wire (HAW) and the other would use Cryo-stabilised Fluxduct (CSF). On the HAW setup, I used two sealable HAW blocks (one where all power would go to from the Dynamos, the other where all power would go into for the machines) to simulate typical use of two sealed modules on a space station level, assuming seperate modules for power generation and resource processiong. All of this would take place inside a Void dimension (The Last Millennium dimension from the Extra Utilities mod) as to remove any impact any other TE or entities would have in the results.
Picture of setup: http://i.imgur.com/bl2eTWc.jpg
This was done on a server running Forge 1566, Fastcraft 1.22 test 18 and Better FPS 1.1.1. The only other entity when results with Opis were taken was the player, which was in its own chunk next to the two setups. As TD ducts don't show as Tile Entities, I decided to go off chunk timing instead. I was actually surprised by the results. I admit, I did go in expecting the TD fluxducts to perform better than the GC wiring.
TD chunk with machines active: 365 microseconds/tick
GC chunk with machines active 169 microseconds/tick
TD chunk with machines not active 195 microseconds/tick
GC chunk with machines not active 95 microseconds/tick
Looking at those results, there's an obviously large relative difference in performance going on. On chunk timing basis, the GC wire is clearly better in terms of performance. The only weird anomaly I found is that one of the dynamos in the GC cluster would have a major timing difference compared to all the others, sitting at anything from 150-170 microseconds in entity timing. On server reloads, it would be a different dynamo too. Not sure as to the cause of that.
I'll be doing some more testing, this time with more realistic in game scenarios as no one would bother to make 100 RF generating blocks which only make 8000RF combined (IIRC a fully augmented dynamo can generate about 665RF/t). Also I think having a capacitor/storage/buffer might increase performance, but I could well be wrong. At the least it looks like I now have a new go to wire/duct/conduit for RF.
EDIT: Putting in a Resonant Energy Cell (from Thermal Expansion) between the Dynamos and Machines really improved things for the Fluxducts.
TD chunk with machines active with REC: 220 microseconds/tick
GC chunk with machines active with REC: 153 microseconds/tick
Not a lot of improvement for the GC chunk, but damn that brought the TD chunk down to levels near what was seen with the machines being inactive. Having 30 machines demand power from one source, and one source demanding power from 100 instead of 30 machines pulling from 100 separate really improved their performance.
Picture of setup: http://i.imgur.com/bl2eTWc.jpg
This was done on a server running Forge 1566, Fastcraft 1.22 test 18 and Better FPS 1.1.1. The only other entity when results with Opis were taken was the player, which was in its own chunk next to the two setups. As TD ducts don't show as Tile Entities, I decided to go off chunk timing instead. I was actually surprised by the results. I admit, I did go in expecting the TD fluxducts to perform better than the GC wiring.
TD chunk with machines active: 365 microseconds/tick
GC chunk with machines active 169 microseconds/tick
TD chunk with machines not active 195 microseconds/tick
GC chunk with machines not active 95 microseconds/tick
Looking at those results, there's an obviously large relative difference in performance going on. On chunk timing basis, the GC wire is clearly better in terms of performance. The only weird anomaly I found is that one of the dynamos in the GC cluster would have a major timing difference compared to all the others, sitting at anything from 150-170 microseconds in entity timing. On server reloads, it would be a different dynamo too. Not sure as to the cause of that.
I'll be doing some more testing, this time with more realistic in game scenarios as no one would bother to make 100 RF generating blocks which only make 8000RF combined (IIRC a fully augmented dynamo can generate about 665RF/t). Also I think having a capacitor/storage/buffer might increase performance, but I could well be wrong. At the least it looks like I now have a new go to wire/duct/conduit for RF.
EDIT: Putting in a Resonant Energy Cell (from Thermal Expansion) between the Dynamos and Machines really improved things for the Fluxducts.
TD chunk with machines active with REC: 220 microseconds/tick
GC chunk with machines active with REC: 153 microseconds/tick
Not a lot of improvement for the GC chunk, but damn that brought the TD chunk down to levels near what was seen with the machines being inactive. Having 30 machines demand power from one source, and one source demanding power from 100 instead of 30 machines pulling from 100 separate really improved their performance.
Last edited:
Did some more testing with this setup: http://i.imgur.com/KDRKHfg.jpg
TD Two Dynamos (max upgraded 2x 640RF/t) with Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 7 microseconds per tick
GC Two Dynamos (max upgraded 2x 640RF/t) with Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 36 microseconds per tick
TD Two Dynamos (max upgraded 2x 640RF/t) with inactive Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 6 microseconds per tick
GC Two Dynamos (max upgraded 2x 640RF/t) with inactive Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 22 microseconds per tick
One dynamo on the GC setup: 25 microseconds per tick (TD side has its at 2 microseconds a tick)
I then added a Resonant Energy Cell between the machines and the dynamos as before.
TD Two Dynamos (max upgraded 2x 640RF/t) with one Resonant Energy Cell, an active Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 34 microseconds per tick
GC Two Dynamos (max upgraded 2x 640RF/t)with one Resonant Energy Cell, an active Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 9 microseconds per tick
One dynamo at 20 microseconds/tick and Energy Cell at 12 microseconds/tick on the GC setup. (TD's dynamos average at 2 microseconds again with the energy cell at about 5 microseconds a tick)
I'd say that if you have an unmanaged huge setup with a staggering amount (i.e 100) of inputs and a wide range of extractors from the network, GC is superior. However, in a more reasonable managed setup, there does seem to be a strange overhead with GC cables being connected and TD is a definite winner in terms of performance here. The original setup in my post above is a very unlikely situation to occur in game. No one spams 100 or so generators anymore (not without being booted from a server for their trouble anyway) and even if someone did, it's very likely they'd still use some kind of capacitor/buffer which changes it from 30 machines drawing from 100 inputs (3,000 possible exchanges at once) to 30 machines drawing from one input (30 exchanges_ on one network and one machine drawing from 100 (100 exchanges) inputs on the other.
TD Two Dynamos (max upgraded 2x 640RF/t) with Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 7 microseconds per tick
GC Two Dynamos (max upgraded 2x 640RF/t) with Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 36 microseconds per tick
TD Two Dynamos (max upgraded 2x 640RF/t) with inactive Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 6 microseconds per tick
GC Two Dynamos (max upgraded 2x 640RF/t) with inactive Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 22 microseconds per tick
One dynamo on the GC setup: 25 microseconds per tick (TD side has its at 2 microseconds a tick)
I then added a Resonant Energy Cell between the machines and the dynamos as before.
TD Two Dynamos (max upgraded 2x 640RF/t) with one Resonant Energy Cell, an active Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 34 microseconds per tick
GC Two Dynamos (max upgraded 2x 640RF/t)with one Resonant Energy Cell, an active Redstone Furnace (max upgraded 400RF/t) and Pulveriser (Max upgraded 800RF/t) 9 microseconds per tick
One dynamo at 20 microseconds/tick and Energy Cell at 12 microseconds/tick on the GC setup. (TD's dynamos average at 2 microseconds again with the energy cell at about 5 microseconds a tick)
I'd say that if you have an unmanaged huge setup with a staggering amount (i.e 100) of inputs and a wide range of extractors from the network, GC is superior. However, in a more reasonable managed setup, there does seem to be a strange overhead with GC cables being connected and TD is a definite winner in terms of performance here. The original setup in my post above is a very unlikely situation to occur in game. No one spams 100 or so generators anymore (not without being booted from a server for their trouble anyway) and even if someone did, it's very likely they'd still use some kind of capacitor/buffer which changes it from 30 machines drawing from 100 inputs (3,000 possible exchanges at once) to 30 machines drawing from one input (30 exchanges_ on one network and one machine drawing from 100 (100 exchanges) inputs on the other.
Wow, I didn't seriously expect you to carry out the test described. Interesting that you did, though.
Your first test (the large setup) is performing exactly as I expected. Apart from GC being better the interesting thing is that TD was able to improve its performance simply by adding in a single Resonant Energy Cell - again as I expected.
Your second test I am very surprised at the results, I would expect the two mods to be about the same in a simple 2 machine power network, or possibly the GC wiring fractionally slower because it is doing cross-mod power conversion twice, to get the energy into the GC system and out of it again. (That's not too complex, it's just looking up the conversion factor and multiplying by it - that should take nanoseconds.) Certainly the differences should not be so extreme. I'm concerned about this, will have to test it myself. Can you list the modlist you used for this test?
It's also possible that TD is so "fast" in the second test because it doesn't check each tick that the power network is still intact and what is now connected to it. In that case it's not really a fair test, because it means with TD you will have chunkloading issues and other potential problems when placing / breaking machines.
Your first test (the large setup) is performing exactly as I expected. Apart from GC being better
the interesting thing is that TD was able to improve its performance simply by adding in a single Resonant Energy Cell - again as I expected.That is intended + expected behaviour. Each tick one of them has to go first into the power network - you could think of it as a pathfinder. It's doing two things. First it checks what is still connected to the power network - because any tick, machine blocks could have been broken or rotated or inputs switched on or off, or new machines could have been added to the network. Second, it asks each connected machine how much power it requires that tick. Some of the tick time you are attributing to GC could be caused by the Redstone Furnaces responding slowly to that power request, I'm not sure, though it might be interesting to try the same test with the Galacticraft Electric Arc Furnace in place of the Redstone Furnaces and see if there's a speed improvement.
Your second test I am very surprised at the results, I would expect the two mods to be about the same in a simple 2 machine power network, or possibly the GC wiring fractionally slower because it is doing cross-mod power conversion twice, to get the energy into the GC system and out of it again. (That's not too complex, it's just looking up the conversion factor and multiplying by it - that should take nanoseconds.) Certainly the differences should not be so extreme. I'm concerned about this, will have to test it myself. Can you list the modlist you used for this test?
It's also possible that TD is so "fast" in the second test because it doesn't check each tick that the power network is still intact and what is now connected to it. In that case it's not really a fair test, because it means with TD you will have chunkloading issues and other potential problems when placing / breaking machines.