Measure MJ/Conductive Pipes

[MrZwij]

King Lemming, it's been said many times, but it's worth repeating: Thanks so much for coming here and posting openly and talking about your mod. It makes a world of difference to get the word "from the horse's mouth."

You're a bit deliberately vague on your wiki ... want to clarify now? Do I have it right that redstone energy conduits lose 5% of their power regardless of distance?

 

[jnads]

You're a bit deliberately vague on your wiki ... want to clarify now? Do I have it right that redstone energy conduits lose 5% of their power regardless of distance?

There's is a flat 5% fee at the point of consumption. Meaning, if you have 40 Conduits connected to to a machine, the 5% is extracted every time the machine requests power.

The "final" conduit effectively stores 1000MJ, and I think the 5% is extracted when that charges.


I am unsure as to whether, if you have a Redstone Energy Cell in between, if there are 2 5% deductions. It doesn't make sense, but I don't know how it's implemented, since there would be 2 1000MJ buffers (unless the RE Cell looks like Conduit to the system and there indeed is only 1 buffer).

 

[Zelfana]

The BC wiki is crazy wrong now - Golden pipes lose 0.5% per length; conduits become better after 10 blocks. Of course, there are other reasons to use it even for shorter runs.

I'm looking at redoing conduit a bit, we'll see.

Hot damn, that's ridiculous. In that light the conduits are a clear winner for most uses. But if you're bound to get losses anyway why not just lower the output of engines and remove losses in short enough pipes.

The original problem is still the lossy nature of conductive pipes and no way to storage MJ within BC itself.

I am unsure as to whether, if you have a Redstone Energy Cell in between, if there are 2 5% deductions. It doesn't make sense, but I don't know how it's implemented, since there would be 2 1000MJ buffers (unless the RE Cell looks like Conduit to the system and there indeed is only 1 buffer).

I would like to know this as well. It is easily tested but I don't have any modpack working right now due to the recent updates breaking everything.

 

[King Lemming]

There's is a flat 5% fee at the point of consumption. Meaning, if you have 40 Conduits connected to to a machine, the 5% is extracted every time the machine requests power.

The "final" conduit effectively stores 1000MJ, and I think the 5% is extracted when that charges.


I am unsure as to whether, if you have a Redstone Energy Cell in between, if there are 2 5% deductions. It doesn't make sense, but I don't know how it's implemented, since there would be 2 1000MJ buffers (unless the RE Cell looks like Conduit to the system and there indeed is only 1 buffer).

You are correct on the loss math - it's a flat 5%. However, this does mean you catch a double penalty for using a Cell in-line - the 5% loss happens twice. I'm not sure if that's really as horrible as it sounds. Let's be honest, BC power isn't that hard to make, and the inability to store it did factor into the initial balancing of it.

I'll likely revisit conduits to have more of a scaling power loss, such that very large networks will surpass 5 or even 10%, and very small ones will be < 1%. The trick is doing so in a computationally friendly manner.

 

[jnads]

You are correct on the loss math - it's a flat 5%. However, this does mean you catch a double penalty for using a Cell in-line - the 5% loss happens twice. I'm not sure if that's really as horrible as it sounds. Let's be honest, BC power isn't that hard to make, and the inability to store it did factor into the initial balancing of it.

I'll likely revisit conduits to have more of a scaling power loss, such that very large networks will surpass 5 or even 10%, and very small ones will be < 1%. The trick is doing so in a computationally friendly manner.

Thanks.

I still like them for the wood-extracts-gold-feeds headache, always running back to my chest because I forgot one or the other (and now the not exploding).

But I will take the 5% in account in my design (I tend to double-buffer as a IC2 habit).

Yeah, it's stupid-easy to abuse cross-mod and get effectively infinite power in any number of lag-friendly ways (Advanced Solar/Magmacrucible/Railcraft Tank/Geotherm or SoulShardBlazeFarm/Steam Boiler/Steam Engine or StevesCarts-or-ThaumcraftGolem/Peat-Tree-Sugar-Farm/BioFuel).

The only people who argue about efficiency are purists.

 

[MilConDoin]

You are correct on the loss math - it's a flat 5%. However, this does mean you catch a double penalty for using a Cell in-line - the 5% loss happens twice. I'm not sure if that's really as horrible as it sounds. Let's be honest, BC power isn't that hard to make, and the inability to store it did factor
into the initial balancing of it.

