Thermal Expansion Status

[SynfulChaot]

Building many differing entire systems is fun to some. Simplifying down to as few as possible and continually improving their efficiency is fun to others. I'm in that second camp. I like building for efficiency in both space and server load. So I always strive for as few networks as possible.

Last map it was IC2 solars for most things and converting with electric engines on the fly when I needed MJ. Current map it is solely my boilers for MJ and I'm avoiding all use of IC2. I'm not yet sure what I'll do on 1.6/1.7. I guess it'll depend on the mods.

For converting DC to AC or vice versa, yes, 25% is way too high. But for converting electrical energy to pneumatic pressure or to thermal energy, I'd say it is probably way too low.

Electric to pneumatic isn't that much of a loss. Just requires a compressor. Thermal can be a bit more of a loss, but induction heating is very efficient.

 

[PhilHibbs]

Electric to pneumatic isn't that much of a loss. Just requires a compressor. Thermal can be a bit more of a loss, but induction heating is very efficient.

So if you compress air into a cylinder, then use that compressed air to generate electricity, how much of the original power would you expect to get back? I'd be astonished if you could get close to 50% even with the very best kit.

 

[SynfulChaot]

So if you compress air into a cylinder, then use that compressed air to generate electricity, how much of the original power would you expect to get back? I'd be astonished if you could get close to 50% even with the very best kit.

Much higher than that.. Compressed air energy storage is a thing. Theoretical efficiency of 100% and actual efficiency of 70% for one implementation. I couldn't find 'in-practice' numbers for the other implementations.

 

[Zarkov]

For Power Converters (or a similar mod) to really work perfectly, you would have to have maybe 25% loss on all producers and have no steam converters. Also, having better names and models (actual BC engine pl0x) would be great.

It's already working perfectly, for me at least Perhaps you mean "work realistically"? I'm not that concerned of that, given that I can punch down trees and run around while carrying smaller mountains.

 

[SonOfABirch]

The problem with universal power is: which system do you want to become universal? MJ? EU? Blutricity?
Or do you make your own system like UE did?

Way ahead of ya

 

[DaeDroug]

Is the problem that there are too many different kinds of power networks or that there is too little ability for simple, if lossy, conversion?

Neither, to use an analogy i used earlier some mods are using meters and others are using feet but no one knows how many feet are in a meter. It ends up that it's too easy for there to be exploits when converting from one to another.

While we're exchanging opinions here, I'll add mine - I don't think a unified power API is conducive to creativity and diversity. It's a bit of a catch-22... if you standardize a lot, then you're limiting the designs, but if you're trying to avoid limiting the designs then you can't standardize much at all and the exercise threatens to become pointless.

I have no idea where you're getting this from, by definition you'd be releasing designs from being constrained to one mod for everything in that mod. Making it so you can power things from one mod with things from another wouldn't limit anything it would increase the options you had. Really the -only- thing it would limit is the amount of redundant wiring you have to do but if wiring is why you play minecraft then i just have to say whatever floats your boat.

I also don't feel like I'm missing power conversion in my life. I haven't ever used Power Converters - personally I tend to call it "overPowered Converters" - and I haven't used any power bridging mod at all ever since the days of 1.2.5, a little over a year ago. I tend to be someone who builds small, efficient setups, just enough to do the job. To do the most I can with as little input as possible, that's my favorite design challenge. As such, I generally build a lot less infrastructure than some others. If I only had one power system to build, I would run out of things to design within a day or two! I rather have a mod environment where I need to build up something new a couple times in any given world in order to access all the features I want.

Again I'm baffled as to why you would think inter mod power would reduce the amount of things you'd have to build, presumably you'd still want all of the things you built in each of those systems, and presumably you'd still need power for them. You could build one gigantic power plant if you really wanted to with inter mod power available but I, like i'm sure many others would, would build different power plants every time I needed to increase the amount of power my base needed. Not only that but there'd be nothing stopping you from being like, "hmmm I'm using up my uranium too fast, i should diversify my power into using some fuel, maybe some coal use too." Again the only thing that would be reduced is the amount of redundant wiring.

 

[Omicron]

I can offer you a lot of technical explanations for many gameplay-related areas.

