before I put this this in a bug thread... BC lasers

[KirinDave]

Compared to 1.4.x, as far as I remember:
- Generation of oil lakes has been moved from "only vanilla deserts" to a list of biomes that biome mods can interact with, allowing the pools to spawn in desert-like biomes from EBXL and BoP
- Generation of oil lakes has been added to swamps (and thus swamp-like extra biomes)
- Biomes which spawn oil lakes have had their chance of oil spouts increased by 50%
- Oceans have had their chance for oil spouts doubled
- "Large" spouts (unsure of what is "large enough") have a 25% chance of the shaft going past the oil bubble down to bedrock, where an infinite oil spring block is situated that will generate a bucket every couple minutes
- Desert oilfield and ocean oilfield biomes were introduced

And yet I just asked my entire player base using a map made with recent buildcraft and we can count the number of oil spouts on one hand and most of them are over water. So I guess we're just not as awesome at getting oil biomes. And even if we're just unlucky, it seems rough to handle it this way because of the way Forestry dictates how people settle. Normal/Normal biomes are prized.

That's because Buildcraft's power currently works nothing like a pneumatic system. In fact, it works 95% like Industrialcraft EU. It is pneumatic in flavor name only. Thus, if the intent is to differentiate, then weird systems like this one get invented.

The EU model is closer to Pneumatic power. Pressure based power: easy to store. One of the very oldest forms of mechanical power, in fact. So old that victorians were even making coffee and tea with it. You should see the clockwork driven siphon systems the french had. Quite beautiful.

 

[Flipz]

(and force them to use basic math, ermagerd!).

The real issue is Let's Players having to do math on camera. Do we really want to encourage that sort of behavior?

In any case, I feel like BC wants to increase time intensiveness to the point where I can't play minecraft for fun anymore. It's a delicate balance I grant, but...

I had that reaction when I realized (in my still very much early-midgame world) that Steve's Carts wants me to spend upwards of eleven diamonds on a simple tree farm if I don't want to use the weakest, most easily breakable tree cutter available. Of course, part of the sudden spike in intensiveness is due to mods like Dartcraft and Tinker's Construct actually making the early game friendlier to the more casual and/or time-restricted player--when those mods can't hold our hand anymore, the difficulty curve reverts to a sharper angle.

That said, the constant power draw is both a blessing and a curse to early-game players. On the one hand, a "run engines only when needed" model works well with extremely basic starter machinery--it's not that different from the manual fueling of furnaces (yes, I know most people just stick a stack of coal in and forget it until they run out of fuel--I'm more OCD about fuel efficiency, so I only smelt enough items to match a specific fuel supply). On the other hand, it makes getting into automation and the "high tech" of later-game functions MUCH harder--rather discouragingly so. I don't have the keen analytic mind necessary to make a truly automated system off the top of my head (like so many people here can), so adding even more fiddly mechanics slows me down exponentially.

On the other hand, leaving an engine to run while the machines have no load is wasteful anyhow--the new system just makes me even more aware of that.

 

[KirinDave]

On the other hand, leaving an engine to run while the machines have no load is wasteful anyhow--the new system just makes me even more aware of that.

This has always confused me. Why can't engines respond to pipe wire signals directly?

Buildcraft has all kinds of sophistication built into its gates. They're actually shockingly clever and well-supported! But then... you need to double your costs just to do elementary things. And it's double the time cost. And under this new system, building gates now introduces idle power draw and only a rather singular type of block from other mods can restrict power flow.

These changes would make a LOT more sense if I could do things like restrict power flow to a sub-network on command. For example, a rolling machine and the "Has work" trigger seem like a natural fit, but then you realize that for large power network's it's pretty unworkable.

I guess I wish I understood what Buildcraft's team actually had in mind for the future of the mod. I just got a cold glance and sharp words from CJ for just mentioning that I read his mod's blog and evidently I have to read every github commit to understand important mechanical changes. I just don't have time for that. So I wish maybe he could summarize what they PLAN to do wit the mod...

 

