Steam Engines in Minecraft's Create Mod

I have spent an irresponsible amount of time thinking about the steam engines in Minecraft’s Create mod, without a good place to put my thoughts. Here’s why I think they’re interesting.

Technical Crash Course on Create Stress Units

Steam engines are one of the power-generating components in Create. Generators produce power (in “stress units,” or \(su\)) via a rotating shaft, which can be linked to other components that consume power. Generators have a fixed \(su\) capacity, at which point they stop rotating.

Stress units are actually sort of a misnomer - even in the above language, \(su\) is far more related to power in the physics sense than it is to stress. This is perhaps easier to see when considering power-consuming components, which consume energy over time as a function of the speed of the shaft.

For the purposes of this discussion, it’s enough to consider stress units as the rate that components produce or consume energy - the more \(su\), the more energy is involved. The Appendix contains a more technical treatment.

Armed with the basics, we now explore steam engines, the most powerful generator in Create.

Create Steam Engines

The power output of a steam engine depends on three quantities: tank size, heat, and water pump rate. Each is tracked independently, and the power output of the engine is capped by the lowest level at any given time.

There is a potential source of confusion in the term “steam engine:” while the single block is technically referred to as a steam engine, you need as many steam engine blocks as the level of the boiler (factoring in heat and water) to use all of the available power. As such, a steam engine rarely has only one steam engine block. For the remainder of the article, I’ll use the term “steam engine” to refer to the entire assembly, and distinguish the block where necessary.

I’ll now break down each input to a Create steam engine, then discuss how to put it all together.

Tank Size

Tank size is the most straightforward variable: the larger the boiler, the more power you can generate. Each level and attached steam engine block requires four fluid tank blocks to be added to the boiler. Because tanks in Create are limited to square footprints (1x1, 2x2, 3x3), there are only a few reasonable choices when designing steam engines.

The chosen tank dimensions drive the the absolute power level and relative size of the steam engine. If things are done right, the tank is the limiting factor on power generation, and determines the size of the engine given that the other supporting infrastructure should always be about the same size.

Heat

Heat is the second most straighforward input. Each attached steam engine block requires one heating element at the bottom of the tank. Heating elements are the main force driving specific tank dimensions, because you need at least as many heating elements as you have steam engines.

Most heating elements (campfires, unlit blaze burners, magma blocks) are passive; you can think of them as producing zero “units” of heat, which buys 128\(su/rpm\) at 16rpm (2048\(su\)) for the entire steam engine. For the effect to stack, the only avenue is to use fueled blaze burners, which each produce “one unit” of heat and doubles output to 256\(su/rpm\) at 64rpm (16,384\(su\)) per attached steam engine block. For more information on these figures, visit the Appendix.

You can produce two units of heat per blaze burner if you use blaze cakes as fuel. These are unfortunately not renewable, and in my opinion are best used to temporarily “boost” large steam engines for big jobs.

While blaze burners can technically be fed any furnace fuel, many fuels are undesirable because they are either not renewable or require large farms to produce. As an alternative, I’ve taken to using the new(ish) dripstone to generate infinite lava in cauldrons. Happily, the Create mod can then pump lava from these cauldrons and use it as fuel for the blaze burners.

In my own steam engines, this system includes a mechanism to pump lava into buckets, a mechanical arm to provide fuel to each blaze burner, and occasionally a separate lava tank. The lava tank accumulates fuel over time, enabling successive cold starts and reducing the probability that the engine randomly runs out of fuel. For more details on the latter case, refer to the Appendix.

Water Pump Rate

The third and final input is water: steam engines require a constant supply. Canonically, this is because water pumped into the boiler is heated to steam, escaping as it powers the steam engine. Because you can’t just fill the tank once, the power of the steam engine depends on the rate that water is pumped.

The rate that a Create pump provides water is proportional to the speed that it rotates; having enough water for a steam engine just depends on gearing the pump so that it spins fast enough. This can be done with standard cogs, adjustable chain gearshifts, or rotation speed controllers, depending on how advanced your world is. The latter is easiest (and most efficient) as you can finely tune the pump rate to waste as little \(su\) as possible; however, it requires that you can manufacture brass and precision mechanisms.

Water pumps can take advantage of infinite water sources, so all you need to do is place one nearby the engine and you’re in business.

Putting it all together

Unlike other power sources, Create steam engines require other power-consuming components to make them self-sustaining. Above, these are pumps and mechanical arms. While these could be powered with another generator like a water wheel or windmill, the most elegant solution is to use the output of your steam engine to power the components that support it. Steam engines become self-contained, with a \(su\) “overhead” required to keep them running.

Stress Feedback