The above, however, is a personal opinion. I can offer little more explanation than to reiterate that it is what I feel about the topic. It is of course perfectly fine for you to disagree You offer valid points, but they wouldn't count for me - I'd be naturally driven to centralize on one power source just because the general building paradigm I follow (call it German OCD if you will). I'd only branch out if I was forced to do so by resource constraints. However, considering I specialize in small, low-power setups, chances are I'll never run out of any one fuel type, even if it's not an infinite loop.

 

[LordBlackHole]

I, personally, (not an official opinion!) would like to see a Forge power API like LordBlackHole is suggesting, with one exception:

The API includes a check to see if the energy sender and receiver are using compatible types of power. If the receiver is happy with the power type, great, everything goes as described; if not, no connection is made, and no energy calculations are made at all.

I like that there are different power systems in FTB, and that they do (mostly) different things; I also like the idea of converting power from one network into another, via a machine. I don't want an "all-in-one" setup, but I'd like an API that standardizes the code so that a.) it's easier for mod makers to switch power systems from one to another and/or support multiple power systems if they want to, b.) it's easier to track down and fix bugs, and c.) it makes power conversion more consistent by using a pre-set unit of power from within Vanilla as the standard for all power.

I had thought of that actually. I'd be super easy to add that.

For Power Converters (or a similar mod) to really work perfectly, you would have to have maybe 25% loss on all producers and have no steam converters. Also, having better names and models (actual BC engine pl0x) would be great.

I'll make it configurable with a master config that applies to all others ok? And I'm thinking 5% just like TE did.

Oh yes, any block that turns one kind of power into another should totally look like a cross between those two mods. Like, imagine a Buildcraft engine that looks a lot like a normal engine but with a texture that seems an awful lot like a Bat Box, and then when you open the GUI it looks very much like the Bat Box GUI, except it also has a tab on the side just like Buildcraft or Forestry engines.

That said, I'm a terrible artist, just awful, so while I'm confident I can do most of the hard machine code for the TileEntities and such, I will absolutely need other people to create the textures, models, and other stuff. Ok, I've decided that I need to make a new thread for this idea, as this thread belongs to King Lemming and Thermal Expansion and this is getting way off topic. Any suggestions on where a new thread should be made?

 

[DaeDroug]

I'd be naturally driven to centralize on one power source just because the general building paradigm I follow (call it German OCD if you will). I'd only branch out if I was forced to do so by resource constraints. However, considering I specialize in small, low-power setups, chances are I'll never run out of any one fuel type, even if it's not an infinite loop.

I really am trying to see it your way but from my point of view these two sentences are pretty contradictory, you say you specialize in small, low-power setups with i'm assuming varied power generation, and yet you say that you'd end up with one big power generator with all the energy coming from one source.

 

[Omegatron]

Back in the olden days of 1.2.5, that's exactly what Power Converters did and looked like. You had electric engines for EU -> MJ and pneumatic generators for MJ -> EU. The main reason it changed, I believe, was to facilitate more energy types like UE power and Factorization charge in a way that was simpler and more modular. At least, if I'd made the decision, that's what my reasoning would've been.

You are thinking of the transformers mod. Power converters used to have an energy link and engine generator which were both full blocks.

 

[Eyamaz]

I had thought of that actually. I'd be super easy to add that.


I'll make it configurable with a master config that applies to all others ok? And I'm thinking 5% just like TE did.

Oh yes, any block that turns one kind of power into another should totally look like a cross between those two mods. Like, imagine a Buildcraft engine that looks a lot like a normal engine but with a texture that seems an awful lot like a Bat Box, and then when you open the GUI it looks very much like the Bat Box GUI, except it also has a tab on the side just like Buildcraft or Forestry engines.

That said, I'm a terrible artist, just awful, so while I'm confident I can do most of the hard machine code for the TileEntities and such, I will absolutely need other people to create the textures, models, and other stuff. Ok, I've decided that I need to make a new thread for this idea, as this thread belongs to King Lemming and Thermal Expansion and this is getting way off topic. Any suggestions on where a new thread should be made?

Mod Discussion

 

[Drawde]

I really am trying to see it your way but from my point of view these two sentences are pretty contradictory, you say you specialize in small, low-power setups with i'm assuming varied power generation, and yet you say that you'd end up with one big power generator with all the energy coming from one source.