[Omicron]

You can actually do things with single gates in this new power system CJ implemented. You stick a gate (any gate) on a wooden conductive pipe and give it the "power requested -> redstone signal" trigger. This will cause the wooden conductive pipe to try and top off its 1,500 MJ internal buffer by activating adjacent engines. Once that is achieved, the redstone signal goes off and the engine shuts down. But if you have a machine requesting power somewhere in the network, the power will flow out of the buffer and the redstone signal stays on, keeping the engine running.

 

[esotericist]

You can actually do things with single gates in this new power system CJ implemented. You stick a gate (any gate) on a wooden conductive pipe and give it the "power requested -> redstone signal" trigger. This will cause the wooden conductive pipe to try and top off its 1,500 MJ internal buffer by activating adjacent engines. Once that is achieved, the redstone signal goes off and the engine shuts down. But if you have a machine requesting power somewhere in the network, the power will flow out of the buffer and the redstone signal stays on, keeping the engine running.

I was just thinking about how I remember seeing a video showcasing this functionality.. This feature, the 'power requested' event for gates, seems almost diametrically opposed to the change that causes constant power drain.

I can't fathom the reasoning.

 

[Loufmier]

I can't fathom the reasoning.

my guess is to encourage use of gates and pipes where they were never needed.

 

[cynric]

my guess is to encourage use of gates and pipes where they were never needed.

Requiring a crossmod way (redstone energy cells or TC bridges) of shutting off the power flow to machines ... or building seperate networks for every machine?

 

[esotericist]

my guess is to encourage use of gates and pipes where they were never needed.

That can't be the reasoning, because the 'power requested' functionality WOULD have gotten me to use more gates. But it's now irrelevant, because power will essentially ALWAYS be requested, because things never stop wanting it.

 

[KirinDave]

You can actually do things with single gates in this new power system CJ implemented. You stick a gate (any gate) on a wooden conductive pipe and give it the "power requested -> redstone signal" trigger. This will cause the wooden conductive pipe to try and top off its 1,500 MJ internal buffer by activating adjacent engines.

See, but aren't all these machines asking for 1mj/t? So aren't they constantly tapping that? They're constantly requesting power. You need Has Work? to explain this to the gate properly, right? This approach USED to work, but it sounds like it won't now.

Or is there two types of power request in the network now?

 

[Loufmier]

That can't be the reasoning, because the 'power requested' functionality WOULD have gotten me to use more gates. But it's now irrelevant, because power will essentially ALWAYS be requested, because things never stop wanting it.

it seems i`ve missed the "always drain" part... with this requirements this condition is indeed useless in most cases, but if TE wont be draining power as they are now, i`m pretty it will have its purpose.

if power switch pipe(add. pipes) is in play, you could use it to cut off machines demand when its inventory is empty via gate, and thus switching "request power" condition on another gate at engines pipe.

 

[Omicron]

Well yes. You can't avoid the idle drain with that gate condition. You can, however, drop down from 10 running engines to 3 running engines automatically when all your machines stop working and drop idle, without the need for gates on both ends or pipe wire or upgrading the gates to iron.

 

[KirinDave]

Well yes. You can't avoid the idle drain with that gate condition. You can, however, drop down from 10 running engines to 3 running engines automatically when all your machines stop working and drop idle, without the need for gates on both ends or pipe wire or upgrading the gates to iron.

Does this actually work? It's my understanding that the tick ordering for engines will be somewhat unpredictable. Many Buildcraft engines have power outputs based on efficiency curves, the relevant variable being "time running".

Is it even more efficient to turn your engines on and off? For railcraft it CERTAINLY won't be. For buildcraft, I'm not sure anymore.

These changes are poorly documented and change basically every assumption and understanding of buildcraft. I'm not saying they're bad, but I honestly have no idea what they mean.

 

[Omicron]

It works with combustion engines. They're instant on, instant off. They also have a fairly high fuel efficiency, so in some setups it might be possible to consume less fuel with a set of self-regulating combustion engines than with a liquid fuel boiler of matching output that must always be on full blast regardless of power requirements.