Say you assemble a steam engine large enough to suit your needs, with pumps to provide water and an automated fuel delivery system. However, there’s a chicken-and-egg problem: the engine can only run when these components are spinning, and they can only spin when the engine is running. How do you start the assembly from a stopped state?

Some people solve this problem with an external generator as a kind of “starter motor.” It can be connected to your engine temporarily, and provides enough \(su\) to pump water / fuel into the engine until the engine can do those things on its own. Once the engine is started, the starter could be removed, although without a lot of thought about the fuel source you run the risk of the engine spontaneously stopping and needing to rebuild the starter.

Hand Starting

To me, an external starter feels a little like needing to crank your car to start it. It’s unreasonable to expect a steam engine to run forever, and it feels more elegant to have a simple way to start and stop it when you need to. In addition, while a starter mechanism could always be present for a stationary steam engine, I’m very interested in using steam engines as a power source for airships in the upcoming Create Aeronautics, which requires that a steam engine be portable. For these reasons, I design my own steam engines around a hand-crank start (and yes, I’m aware of the irony with my car-cranking analogy).

The challenge with a crank start is that the hand crank produces a maximum of \(256su\), which isn’t enough to spin all of the supporting components on anything but the smallest of steam engines. To get around this problem, some solutions:

• Use two pumps, one for the engine and the other for the hand start. The starting pump can provide enough water for the engine to start passively, and even at \(2048su\) the engine ought to be able to run its supporting hardware. For very high-level engines, this may not be true, in which case…
• Add a mode switch, which uses a clutch to engage the starter pump and let it help pump water into the engine. This doubles the water level of the engine, at commensurate \(su\) cost. A mode switch just requires that you start the engine by hand and then use a lever to engage full power.
• If using levers feels like a lot of work, you can use a little bit of redstone to automatically engage a clutch once the engine starts moving under its own power. I’ve done this in two ways: pull a comparator output from a speedometer to detect when the engine starts moving, and engage the starter then, or use a comparator to compare a stressometer to a \(su\) threshold.

This concludes the bulk of my ideas about Create steam engines. I’ll leave you with a gallery of the steam engines I’ve built. I also have some extraneous thoughts that are included as an Appendix.

Gallery

Following are three of my own engines: Level 2, Level 4, and Level 9.

Previous Nextsads

I believe all of them are quite compact:

• The level 2 engine is \(6 \times 3 \times 4\) with a volume of 72 and nets \(32512su\),
• The level 4 engine is \(9 \times 3 \times 4\) with a volume of 108 and nets \(65056su\),
• The level 9 engine is \(10 \times 4 \times 5\) with a volume of 200 and nets \(145920su\).

Some of the images show extraneous things hanging off of the engines. These either belong to stress test circuitry (how I measure performance drops in the Appendix), or provide information to the displays.

Appendix A: Create’s Physics

The power produced/consumed by a given component could be written as

$$P = \frac{dW}{dt} = \tau\omega,$$

where \(P\) is power, \(W\) is work (or energy), \(\tau\) is torque, and \(\omega\) is rotational speed. From the above, we can see that the multiplier on a stress component is really the friction/resistance torque \(\tau\), and that power consumption increases with the rotational speed or rpm \(\omega\). We can perform the same exercise for generators: each generator produces some amount of power \(P\) in \(su\) at some speed \(\omega\). With these, we can compute the torque figure for each type of generator.

The generator torque figures are:

• Water Wheel: 16\(su/rpm\)
• Windmill: 512\(su/rpm\)
• Steam Engine: 128-256\(su/rpm\), depending on active heating

From just the above, you would think that the windmill is the best power source. However, here is where the distinction between torque and power (equiv. horsepower) matters. A single windmill tops out at 16 rpm; it has to have a lot of torque to produce any useful amount of energy \((8192su)\). Similarly, the water wheel has a maximum speed of 20 rpm/\(320su\), but can be extended to increase the torque and power output.

In contrast, a single steam engine’s minimum speed is 16 rpm/\(2048su\), with a maximum of 64 rpm/\(16384su\) when adequately heated. The power output is much higher than the alternatives, in part due to its relatively high speed. The other component is the steam engine’s linearly varying torque; when heated, the torque output of a single engine doubles.

Create’s generators are an interesting avenue to discuss the difference between torque and power, and what matters when comparing systems. In the context of the mod, though, the takeaway is obvious: steam engines crush the competition in terms of power output. When we consider the fact that up to 9 engines can be run in parallel on the same boiler, there is no reasonable alternative within the same footprint.

Appendix B: The Statistics of Dripstone Farming

When using a dripstone farm, it’s important to pay attention to the frequency that lava collects in each cauldron. Dripstone creates a full lava bucket every 19 minutes on average, so you need 1.14 cauldron setups per burner:

$$1000\frac{sec}{burner} \times \frac{1}{60}\frac{min}{sec} \times \frac{1}{19}\frac{cauldron}{min} = 1.14\frac{cauldron}{burner}.$$

To complicate things further, each dripstone doesn’t reliably produce a lava block every 19 minutes; it’s a random process that depends on Minecraft’s random ticks. This means that while on average we expect a lava block every 19 minutes, it’s perfectly reasonable to go several ingame days without seeing lava, or see several lava blocks in a single day. If you rely directly on a dripstone farm for fuel, you run the risk of occasionally not having quite enough fuel for your engine in lean cases.

While I am technically qualified to model the above mathematically / computationally, there are limits to the time I will commit to this topic. For the curious, the random process follows a geometric distribution:

$$ X \sim Geom(p_{fail, lava}).$$

The probability that an engine doesn’t have enough fuel to run at 100% power is the probability that all random ticks (trials) to a lava generator fail for 16 minutes, at which point a single burner runs out of fuel:

$$P_{fail, burner} = P(X > x);\quad x\approx 16min.$$

Limited empirical testing is enough to see for oneself that this is not an uncommon ocurrence, as it only needs to happen to one burner.

As above, I typically choose to add a “buffer tank” to store lava in an effort to reduce the chance that an engine loses power to a lack of fuel. This does not change the underlying distribution of lava arrival time; rather, it makes the joint probability of failure dependent on many more successive failures for lava to generate:

$$P_{fail, burner} = \prod_{i=1}^8 P(X > x),$$

where the number of successive failures is dependent on the capacity of the tank; in this case, this is 8 lava buckets.

My own testing reveals that a buffer tank indeed reduces the frequency of performance drops: over a 10hr test, the unbuffered system experienced a temporary lack of fuel five times, while the buffered system experienced a lack of fuel once. To make the frequency of failure zero, one would either need to increase the number of lava generators or a install a large enough buffer tank that the probability of failure vanishes beyond machine precision.

Appendix C: Miscellaneous Notes and Features

Here I’ll include some additional thoughts about designing Create steam engines that didn’t quite fit elsewhere.

I’ve found it useful to introduce a clutch between the steam engine output and its supporting hardware, which makes it possible to stop the engine on demand. This was a great feature during testing, and I’ve also used it for some peace and quiet.

I like to think about the water pumping and fuel delivery systems as separate circuits, which ought to be controlled separately. For all but the largest steam engines, the water circuit is the only one that needs to be run at a consistent speed. It is useful to be able to change the speed that fuel is delivered depending on whether you care to minimize \(su\) overhead or the duration of performance drops. With a faster fuel delivery system, performance drops will be more brief, but \(su\) will be wasted maintaining the system.

Performance drops are unavoidable if you’re using a mechanical arm to fuel exactly the number of blaze burners required to maintain an engine. An arm will only fuel a blaze burner when the burner runs out of fuel, so every 16 minutes an engine will lose \(16384su\) temporarily. Unless fuel runs out for some reason, an engine should not ever drop more than one power level.

A great way to avoid performance drops on lower-level steam engines is to include one more blaze burner than is technically required to heat the engine. Fuel consumption only increases to the amount of available fuel, so this change does not make the engine significantly less efficient; rather, it ensures that there are always enough active burners to power the engine at full power. As soon as there is fuel for the extra burner, it is lit, and it smoothly takes over when the next burner goes out. This change also allows the fuel circuit to be run at incredibly low speed, buying extra performance for free.

Most dripstone farms provide just a little more fuel than is required by the engine. With the above change, this fuel is now committed to eliminating performance drops.

Unfortunately, performance drops appear unavoidable on Level 9+ steam engines. The best I have been able to do is run the fuel pumps very slowly and the mechanical arm very quickly to jointly reduce overhead and prevent very long performance drops. Hopefully, a <1sec drop of ~16k \(su\) does not matter on an engine producing over 147456\(su\).

Finally, in service of Create Aeronautics, I’ve spent some time thinking about keeping a steam engine and critical hardware (like the propellers keeping you airborne) running if the stress network somehow becomes overstressed. I can’t think of a worse experience than trying to start your steam engine as you fall from the sky. The “stress lock” I’ve come up with involves a latch that activates if the network breaks a stress threshold, as done for some of my hand start mechanisms.

If the rotation network becomes overstressed, then a latch is activated, powering a clutch that disengages the overstressed portion of the network (and allowing the engine to continue spinning). The latch can then be reset by hand once the problem has been addressed. The system can also be chained with delays to have different levels of critical components (i.e. the workshop is disconnected first, then maneuvering propellers, then lift propellers).