Nope, the internal combustion engine, as denoted by the term "combustion" works through heat. Specifically, the property of heated gases to expand. This expansion pushes a piston. Thus converting the heat from setting gasoline on fire into mechanical energy.
Thermal Expansion Status
- Thread starter King Lemming
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
- Status
Nope, the internal combustion engine, as denoted by the term "combustion" works through heat. Specifically, the property of heated gases to expand. This expansion pushes a piston. Thus converting the heat from setting gasoline on fire into mechanical energy.
IMHO, an efficient GCD (greatest common divisor) energy/power API would not be a bad thing in Forge. Modders would/are free to ignore/extend if they like to put their features in they like.
A good example is 3x3 shaped crafting. Anyone can register a 3x3 shaped crafting recipe in their mod via CraftingManager.addRecipe(...) or any of its Forge wrappers and indeed pretty much every mod adds to the recipe database.
However, modders aren't limited to that and many have their own, specialized crafting machines or mechanics that use the 3x3 grid, such as the RC Rolling Machine, Forestry Carpenter and Thermionic Fabricator, and of course the Thaumcraft table and infusion alter. I believe the BC Assembly Table with lasers falls into this category as well.
But, I also admit I don't understand the complexities such a common API for energy/power might bring and indeed, it may have been attempted before and unintended consequences like exploding pipes may have been the result.
A good example is 3x3 shaped crafting. Anyone can register a 3x3 shaped crafting recipe in their mod via CraftingManager.addRecipe(...) or any of its Forge wrappers and indeed pretty much every mod adds to the recipe database.
However, modders aren't limited to that and many have their own, specialized crafting machines or mechanics that use the 3x3 grid, such as the RC Rolling Machine, Forestry Carpenter and Thermionic Fabricator, and of course the Thaumcraft table and infusion alter. I believe the BC Assembly Table with lasers falls into this category as well.
But, I also admit I don't understand the complexities such a common API for energy/power might bring and indeed, it may have been attempted before and unintended consequences like exploding pipes may have been the result.
Well, in the strictest sense, combustion means exothermic chemical reaction. Without being super pedantic and invoking e = mc^2, it really is chemical energy. Breaking the chemical bonds of fuel releases heat, which then drives the engine via a thermodynamic cycle.
True, I suppose it is important to differentiate the chemical source of the heat from a frictional or nuclear source. But ultimately it's the heat that's key to moving the pistons, not the mechanism that causes the gasoline to burn. Unlike, for example, an electric car which is driven by the conversion of electrical energy from a battery (again sourced by chemical energy within the battery) into mechanical energy.
Actually, I just thought about something. I wonder if it would be possible to run a small engine by creating heat through friction to cause a gas to expand. Horribly inefficient, of course, but an interesting project, no?
You cant realy own a unit of tesla... And if you own someone named Tesla id have to report you for slavery...
... or do you mean the electrical device?
An engine that runs by heat rather than combustion or water-->steam expansion is a Stirling Engine. Those are actually some of the most efficient engines out there and beat (internal) combustion engines by a long-shot in terms of pure efficiency. However, they don't have a sufficient power:size ratio to make sense in an automobile and aren't cost-competitive, either. Also, a combustion engine indeed produces heat, but the expansion is not purely heat, but a rapid expansion of the fuel when mixed with the oxidizer and ignited. The chemical explosion, i.e. exothermic chemical reaction of the fuel, is mainly what drives the expansion.
In a spark (gasoline) engine, it's the spark that triggers the chain reaction of combustion of the fuel, which causes rapid expansion of the fuel that drives the piston. In a diesel, it's the pressure that triggers the chain reaction. A true heat-base engine like a Stirling has no such chain reaction or explosion. The fuel slowly burns.
Engines work by converting some kind of power or fuel into motion. So you need an engine to generate the motion to generate the friction to generate the heat to expand the air to work an engine. Yeah, that's why it's inefficient. The more things to do things to do things, the lower the efficiency. Which is why I think Power Converters should be lossy. It would help reduce 'sploits as well.
I really feel like a lot of people are either missing the point or not understanding what a universal API could mean and do, so I'm going to do my best to explain what I think it means and how every current power system could convert to it without any users noticing the difference.
I think the API should define only two things.
1. A universal power unit, probably based on how many ticks a lump of coal burns in a furnace. (Most mods already do used units based on that, they just use different ratios).
2. Universal Interfaces to define how power can enter and exit tiles, items, and maybe other things.
For a full explanation on how I think the API should work, read my previous post here.
And now how all current systems can use that and still not seem to change. Let's start with IC2. I have used it's API in one of my own mods, Liquid Fuels, to power machines, so while I know a bit, I could make some incorrect assumptions, so please bear with me.
When you place an IC2 machine down into the world, it sends an "event" basically a message, saying it was added and giving it's world coordinates and a reference to itself. (Cables, storage and generators do the same)
A class in IC2 receives this message and says "ok, now are there any cables or power sources next to this machine?" If there are, it traces the cables back to the sources, either a storage blocks or a generators and say "here is a possible output, and here is how many blocks away it is (and maybe what kind of cable it is?)"
When the source ticks, it asks each of it's outputs, which could be storage block or machines, "hey, how much power do you need?" and if it does need some, it says "Ok, here it is!" and reduces the power based on the transmission loss and then passes what's left to the machine or block.
I THINK, although I could be wrong, but I think this is when a block asks "is this too much power for me to handle?" And if yes, it says "Uh oh, BOOM!" This might also be when cables short out. I'm not sure about that, but I'm pretty sure the cables don't every hold any power of their own. Power jumps from block to block in packets and doesn't exist inside the cables ever. This reduces lag.
Now, using the universal API, this is how it would work.
When you place a block, it won't do anything, but the cables next to it would notice and they would say "Hey new guy, are you a powered block?" If that block says "Yes, I'm a powered block" the cable will send an event to IC2 alerting it of the new block.
Then that same IC2 class catches the event and does the same tracing, but instead of going all the way to the source blocks, it would only go to the cables that touch source blocks.
When those source cables are ticked, they will ask the block next to them if it can emit any power. If that block says "Yes, I can emit this much!" Well, the cable will short if it's too much, but if it's not, it will check it's outputs saying "Do any of you blocks need power?" If one says "yes, I need this much" the cable will reduce the amount based on the cable length and then send the rest.
If that block is also an IC2 block, it can then check and say "Was I given too much power?" And if so, "Uh oh, BOOM!".
This might cause a bit of lag compared to the previous design, because the cables will have a lot more to do, and of course you'll have a lot more of them, but other than that, to a user it would seem identical. And here's the thing, nothing about the numbers needs to be different to the user. IC2 could still CALL it's power EU. It could still use the same GUIs, it could still say that machines use 32 EU per tick, or that Bat Boxes emit 32 EU per tick, and all that. It could either convert the units just for display, or it could convert them between each transaction (which could itself be used to provide a tiny amount of loss by always rounding down). In other words, when the cables receives power, it could turn it to EU and use that for transmission max and loss, then turn it back and give it to the next block. If that block is also an IC2 machine, it could turn it right back to EU to use for display, (or just convert it for display only and store the value in the universal units). A user won't even notice the difference. Cables would still have different capacities, machines could still blow up, the packet system would still work, and users would still see everything in EU, the only difference is that it could work with any other blocks from other mods using the API.
Now for Buildcraft, which again, I've used in Liquid Fuels, and I might make mistakes.
When a machine is placed, pipes next to it check "Hey, are you an IPowerHandler?" And if yes, they connect and save that connection. Engines do the same when placed, and they also try to point toward the first pipe or machine they find.
That machine MUST have a PowerHandler inside of it, and tell it how much power it can except, how much power it can store and other things like that.
A machine gets it's power from the PowerHandler, not storing it itself or communicating with the pipes or engines around it in any way. This is one of the things that King Lemming was not happy about since it means the PowerHander has FULL and TOTAL control on how power flows, is stored, and how the power "leaks" and there isn't much that any block can do if it doesn't like that.
A machine can also I THINK choose to tell the PowerHandler "Hey, get power please" At any time.
The PowerHander asks for any pipes next to it "Hey, can I have some power?" And those pipes can say "Yes, here you go" and give it to them.
The pipes themselves store power inside of them, with the different kinds of pipes storing different amounts and since they can all send their full amount that also changes how much power they can send. This is another thing King Lemming didn't like because it means each pipe is doing things and therefor more stuff is happening each game tick, meaning there is more lag than IC2's packet system.
Engines try to add the power they make to the pipes or machines they are pointed towards on their own time.
Now, using the universal API, this is how it would work.
When a block it placed next to a pipe the pipe will say "Are you a powered block?" and if yes it will point to it. And again, Engines will look for "Powered blocks" and point toward it.
When the pipe is ticked it will check first the blocks around it "Hey, do you need power?" And if yes, the pipe will give it to the block. After checking for blocks, it will check for pipes and pass it's power along to them just like it does now.
Engines will basically do the same for whatever machine or block they are attached to.
It wouldn't change how power flows through the pipes at all, only how the pipes talk to engines and machines. So machines could still "leak" if they want to, even if powered by another universal power system. And again, they could still call it MJ, translating it either for display or between inputs and outputs.
And not only would the two systems work exactly the same as they do now (to the user) they would work together. Because MJ doesn't explode or have loss, it might be good for pumping huge amounts of power long distances, while EU can be stored and generated on demand. So you could have a system using a nuclear reactor producing MJ when needed with a Gate, then pump that through pipes and store it in several MFSUs. They you can use pipes to pull the energy out and choke it to put the energy into IC2 machines, and since it's not limited by packets, it could move a lot more power. Or you could use EU to run forestry machines and have a simple redstone switch on a bat box to prevent power from leaking when you're not using them. Or use Steam Engines to power your IC2 Mass Fab, or use IC2 Solars to offset your Rolling Machine's power leak.
What I'm trying to say is that although they could each work on their own just as they do now, when combined one would not supplant the other, and neither would be obsolete, instead it would provide more freedom for users to combine the best parts of each mod to their own advantage.
And now, for Blutrcity! (Am I spelling that right?)
Eloraam once tweeted that professionally, she works as an Electrical Engineer, and it shows in Blutricity, which works almost exactly like real electricity.
In Blutricity, every block acts both as a cable and a battery, storing some amount of power and also transmitting it. Each "conductive" block stores it's own power, and each time it's ticked, it tries to balance it's power with it's neighbors. Machines and the Battery Box have extra storage when the normal cable storage gets above a certain point, and the battery saves its, or releases it if it's cable energy drops too low.
That's it really. Power flows as a machines uses it and reduces it's store of power, drawing from the cable and causing the cable next to it to try to give it enough power to keep them balanced, then the cable next to it tries to give it enough power to balance and so on and so on until it reaches the generator.
Really, with a universal API, Blutricity would only need to change the ways each cable talks to each other using the new API. Fundamentally it wouldn't have to change at all. This would mean that not only could you power IC2 or MJ machines with Blulectric cables, but a Blulectric machine would power the machines next to it without needing any other cables at all. Use EU to power THAT and you've got an Alloy Furnace that also powers the IC2 machines touching it.
A few more power systems. I think that King Lemming's redstone conduits and presumably the new Redstone Flux system works a lot like IC2, so I don't feel the need to explain it again, plus I'm not very sure. Universal Electricity also works a lot like EU, with packets and stuff. Again, I'm not very filmier with UE so I'm not 100% sure of that. I also am not sure about Factorization Charge, but I think it's basically just like Blutricity.
So, in conclusion, I argue that while yes, it will take a lot of work to translate these systems to a new API, it would be possible to do so without changing the fundamental ways in which they work. They could all still be unique and have their own advantages and disadvantages. I don't think that converting them to work together would make any of them obsolete or prevent any of them from losing any features. In fact, I believe that the ability to combine these mods will allow for much more user customization and the freedom to mix-and-match different systems will make each one shine brighter and be more useful together then they could be apart.
Sorry for creating such a huge wall of text, it's just who I am. And thank you to anyone who put in the effort to read the whole thing.
I think the API should define only two things.
1. A universal power unit, probably based on how many ticks a lump of coal burns in a furnace. (Most mods already do used units based on that, they just use different ratios).
2. Universal Interfaces to define how power can enter and exit tiles, items, and maybe other things.
For a full explanation on how I think the API should work, read my previous post here.
And now how all current systems can use that and still not seem to change. Let's start with IC2. I have used it's API in one of my own mods, Liquid Fuels, to power machines, so while I know a bit, I could make some incorrect assumptions, so please bear with me.
When you place an IC2 machine down into the world, it sends an "event" basically a message, saying it was added and giving it's world coordinates and a reference to itself. (Cables, storage and generators do the same)
A class in IC2 receives this message and says "ok, now are there any cables or power sources next to this machine?" If there are, it traces the cables back to the sources, either a storage blocks or a generators and say "here is a possible output, and here is how many blocks away it is (and maybe what kind of cable it is?)"
When the source ticks, it asks each of it's outputs, which could be storage block or machines, "hey, how much power do you need?" and if it does need some, it says "Ok, here it is!" and reduces the power based on the transmission loss and then passes what's left to the machine or block.
I THINK, although I could be wrong, but I think this is when a block asks "is this too much power for me to handle?" And if yes, it says "Uh oh, BOOM!" This might also be when cables short out. I'm not sure about that, but I'm pretty sure the cables don't every hold any power of their own. Power jumps from block to block in packets and doesn't exist inside the cables ever. This reduces lag.
Now, using the universal API, this is how it would work.
When you place a block, it won't do anything, but the cables next to it would notice and they would say "Hey new guy, are you a powered block?" If that block says "Yes, I'm a powered block" the cable will send an event to IC2 alerting it of the new block.
Then that same IC2 class catches the event and does the same tracing, but instead of going all the way to the source blocks, it would only go to the cables that touch source blocks.
When those source cables are ticked, they will ask the block next to them if it can emit any power. If that block says "Yes, I can emit this much!" Well, the cable will short if it's too much, but if it's not, it will check it's outputs saying "Do any of you blocks need power?" If one says "yes, I need this much" the cable will reduce the amount based on the cable length and then send the rest.
If that block is also an IC2 block, it can then check and say "Was I given too much power?" And if so, "Uh oh, BOOM!".
This might cause a bit of lag compared to the previous design, because the cables will have a lot more to do, and of course you'll have a lot more of them, but other than that, to a user it would seem identical. And here's the thing, nothing about the numbers needs to be different to the user. IC2 could still CALL it's power EU. It could still use the same GUIs, it could still say that machines use 32 EU per tick, or that Bat Boxes emit 32 EU per tick, and all that. It could either convert the units just for display, or it could convert them between each transaction (which could itself be used to provide a tiny amount of loss by always rounding down). In other words, when the cables receives power, it could turn it to EU and use that for transmission max and loss, then turn it back and give it to the next block. If that block is also an IC2 machine, it could turn it right back to EU to use for display, (or just convert it for display only and store the value in the universal units). A user won't even notice the difference. Cables would still have different capacities, machines could still blow up, the packet system would still work, and users would still see everything in EU, the only difference is that it could work with any other blocks from other mods using the API.
Now for Buildcraft, which again, I've used in Liquid Fuels, and I might make mistakes.
When a machine is placed, pipes next to it check "Hey, are you an IPowerHandler?" And if yes, they connect and save that connection. Engines do the same when placed, and they also try to point toward the first pipe or machine they find.
That machine MUST have a PowerHandler inside of it, and tell it how much power it can except, how much power it can store and other things like that.
A machine gets it's power from the PowerHandler, not storing it itself or communicating with the pipes or engines around it in any way. This is one of the things that King Lemming was not happy about since it means the PowerHander has FULL and TOTAL control on how power flows, is stored, and how the power "leaks" and there isn't much that any block can do if it doesn't like that.
A machine can also I THINK choose to tell the PowerHandler "Hey, get power please" At any time.
The PowerHander asks for any pipes next to it "Hey, can I have some power?" And those pipes can say "Yes, here you go" and give it to them.
The pipes themselves store power inside of them, with the different kinds of pipes storing different amounts and since they can all send their full amount that also changes how much power they can send. This is another thing King Lemming didn't like because it means each pipe is doing things and therefor more stuff is happening each game tick, meaning there is more lag than IC2's packet system.
Engines try to add the power they make to the pipes or machines they are pointed towards on their own time.
Now, using the universal API, this is how it would work.
When a block it placed next to a pipe the pipe will say "Are you a powered block?" and if yes it will point to it. And again, Engines will look for "Powered blocks" and point toward it.
When the pipe is ticked it will check first the blocks around it "Hey, do you need power?" And if yes, the pipe will give it to the block. After checking for blocks, it will check for pipes and pass it's power along to them just like it does now.
Engines will basically do the same for whatever machine or block they are attached to.
It wouldn't change how power flows through the pipes at all, only how the pipes talk to engines and machines. So machines could still "leak" if they want to, even if powered by another universal power system. And again, they could still call it MJ, translating it either for display or between inputs and outputs.
And not only would the two systems work exactly the same as they do now (to the user) they would work together. Because MJ doesn't explode or have loss, it might be good for pumping huge amounts of power long distances, while EU can be stored and generated on demand. So you could have a system using a nuclear reactor producing MJ when needed with a Gate, then pump that through pipes and store it in several MFSUs. They you can use pipes to pull the energy out and choke it to put the energy into IC2 machines, and since it's not limited by packets, it could move a lot more power. Or you could use EU to run forestry machines and have a simple redstone switch on a bat box to prevent power from leaking when you're not using them. Or use Steam Engines to power your IC2 Mass Fab, or use IC2 Solars to offset your Rolling Machine's power leak.
What I'm trying to say is that although they could each work on their own just as they do now, when combined one would not supplant the other, and neither would be obsolete, instead it would provide more freedom for users to combine the best parts of each mod to their own advantage.
And now, for Blutrcity! (Am I spelling that right?)
Eloraam once tweeted that professionally, she works as an Electrical Engineer, and it shows in Blutricity, which works almost exactly like real electricity.
In Blutricity, every block acts both as a cable and a battery, storing some amount of power and also transmitting it. Each "conductive" block stores it's own power, and each time it's ticked, it tries to balance it's power with it's neighbors. Machines and the Battery Box have extra storage when the normal cable storage gets above a certain point, and the battery saves its, or releases it if it's cable energy drops too low.
That's it really. Power flows as a machines uses it and reduces it's store of power, drawing from the cable and causing the cable next to it to try to give it enough power to keep them balanced, then the cable next to it tries to give it enough power to balance and so on and so on until it reaches the generator.
Really, with a universal API, Blutricity would only need to change the ways each cable talks to each other using the new API. Fundamentally it wouldn't have to change at all. This would mean that not only could you power IC2 or MJ machines with Blulectric cables, but a Blulectric machine would power the machines next to it without needing any other cables at all. Use EU to power THAT and you've got an Alloy Furnace that also powers the IC2 machines touching it.
A few more power systems. I think that King Lemming's redstone conduits and presumably the new Redstone Flux system works a lot like IC2, so I don't feel the need to explain it again, plus I'm not very sure. Universal Electricity also works a lot like EU, with packets and stuff. Again, I'm not very filmier with UE so I'm not 100% sure of that. I also am not sure about Factorization Charge, but I think it's basically just like Blutricity.
So, in conclusion, I argue that while yes, it will take a lot of work to translate these systems to a new API, it would be possible to do so without changing the fundamental ways in which they work. They could all still be unique and have their own advantages and disadvantages. I don't think that converting them to work together would make any of them obsolete or prevent any of them from losing any features. In fact, I believe that the ability to combine these mods will allow for much more user customization and the freedom to mix-and-match different systems will make each one shine brighter and be more useful together then they could be apart.
Sorry for creating such a huge wall of text, it's just who I am. And thank you to anyone who put in the effort to read the whole thing.
Holy crap. Anyways, you're batting around .500 with some of that stuff, but you got the salient points. In general, I avoid tracing and packet routing at all costs - tracing only ever happens during a network rebuild.
Blutricity is indeed a lot like real electricity, and while I admire Elo for putting that in, I'm also an electrical engineer (in power systems, no less), and there's a reason I went with MJ initially. Feels more Minecrafty.
RF is basically going to be the same setup people already know - build dynamos or other sources, run conduit (currently 2 tiers of it), and power your stuff. We've revisited how conduit functions at a base level, and there's just no current way within Minecraft to build anything more efficient, period.
At the end of the day though, I'm still not sold on universal power. The advantages just aren't there for me.
Great write-up, LordBlackHole.
However, I think you hinted at one potential problem of a common/universal API : how to support a block-by-block power system like BC4 and connected graph power system like TE2 ?
One can see BC4 block-by-block in DW20's video of using a high-end BC4 pipe loop to store energy. I don't believe you can do the same with TE2 Energy Conduits. Rather, as KL described it earlier,a network of Energy Conduits is just that - a network. There is no per-block, per-tick calculation, but rather suppliers and consumers, with the conduit network as an obfuscated cloud in between. All a supplier and consumer must agree upon is whether they are connected to the same network or not. Hence, calculation can be done at placement time rather than every g-damn tick.
And, while TE2's Energy Conduits do store MJ, it's the entire network that stores MJ and not a single link/block. That's why when you use the TE meter to look at an energy conduit or liquiduct (same philosphy, it seems), you see the value for the network and not the individual link/block. Notice also how a liquiduct fills up and drains uniformly, not piece-by-piece like BC pipes. You don't get the same visual indication with energy conduits, but I'm pretty sure the kind of thing is going on.
I'm not sure how a common API could satisfy both methods other than *allowing* modders the option of either/or/both. Perhaps their engine or machine would simply join the network be a "network" TE2-like block. Or, it could be a BuildCraft-esque block-by-block device. And, while it could do both at the same time (network and block-by-block), it wouldn't fully satisfy both. When a machine wants power, for example, does it pull from its internal buffer, or does it simply put that machine in touch with an engine somewhere in the network, for example ?
While I think that gets the gist of it, I'm sure I have some details completely wrong, like "connecting consumers with producers" - that's probably not quite correct. Perhaps TE2's conduit network acts as one, huge "pipe" where all input is summed and all output (demand) is summed. Not sure.
But, one thing I do know is I highly prefer placement-time calculations vs. per-tick calculations. *ANY* code that runs per-tick has got to be treated as real-time code with the philosophy of it ain't absolutely necessary, then don't do it. The main MC loop *must* maintain 20 TPS.
However, I think you hinted at one potential problem of a common/universal API : how to support a block-by-block power system like BC4 and connected graph power system like TE2 ?
One can see BC4 block-by-block in DW20's video of using a high-end BC4 pipe loop to store energy. I don't believe you can do the same with TE2 Energy Conduits. Rather, as KL described it earlier,a network of Energy Conduits is just that - a network. There is no per-block, per-tick calculation, but rather suppliers and consumers, with the conduit network as an obfuscated cloud in between. All a supplier and consumer must agree upon is whether they are connected to the same network or not. Hence, calculation can be done at placement time rather than every g-damn tick.
And, while TE2's Energy Conduits do store MJ, it's the entire network that stores MJ and not a single link/block. That's why when you use the TE meter to look at an energy conduit or liquiduct (same philosphy, it seems), you see the value for the network and not the individual link/block. Notice also how a liquiduct fills up and drains uniformly, not piece-by-piece like BC pipes. You don't get the same visual indication with energy conduits, but I'm pretty sure the kind of thing is going on.
I'm not sure how a common API could satisfy both methods other than *allowing* modders the option of either/or/both. Perhaps their engine or machine would simply join the network be a "network" TE2-like block. Or, it could be a BuildCraft-esque block-by-block device. And, while it could do both at the same time (network and block-by-block), it wouldn't fully satisfy both. When a machine wants power, for example, does it pull from its internal buffer, or does it simply put that machine in touch with an engine somewhere in the network, for example ?
While I think that gets the gist of it, I'm sure I have some details completely wrong, like "connecting consumers with producers" - that's probably not quite correct. Perhaps TE2's conduit network acts as one, huge "pipe" where all input is summed and all output (demand) is summed. Not sure.
But, one thing I do know is I highly prefer placement-time calculations vs. per-tick calculations. *ANY* code that runs per-tick has got to be treated as real-time code with the philosophy of it ain't absolutely necessary, then don't do it. The main MC loop *must* maintain 20 TPS.
Yup, the conduit networks are a single huge pipe. Machines are ignorant of them. It's also trivial to enclose BC's system inside my own, it's just an issue of me not wanting to do it - the API I posted somewhere back in this thread would actually function flawlessly as a universal system, regardless of the backend.
I do not know what that means.
What I'm saying is that the network begins and ends with the cables, instead of including the machines. How mods move, use or store power is unimportant to the API, which would only control how things send and receive power. That is what would allow so many mods to transfer power however they like.
Probably the wrong place to do it but as I know you're actively following this thread, KL, I'll post here.
Something that I think would be pretty epic in regards to Redstone Energy Cells would be to tell which faces would be inputs/outputs. Also an option for both in and out. I don't know how well it would work with your network being an all over thing, but considering you have the same kind of thing with your conduits I thought it might be possible.
Something that I think would be pretty epic in regards to Redstone Energy Cells would be to tell which faces would be inputs/outputs. Also an option for both in and out. I don't know how well it would work with your network being an all over thing, but considering you have the same kind of thing with your conduits I thought it might be possible.
In AND Out isn't really feasible. The new cells are already sided for In OR Out however. Conduits will be losing their in/out logic, there's no need for it. Something either produces or consumes on a given side, it shouldn't do both.
that's perfect! Super excited for the release.. Modded minecraft isn't the same without TETrue but that's not really what's happening in minecraft is it, it's more like trying to unplug something from one side of the room and plug it in on the other and having it not work.
It's a baseball term that pretty much means you did a damn fine job.
I can easily see how that might be the case, the best explanation I have is that just like the reason you don't want to use the BC api anymore because it doesn't give you enough options, we like to have as many options as we can as well, as it is we don't really have all that many options when it comes to what we power with what. More options when we're building our minecraftian creations is simply better then less options, or just in general really.
I just want to say that I am excited about the future of Thermal Expansion too. Sometimes there are times that I just want to say all hail the King and not just because I live in the United Kingdom (long live the Queen too, just saying). --- On a slight tangent, could you imagine if the Queen wrote a Minecraft mod, I think that would be pretty cool.
I like the sound of redstone flux too. I agree with Covert Jaguar that MJ is a good system that has plenty of utility and perhaps a touch of universality (at least in the 1.5 world and I don't know who to credit with that so I will just thank all of you). However, I am looking forward to trying out redstone flux and whether it is a high power system a la boilers or a relatively low power system I don't care. I have every confidence that it will be just as cool as the Thermal expansion I am enjoying in 1.5x. Furthermore, the most potent fuels in 1.5 are in my opinion fuel, ethanol/biofuel, liquid force, crushed ice(as a throttle) and steam. All can be conveyed by liquiducts. It seems to me that "potential energy" is already a pretty decent standard.
-----
Also, @King Lemming. With the power of logistics pipes, buildcraft and Thermal Expansion, I created a system which would intelligently divert ores to a pair of induction furnaces. It would select whichever one would give the greatest yield, depending if furnace A had rich slag in it or not. If it didn't have rich slag it would go into a sandy induction furnace. And I bet you know how I kept it stocked with sand.
I like the sound of redstone flux too. I agree with Covert Jaguar that MJ is a good system that has plenty of utility and perhaps a touch of universality (at least in the 1.5 world and I don't know who to credit with that so I will just thank all of you). However, I am looking forward to trying out redstone flux and whether it is a high power system a la boilers or a relatively low power system I don't care. I have every confidence that it will be just as cool as the Thermal expansion I am enjoying in 1.5x. Furthermore, the most potent fuels in 1.5 are in my opinion fuel, ethanol/biofuel, liquid force, crushed ice(as a throttle) and steam. All can be conveyed by liquiducts. It seems to me that "potential energy" is already a pretty decent standard.
-----
Also, @King Lemming. With the power of logistics pipes, buildcraft and Thermal Expansion, I created a system which would intelligently divert ores to a pair of induction furnaces. It would select whichever one would give the greatest yield, depending if furnace A had rich slag in it or not. If it didn't have rich slag it would go into a sandy induction furnace. And I bet you know how I kept it stocked with sand.
just for those who tell about plugging american devices in european power sockets. okay, firstly they are differently shaped (there are even a few different non-compatible standards in europe ), so you need an adapter for it. secondly many devices and ac-dc adapters are designed to work with 100-250V and 50-60 Hz. so, universal plugging.
normal pcs once had a nice red switch on their power supply, sometimes hidden under a sticker. in schools, pupils had sometimes the idea of switching the pc from 220V to 110V. and the next one who turned it on saw a nice cloud of the magic black smoke (you know that smoke, that keeps things running, if the magic smoke left the machine, it doesn't work anymore). I guess, turning a pc in america from 110V to 220V will lead to other nasty habits, maybe it destroys harddrives.
but today, most devices are very tolerant about the voltage they get.
), so you need an adapter for it. secondly many devices and ac-dc adapters are designed to work with 100-250V and 50-60 Hz. so, universal plugging.normal pcs once had a nice red switch on their power supply, sometimes hidden under a sticker. in schools, pupils had sometimes the idea of switching the pc from 220V to 110V. and the next one who turned it on saw a nice cloud of the magic black smoke (you know that smoke, that keeps things running, if the magic smoke left the machine, it doesn't work anymore). I guess, turning a pc in america from 110V to 220V will lead to other nasty habits, maybe it destroys harddrives.
but today, most devices are very tolerant about the voltage they get.
Well they may not be for you, but for lazyasses like me and my friend it would be pure awesome. We wouldn't have to bother with the noise of multiple power systems. (well HE wouldn't have to, normally i mostly handle magic and he machine). But hey, if you don't want to, you don't want to, all i can do is type words here to convince you otherwise.
Though it would also be perfect if RFlux has a good generation method, and conversion to most other forms of power, if not from. please?
- Status