As for other engines, I'm not sure. I haven't really played too much with it, just some cursory tests to know what to expect when.

 

[KirinDave]

It works with combustion engines. They're instant on, instant off. They also have a fairly high fuel efficiency, so in some setups it might be possible to consume less fuel with a set of self-regulating combustion engines than with a liquid fuel boiler of matching output that must always be on full blast regardless of power requirements.

As for other engines, I'm not sure. I haven't really played too much with it, just some cursory tests to know what to expect when.

This is untrue. They cannot turn back on while cooling down, and they do have an efficiency curve.

 

[Omicron]

Since when do they have an efficiency curve? Can you describe it? Because I've never seen one, nor behavior that suggests so.

 

[KirinDave]

Since when do they have an efficiency curve? Can you describe it? Because I've never seen one, nor behavior that suggests so.

You can measure it. It's small. But even if that's the case, it doesn't matter. The cooldown behavior totally kills this plan. Unless they removed it, your idea wouldn't have ever worked ever. Since like 1.2.* buildcraft, old tekkit days.

 

[Omicron]

How can I measure it?

I am fairly sure that in every measurement I've done so far, the combustion engine has given me exactly 600,000 EU per bucket of fuel, and 200,000 EU per bucket of ethanol. It can do so only if every single tick, down to the first one, outputs its full 6 (or 5) MJ of power, and the amount of fuel allows for every single tick to happen that is supposed to happen for one bucket of fuel. If at any point the combustion engine did not generate full power for a tick, or ran less ticks than intended off of a mB of fuel, then the result should be less than 600k / 200k, and consistently so by the same amount.

Mind you, I have not tested combustion engines since 1.4, because they always just worked.

The cooldown issue can be solved by throwing more engines at the problem. Since they only run when power is requested, the excess ones will not run unless the normal ones are in cooldown while more power is being requested.

(Also, please keep in mind that I'm not disagreeing with you that the system as it is is a big step backwards. I'm simply trying to explain the mechanics as they are intended right now, and recounting what I was told when I asked about the reasons for the change.)

 

[KirinDave]

The cooldown issue can be solved by throwing more engines at the problem. Since they only run when power is requested, the excess ones will not run unless the normal ones are in cooldown while more power is being requested.

I guess I will have to try building it. I suspect this does not work even a little bit because the "power requested" signal and subsequent redstone updates will propagate to the engines faster than power can feed through the BC network to satisfy it.

(Also, please keep in mind that I'm not disagreeing with you that the system as it is is a big step backwards. I'm simply trying to explain the mechanics as they are intended right now, and recounting what I was told when I asked about the reasons for the change.)

No I appreciate that. I just do not think the proposed build will work for a network of reasonable size.

 

[gattsuru]

Basic BuildCraft engines have stable efficiency unless their internal storage caps: it is power output frequency that change. Same for Forestry Engines. For most people, cycle frequency doesn't matter terribly, and won't effect efficiency significantly. ((There are rare cases where it is relevant for very small networks with disparate devices, outside the scope of this thread.)) Steam Boilers are the only ones you really have to watch out for from a pure fuel efficiency standpoint. Combustion Engine cooldown can be a big deal from a different perspective, but they can also store a stupid amount of energy internally, don't drain that energy store unless they're running, so it's more a number of making larger banks to adjust for potential downtime.

The nasty trick is that powerPerdition occurs on the wooden pipe interface alone (and, obviously, adds up rather quickly), making it very tricky to work around even by completely removing consumers from the network. Turning engines off completely, having multiple small networks, and then only putting in enough total energy to complete a batch of work, is the only real way to avoid losses.

 

[SpitefulFox]

Forestry's Multifarm machines are set to have no passive power draw. Other than that, yes, you'll want to have discrete networks, or assume 1 MJ/T idle draw per machine.

Ironically, isn't the Multifarm the one machine you'd reasonably expect to have constantly running?