My inline cell isn't of the conduit -> cell -> conduit type, but the conduits are also connected. So the cell will only jump in when the conduits drain, otherwise they will transport the energy directly to the target. I don't know the inner workings of when what computation is done, but this seems to reduce the loss. The cell stays full, while it was slowly draining in the other setup.

I'll likely revisit conduits to have more of a scaling power loss, such that very large networks will surpass 5 or even 10%, and very small ones will be < 1%. The trick is doing so in a computationally friendly manner.

How do your conduits know, to which network they belong? Do you have a central information storage (CIS) and each conduit knows "I belong to network 325", while the CIS knows, that network 325 is 24 conduits long in total (regardless of the number of junctions)? Then just:

onReceivePower(int energyGained)
{
  energyStored += CIS.getEfficiency(network)*energyGained
}

with the getEfficiency function using some simple formula to compute the penalty from the network size.
This should be easy on the CPU.

 

[King Lemming]

There is no centralized conduit anything - that would mean having to deal with a counter, which risks numerical overflow conditions.

The conduit networks are actually shapeless infinitely scalable multiblock entities which can dynamically resize smoothly as chunks are loaded and unloaded. That's why frames wreck them.

As far as using a getEfficiency function, I'm afraid that's too inefficient. It would be more optimal to pre-compute that value, store it in the gestalt grid object and directly apply it to the computation when necessary. Or, it could be precomputed for any given conduit, stored in that conduit, and then called using an accessor.

In either cases, the CPU cost is frontloaded at the expense of memory, and that's always the balancing act. Given that servers are far more CPU limited, I'm happy to use memory instead.

 

[Saice]

Conduits still lose too much power imo. You can never reach the 5% loss of conduits with golden conductive pipes in a realistic situation.

Sure but they never blow up.... ever.

That right there is worth the 5% loss in power.

If they had cables of IC2/GT that auto stepped to the exact power needs of the machines. I would totally use them even if they had a 5% or even 10% power lost to them. Why? Well because stuff not blowing up is a huge draw for me and I can always just and an extra engine or generator to make up for that lost.

 

[lolpierandom]

Aren't conduits usually 10% loss in the way people use them? 5% lost to the cell, another 5 to the machines- though I suppose you save a lot more than 10% just by having that buffer in the middle catching excess.

Still, conductive pipes lose absurd amounts of energy + explosions, so meh.

 

[Hydra]

I just want to quickly step in here and point out that the current state of BC pipes actually began when CPW pulled in MY fix for BC machines and then adjusted the pipes to have the new storage and explosion mechanic.

It was a very deliberate and intentional change; the chunk-loading problem is unfortunate. However, there absolutely is no jealousy - CPW and the rest of the BuildCraft guys are some of the best people in the community.

It's also worth pointing out that BC power may be getting a complete overhaul at some point here.

No matter what, the pipes are simply unusable right now in their current form.

I think that the TE conduits are 'just right'. Overcomplexity (like in IC2) or having to baby-sit some simple pipes (like in BC) gets in the way of fun. TE conduits balance cost and usefullness very well in my opinion.

 

[Roachy]

Aren't conduits usually 10% loss in the way people use them? 5% lost to the cell, another 5 to the machines- though I suppose you save a lot more than 10% just by having that buffer in the middle catching excess.

Not sure if machines requesting directly from cells incur the loss, but if they do, it would be 9.75%.

100 - 5% = 95
95 - 5% = 90.25

But from what I can tell the loss is incurred only when energy is "pushed" onto a conduit. So you would incur a double loss if the machine is requesting from a conduit which is requesting from a cell, which is requesting from a conduit which is requesting from something. However following this logic, if the originating conduit is disconnected from its power source, then you wouldn't technically lose the first 5%, because it would be sending its own stored power, which has already been "taxed".

 

[KirinDave]

Cool necro, bro.

 

[Roachy]

I did not notice. However if I came here on a Google search it stands to reason that others may as well who might benefit from further information. "Necro" really only has meaning if the thread is so old that the topic is moot.

 

[Avatar]

SNIP..

Completely off topic here, but gratz of 1k posts!

Back on topic, i do like the new changes lemming was talking about up der /\