[Feature Request] Controllable power pipe conduction rules
ReikaKalseki opened this issue · 12 comments
I am making a pack where I wish to have several "tiers" of power progression, and use BuildCraft power pipes for several of those tiers.
Essentially, what I would like is a way to control, pipeside, "minimum passable currents" (i.e. any RF/t less than this is ignored, maybe lost) or (more complicated but powerful) the ability to sort energy providers and receivers into tiers, where a receiver can only receive from a provider of its tier (or greater).
As a side note, does enabling the "classic" power pipe resistance turn off the pipe limits? If not, I would like that as an option too, to further replicate "original" BC.
The "classic" power pipe resistance brings back the BC pre-3.7.0 algorithm verbatim, including no pipe limits (or, rather, a limit of 1024 MJ/t)
As for tiering, why not extend BC's pipe classes and make an addon mod?
No. You just create a new Pipe, and register it using
BCTransport's methods. All you have to do is implement potential behaviour
overrides/event listeners. The rendering/logic is automatically done for
you. Look at ABO or AdditionalPipes.
2015-12-11 21:05 GMT+01:00 Reika [email protected]:
The "classic" power pipe resistance brings back the BC pre-3.7.0 algorithm
verbatim, including no pipe limits (or, rather, a limit of 1024 MJ/t):D
As for tiering, why not extend BC's pipe classes and make an addon mod?
I have no idea how BC network logic - pipe, item, or otherwise - works,
and would I not have to reimplement all of that, plus all of the renderers,
myself?—
Reply to this email directly or view it on GitHub
#3155 (comment)
.
OK, so I have found out that yes, registering custom pipes is easy.
However, I am at a bit of a loss as to how to accomplish my goal; while I could easily implement new "tiered" pipes that only could receive from their tier or higher, and could only power their tier or less, I was hoping to make it feel like original BC. Or is there a way to simply, say, replace the wooden transport pipe with a variant that "tells" the rest of its network "I am receiving from a Tier 2 engine, do not supply any power to Tier 3 or higher machines"?
Put more simply, I have found the simple energy I/O methods which could be put to use, but nothing more network-level, which was what I was hoping for in order to make the tiered pipes nonetheless feel like "vanilla" BuildCraft.
What I suggestes you do is to simply, say, make your own wooden transport pipe, then hide the original one away.
(Also, BuildCraft power pipes don't really have a network per se. It works more like redstone in the sense of per-block signal propagation than a graph.)
Yes, replacing the wooden pipe is the simplest and cleanest, but how would I use that to enforce the tiering? Is there some "additional data" I could pass on like "do not power a machine if it is in this set", for example?
It sounds somewhat similar to the IRedstoneEngine setup, where various machines cannot receive if the provider is a redstone engine.
@ReikaKalseki - Probably not. That's why redstone engines don't connect to pipes. You'd probably have to rewrite PipeTransportPower, create your own pipes with that transport, then use the pipeTransportRendererMap to use PipeTransportPower's default renderer with your class.
:/
Is there any way for a wooden pipe to know what it is connected to, outside a simple recursive search?
The "classic" power pipe resistance brings back the BC pre-3.7.0 algorithm verbatim, including no pipe limits (or, rather, a limit of 1024 MJ/t)
:D
As for tiering, why not extend BC's pipe classes and make an addon mod?
I have no idea how BC network logic - pipe, item, or otherwise - works, and would I not have to reimplement all of that, plus all of the renderers, myself?
@ReikaKalseki - No.
Yeah unfortunately you would probably have to implement your own graphing for pipes. I'm guessing that you no longer need this though @ReikaKalseki so I'm going to close this as its outside of BC's scope.
Pushing for BC pipes being the central pipe type caused something of a revolt anyways...