I think Omicron means that whenever he needs something that needs a different source of power he builds it instead of simply hooking it up to his current system. So if he was currently using IC2 and needed a Rolling Maching for RC tanks, he enjoys creating a small MJ power source to run it as opposed to simply making one block to convert EU to MJ. Something that requires him to construct a whole new system instead of one block.

 

[SpoonsJTD]

I am going to drop my $0.02 on the whole energy conversation. Some of this will be overlapping, especially with what some of LBH and KL have said.

I think one of the issues with even having the discussion is that it seems that many are conflating two different issues: 1) that there is no standard code development framework for energy/power management and 2) there is no standard unit of energy that is adhered to. While solving #1 might help with #2, that isn't necessarily the case, and so solving #2 isn't necessarily solved by implementing #1.

#1 is a barrier to integration. #2 can be a barrier to integration if the fact of #1 isn't addressed already with a good API provided by the various energy implementations, but #2 is what can cause what has been described as the lack of balance between mods, especially when convertors are developed, because it becomes the job of the convertor to define the conversion rate.

I think this is important to the discussion, because people confuse the two, and make arguments for #2 when they are really talking about solving #1, and vice versa.

I also think the barriers to solving #1 are not technical, despite the talk of 'well, which do you use, EU, MJ, Blutricity, etc.' Those are really points made in the discussion of #2. Solving #1 wouldn't necessarily be any of those. To solve #1, it's not about which system seems more balanced and has the better 'feeling' system when playing minecraft, it's about how well does the underlying code allow you to do what you want. Typically, a system developed without considering #1 won't end up being a good candidate to solve #1 because it will be designed in such a way to support the specific mechanisms it is implemented to have. Now, an experienced developer might end up with a decent solution for #1 while developing a specific instance, because he/she may recognize that creating a good framework will help with future development when things change with that specific implementation.

#2 can be a little more difficult to solve because it's hard to standardize how much energy is needed to perform some tasks. Macerating ores might be easy because so many mods do it, but how do you define how much energy it takes to wash ores based on how much energy it takes to macerate them (to use an IC2 example)? And if maceration results in different products, even standardizing that can be difficult. Maybe a standard on 'how much energy does it take to turn one ore into one ingot', but even that will have issues.

Having said all that, having a #1 IMO would be a good idea, and can be done in such a way that it can support a large number of styles and mechanisms without restricting 'creativity'. At its base, there are only so many ways to represent energy being generated and consumed at the code level. There are lots of patterns that can be applied that could let people design systems as complicated or as simple as possible and still use the same base framework.

 

[MigukNamja]

By default BC4 is slightly "leaky". However, you can set it to 0 a couple of different ways. While perdition is only for energy slowly "leaking" out per-tick rather than a flat-tax on a transfer of energy, CJ did indeed provide a recent update (because of this very thread !) for a %-based transfer "cost" or "tax":

used -= used * getPerdition().getTaxPercent();

source : https://github.com/BuildCraft/BuildCraft/blob/master/common/buildcraft/api/power/PowerHandler.java

However, I don't believe BC4 power would be accepted by all mod devs as a satisfactory power system because it's a per-block, per-tick power system and that's why the machines closest to the engines receive more power than those farther away and why you can store power in a BC4 pipe loop. Neither IC2 nor TE work this way. But, if IPowerHandler were effectively merged with, i.e. implemented, a "the power network is just 1 big pipe" like TE2.x (and hopefully TE3 !), *and* the mod dev got to choose which power to pull from/push to, it woud be great.

But, you can't simultaneously have a block-by-block, cable-by-cable power system and a "each individual cable pieces doesn't matter - it's only the connections that matter" system. They are effectively mutually exclusive, i.e. on different planes/channels.

In practical terms, if one were to merge a BC4 energy pipe with a TE pipe, you'd have to choose which system to put energy into and which system to pull energy out of. You couldn't have both at the same time.

As an analogy, you can choose to make a website an English or in French or have both on the same website, but then it wouldn't be a single website, but a mish-mash of the two. Forums, for instance, would be not unified, but you'd have to have a French forum and English forum. Unless, of course, everyone was bilingual, but the analogy to that would be requiring all modders to have bilingual code and support a BC4-style of power and TE-style of power.

Ditto for an IC2 power that involves 'voltage levels' (packet sizes) and machine/wires blowing up when the wrong packet size is connected, that would be yet a 3rd paradigm and a 3rd set of APIs.

 

[SpoonsJTD]

By default BC4 is slightly "leaky". However, you can set it to 0 a couple of different ways. While perdition is only for energy slowly "leaking" out per-tick rather than a flat-tax on a transfer of energy, CJ did indeed provide a recent update (because of this very thread !) for a %-based transfer "cost" or "tax":

used -= used * getPerdition().getTaxPercent();

source : https://github.com/BuildCraft/BuildCraft/blob/master/common/buildcraft/api/power/PowerHandler.java

However, I don't believe BC4 power would be accepted by all mod devs as a satisfactory power system because it's a per-block, per-tick power system and that's why the machines closest to the engines receive more power than those farther away and why you can store power in a BC4 pipe loop. Neither IC2 nor TE work this way. But, if IPowerHandler were effectively merged with, i.e. implemented, a "the power network is just 1 big pipe" like TE2.x (and hopefully TE3 !), *and* the mod dev got to choose which power to pull from/push to, it woud be great.

But, you can't simultaneously have a block-by-block, cable-by-cable power system and a "each individual cable pieces doesn't matter - it's only the connections that matter" system. They are effectively mutually exclusive, i.e. on different planes/channels.

In practical terms, if one were to merge a BC4 energy pipe with a TE pipe, you'd have to choose which system to put energy into and which system to pull energy out of. You couldn't have both at the same time.

As an analogy, you can choose to make a website an English or in French or have both on the same website, but then it wouldn't be a single website, but a mish-mash of the two. Forums, for instance, would be not unified, but you'd have to have a French forum and English forum. Unless, of course, everyone was bilingual, but the analogy to that would be requiring all modders to have bilingual code and support a BC4-style of power and TE-style of power.

Ditto for an IC2 power that involves 'voltage levels' (packet sizes) and machine/wires blowing up when the wrong packet size is connected, that would be yet a 3rd paradigm and a 3rd set of APIs.

It would be difficult to do if you tried to let different systems on each others energy nets, but there's no reason, gameplay or programmatically, you couldn't have two nets interface at a single point, even with ones that distribute power based on different rules.

I think my #1 and #2 could be solved above, but I think a #3 being that people want all mods to have all their machines work on every power network the same is a straw man of sorts that is not very doable, but not what people really want if I understand it correctly. I could be wrong.

Edit: Also, as to "that would be yet a 3rd paradigm and a 3rd set of APIs" -- not necessarily. 3rd paradigm yes, 3rd set of API's, no. There is no reason both BuildCraft and IC2's power systems couldn't be built from a same common "energy development framework". They would both have different implementations of a theoretical 'PowerDistributionStrategy', but that doesn't mean it would require a completely separate API (framework).

 

[Omicron]

I think I'll pass on the new power tax thingy... I'm already spending near 50% of my power output just on idle upkeep, I don't need even more loss

8 lasers - 4 MJ/t
1 thermionic fabricator - 8 MJ/t
4 carpenters - 4 MJ/t
2 squeezers - 2 MJ/t
1 centrifuge - 1 MJ/t
1 fermenter - 1 MJ/t
1 still - 1 MJ/t
------------------------------------
Total: 21 MJ/t idle power perdition (13 without thermionic fabricator)

And that's not counting the 2 multifarms, 1 rolling machine and 15 wooden kinesis pipes, all of which have miniscule loss too and add up to maybe another 0.3 - 0.5 MJ/t.

I just upgraded my 44 MJ/t setup to an 48 MJ/t setup today.

 

[MigukNamja]

Spoons,

I, too, would love to see a basic/common power/energy API that enough modders could agree upon that it would gain widespread acceptance. Each modder wouldn't be limited to that API, but would/could of course expand on it.

However, I don't know how you'd solve the problem of an engine connected to a Unified BC4+TE+IC2 cable with 2 of more machines/consumers connected to it and have it work as expected (i.e. satisfy) all mods. I'll use the most commonly used mods BC, TE, and IC:

Question 1 : Should the closest machine receive more power than the one further away ?

BC4 : absolutely yes, but cable length doesn't matter
TE2 : no
IC2 : yes, but based solely upon distance and cabling

Question 2 : Should a machine or cable blow up if connected wrong ?

BC4 : Not by design, no. A "too-small" pipe, however, will throttle it down
TE2 : no
IC2 : If packet size is wrong, yes

I don't think a single API could satisfy all 3 of those mods, and that doesn't include other power systems from other mods. So, I think you'd have to go with 1 power system that would probably *not be accepted by a sufficent % of mod devs *or* you'd have to support mutually exclusive APIs and effectively have merge pipes.

A good example of the former of a truly common API is PowerConvertors.

A good example of the latter is that mod where different kinds of transport pipes share the same space and make for more compact/clean setups (I forget the mod name - please accept my apologies !)

 

[SpoonsJTD]

Spoons,

I, too, would love to see a basic/common power/energy API that enough modders could agree upon that it would gain widespread acceptance. Each modder wouldn't be limited to that API, but would/could of course expand on it.

However, I don't know you'd solve the problem of an engine connected to a Unified BC4+TE+IC2 cable with 2 of more machines/consumers connected to it and have it work as expected (i.e. satisfy) all mods. I'll use the most commonly used mods BC, TE, and IC:

Question 1 : Should the closest machine receive more power than the one further away ?

BC4 : absolutely yes, but cable length doesn't matter
TE2 : no
IC2 : yes, but based solely upon distance and cabling

Question 2 : Should a machine or cable blow up if connected wrong ?

BC4 : Not by design, no. A "too-small" pipe, however, will throttle it down
TE2 : no
IC2 : If packet size is wrong, yes

You are right. But that isn't a problem of not having a common development API/framework, that is a problem of having different distribution strategies. One energy net that allows any machine to be put on any other's net is a bit of a pipe dream, pun intended. It could be done if everyone agreed on a single energy paradigm, but that is the #3 I described above. I supposed I should walk back from it not being what people want. It's probably more accurate to say it's not something that is terribly doable, no matter how much people would want it because no two modders are going to agree on one common paradigm.

I think with a common framework though, you could achieve much better interoperability than what we have now.

Edit: Expounding on that comment a bit ...

With a common framework, it would allow things like 'wrapping' -- so I could create a 'machine wrapper' or 'adapter' that wraps/adapts another mods machine and allows it to be placed on my net, consume energy my way, and then just forward on the request to 'do work' to the original machine. This can be done today, but not in a generic dynamic way because you need a separate implementation for every single mod. With a common framework with a common interface, any machine that implemented the interface could be 'adapted'.

 

[MigukNamja]

...pipe dream, pun intended

Now *that* is a great name for such a mod !

 

[RavynousHunter]

Honestly, I'd have an issue if BC4 power were the end-all, be-all power source for mods that use energy. Why? I, personally, don't like tick-based systems. They're clunky, inefficient, and in my opinion, inelegant. If you ask me, it almost borders on a kludge. Yes, event-based systems are more difficult to implement, and they require more upkeep and may be more prone to bugs, but their inherent efficiency, using resources only when they're actually needed, outweighs any developmental difficulties that might arise from their creation and implementation. Its why I don't like how Minecraft used to (don't know if that's still the case from 1.6 onward) handle the texture library, by sending it to the graphics card every tick, or roughly 20 times every second. Yes, it works, but its inefficient. Inefficiency in the case of graphics can be lethal to a game's performance, since graphics typically requires the most horsepower outside, perhaps, AI.

That said, if that's the course that the BC team wants to go with their power system, such is their right. Its their mod, and they can do with it what they please. They tend to listen to the addon developers and end users, which is a definite plus, but at the end of the day, the decisions on what goes in and what doesn't is theirs and theirs alone. I'll not be using MJ for my mod's power, mostly because I want it to be more independent, and I don't want it to be seen as direct competition with Railcraft and/or Thermal Expansion. Of course, I may consider implementing a solution to convert my mod's power to MJ, and likely also to EU, UE power, and Charge, if I can; cross-mod compatibility is always a good way to boost a mod's usefulness. Hell, if I could, I'd even like to find a way to convert my power to Blutricity, if Elo would allow it, since I'm quite fond of RedPower.