So I’ve been working more on Frames, and while there’s still a number of bugs remaining (especially graphical bugs), I’m able to start making things out of them.

So first, I made a vault door:

Then I set out to do something a lot more ambitious:

This machine functions much like a Buildcraft Quarry, but it’s done entirely without “magic blocks”. I designed and built it in-world out of existing RedPower blocks and Frames. While this particular function is familiar-looking, it’s only one of millions of possibilities.

This is what I mean when I talk about making the parts work together. Other mods have some of the parts of this, but no combination of them can be used to build these sorts of machines.

So I just posted RedPower 2 Prerelease 4b, for Minecraft 1.0.0. Download link is up top, as always.

This version requires Forge 1.2.3 or later, so I packaged up an SVN experimental version, available on the download page. The official one will be out soon, I’m sure.

Unofficial Recipe List

Fixes

• Fixed distribution distance rules.

• Fixed colored stub tubes.

• Fixed retriever pulling from bottom slots.

• Fixed retriever bounces dropping.

• Fixed BT Battery and Indigo Paint recipes (ore dictionary support).

• Fixed stuffing minecarts.

• Fixed flax and nikolite drops.

• Added support for Fortune enchants for mining nikolite.

• Smelting iron bars and doors into ingots in the alloy furnace.

• Nether brick and gemstone block microblocks.

• Creative mode inventory population.

I really didn’t want to have to post this. I’ve been keeping quiet because I don’t like drama, and I don’t see anything to fight about here. But try as I might, I’m getting singled out, so I’m going to have to respond.

First, I’m going to start by linking to a post by Stratagerm: Statement on minecraft mods copying features from one another. It’s worth a read. I agree with the point he raises.

Beyond that, though, lets talk specifics. I’ve talked about my inspirations for my timer mod, and for the wiring that followed after it. So instead, let’s talk code.

Early in my development, I ended up with a feature that was quite coveted by other mod authors: I used 1 block ID for all of Integrated Redstone (which became RedPower Logic). I’ve continued this legacy of using very few block IDs through to the present day.

Now, IndustrialCraft used to use a lot of block IDs. This was long before I had any features even remotely inspired by IC. At the time, the IC team looked inside RedPower to find out how I’d done it. The first “copying” (although I’m very hesitant to use this word - since while they used the technology I developed, their code is their own) was actually IC using part of the technology of RedPower. Since then, IC and RP have traded ideas back and forth. IC got wires that connect like RP’s jacketed wires, and RP got Blutricity. IC also gained the ability to separate wires by color, by using paint. I borrowed that idea back again by using paint to separate and mark tubes, but it’s worth noting that the back-and-forth there has made both mods better.

Now let’s talk Buildcraft. Buildcraft’s pipe ideas weren’t new at the time it was first released - the Allocator and Minefactory could be used together quite effectively to shuffle items around on conveyor belts. What Buildcraft was, though, was clean. It worked together. I started modding by adding a few blocks to assist BC users: the redstone pipe, and the timer. For a long time, BC and RP were inseparable, and I rather liked it that way. Then BC2 came out, and it largely made the timer redundant, while also adding a complete power system of its own. SpaceToad did a really good job of making the power system look new and original, but fundamentally, it’s still a power network.

Yes, I added a method of transporting items to RedPower. It’s a rather obvious necessity for large-scale automation mods, and Buildcraft isn’t unique in this requirement. It’s not even the first. I’ve done what I could to make my implementation unique, and with the inherently networked tube pressure system, I believe I’ve managed that. The Sorting Machine and Retriever have no direct siblings in Buildcraft. And again, it goes in both directions. Buildcraft 3 adds wires and logic gates, and both mods are better in the end.

And then there’s Frames. A lot of accusations of them being ripped off from something, but I’m still not sure what. The demos clearly show them moving not just more frames, and not just frames with covers on them, but functional machine blocks also. I’m not aware of another mod which existed before that video that allowed you to assemble a tunnel boring machine from multiple blocks and move it as one unit. There is a new mod that came after, but I’ll get to that in a minute.

I’ve been doing a lot of work behind the scenes to make the large tech mods interoperate well. The functionality in Forge that allows unlimited terrain sprites without performance loss? I wrote it (and it required a major overhaul of the rendering engine, at that). The interfaces to let machines with unusual interface shapes (like IC’s Induction Furnace or RP’s Alloy Furnace) interface with item movement systems like BC’s pipes, RP’s tubes, MFR’s conveyers, etc? I wrote those also. The Ore Dictionary to make mods with similar ores play nicely? That too.

Finally, it doesn’t end with RedPower. The Frame-based tunnel boring machine? Since I released that video, a new mod came around devoted to building tunneling machines along the same lines. And then there’s FutureCraft. And the original Minefactory has been continued under new management. So many of the ideas in those mods have been passed around so many times, who is to say who got inspired by who? Noos assures me that the tunnel boring machine was parallel development, FutureCraft appears on the surface to be a little more directly inspired by RedPower, and MFR just continued along the natural path for Minefactory. Do I have a problem with either? Nope.

Everyone has inspirations. The biggest difference is that I openly admit mine.

Now can we please put this silly drama to rest, so I can go back to writing my mod?

So I just posted RedPower 2 Prerelease 4, for Minecraft 1.0.0. Download link is up top, as always.

Unofficial Recipe List

Major New Features

• New Blutricity energy net.

• Added Battery Boxes.

• Added Voltmeter.

• Added Sorting Machine.

• Added Retriever.

• Added Buffer.

• Added Paint Cans/Brushes.

• Added Redstone Tubes.

• Added partial support for Creative mode.

Known Issues

• Blutricity power is a little “springy”. When you connect it, you’ll see line transients if you repeatedly measure with a voltmeter. This is normal.

• There are probably issues with TMI. Don’t bother reporting them. I plan to fix TMI interaction in pr4b.

• I have no idea what happens if you to enchant RP items.

• Forge 1.2.0 has a bug with repair recipes. Just don’t use them with RP items. The next Forge version will fix this.

Bugs Fixed

• Rubber trees now have a fast mode.

• Fixed infinite backstuffing.

• Fixed machine freezing.

• Fixed covers on logic turning into cobble.

• Fixed ore generation patterns.

• Fixed a major loss of framerate in SMP with tubes.

So now I’ve got most of the sprites for RedPower PR4 ready, and I’m down to coding.

People following on twitter may have seen this:

A while ago, I posted this:

These are the two main components of Frames: the Frame Motor, and the Frame itself.

Frame Motors pull Frames in a direction, along with anything adjacent to the Frame. When they pull another Frame Motor, they also pull the whole Frame connected to it also.

Currently it’s only about half-finished, and it has some bugs, but it’s complete enough to demonstrate:

The Frame Motor will use Blutricity when it is completed, but for ease of testing, it currently does not.

Someone in the comments asked me where I was going with RedPower, and for some reason, I ended up replying with an essay-length ramble about the history and inspiration of RedPower. So I’ve decided to repost it here, with a few edits.

If you want to see my inspiration, look at my old 1.501 world video on Youtube. I made that world completely legit, although I used a whole mess of mods to make it possible. They didn’t all work together properly (BC and the Allocator hated each other, IC at the time was full of bugs, the Piston Mod was a glitchy mess, Redstone Advanced was crash-prone), but I had so much fun, that I decided that I wanted to make a single monolithic mod that provided the gameplay experience that I had at that time, except properly integrated and polished.

I started by identifying areas that needed improvement. My earliest modding effort was the redstone pipe for Buildcraft – because at the time, Buildcraft had not added the obsidian pipe, so I used an Allocator, a pressure plate, a chest, and a wooden pipe to detect items. I thought Buildcraft really needed a detector, so I wrote one. Also, at the time, I was using the clocks from Redstone Advanced to run my Buildcraft machines, but they only provided a single speed, and didn’t look very good (a flat texture on the ground). And so I started on my second mod – the Redstone Timer. In that mod, I included the RS Latch, and the Sequencer. The RS Latch was my effort to avoid using a ton of block IDs for all the different timing functions you might use – when combined with the Timer, it allowed almost every single timing function to be realized in 3 logic tiles.

Next up was Redstone Advanced itself. Faenorith had left modding, and RSA was terribly buggy to begin with. If you connected a NOR gate back to its own input, it would promptly crash Minecraft, for example. I figured I could make a set of logic gates that fit the vanilla feel, and so I did. The arcane rules of redstone dust started to frustrate me during that development effort, and so the original version of RedPower Wiring (which was just called RedPower at the time) was born. There were mods out there that solved parts of the problem. Vertical redstone could go up, colored redstone could be isolated. There was a feature request called the Redstone Tunnel Block for hiding wires. I looked at all these partial solutions and imagined a complete solution. The first version had bare wires, insulated wires, and a single color of bundled cable, in addition to cover plates in a couple materials. At first, cover plates could only be placed on wires, but the initial playtesting resulted in so much demand for “free-standing cover plates” that I relented in the next version.

Of course with all that framework I built to make cover plates possible, especially after I made them freestanding, I decided that it was a natural evolution to add a lot more different types of microblocks. There were a few mods out there that I drew inspiration from – the Eighth Block mod was rather neat looking, and Better Than Wolves had a nice approach to slabs, strips, and corners (although I was only vaguely familiar with BTW at the time). So I extended the cover system to include a lot of other types, and I’ve kept extending that. RedPower 2 has nearly doubled the number of microblocks over 1.

That takes us up to the golden age of RedPower 1 – when BC, RP, and IC didn’t have any overlapping functionality, and RedPower was a common footnote in people’s worlds. At this point, IC1 was discontinued, IC2 was on the distant horizon, and Buildcraft was doing its own thing. So I started working on RedPower World, with the intention of adding the materials I needed for future expansion packs. Truthfully, I saw myself working on RedPower Laser and RedPower Advanced Logic next (which is why gemstones feature prominently in the mod), but some of my original inspirations showed up first.

The first thing on my mind was that, with IC on hiatus and the old IC1 cable system in the state it was in, I wanted to use the RedPower wiring technology as a power transmission system. That was when the first hint of what has become Blutricity was born. My plan at the time – which is still the plan – was to provide a way to power a number of machines unique to RedPower, but also to add equivalents of a couple of the basic machines from IC (electric furnaces, compressors, and macerators, specifically), with suitable renamings, graphical upgrades, flavor changes, and different balance, as a stopgap until IC² came out and as a convenience for games without IC. Of course, development ran long, and IC² was released, so I deprioritized the basic machines and went on to more original things.

After that, I looked back to my 1.501 world and asked myself which blocks I really wish I had. There were three that I had designed back then. The first was a machine that would simply break the block in front of it and eject it into a Buildcraft pipe. The second was a machine with an inventory that would place a block from its inventory into the world. The third was a Buildcraft-compatible version of the Allocator. These became the Block Breaker, the Deployer, and the Transposer. The Block Breaker was a response to the unreliable piston-mod glitch cobble generator that I used, which jammed on load every so often. The Deployer was meant to pair with it to make a much simpler version of the reminer that you can see in my 1.501 world. And BC and the Allocator just simply didn’t play nice to begin with.

Tubes were honestly an accident. I had no intention of writing a competitor to Buildcraft’s pipes. I wanted to add a basic transport system called “chutes” so that Machine would stand alone without Buildcraft, but one night, after too much absinthe, in a single sitting, I sprited, designed, and implemented Tubes. I woke up the next morning, a little hung over, to realize that I had a fully functional transport system that avoided my biggest pet peeve of Buildcraft – spilling items. As Buildcraft’s API was big and kept changing, I shelved my original plans to make Machine fully BC compatible and just connected everything to the tube system instead.

Now I’ve reached a critical mass where completeness is calling for a few more basic machines. The Crafting Machine is the next one on the list, solely because Machine can meaningfully automate everything except crafting. But the one I’m most excited about is Frames, which I’m working on next. It’s a little bit like the platforms in BTW, except they can move other blocks, including ones with TileEntities. It’s really the last piece of the basic Machine set, since you can use it with blocks like the Block Breaker to make automated mining platforms, gantries, etc. A sufficiently motivated player could use Frames to build a Quarry. Or a self-propelled tunnel boring machine. RedPower Control (the computer mod) will help a lot for controlling gantry movements and things. A few people have even suggesting using Control with Frames and a Deployer to make an in-world 3D printer.

And there are tons of long-range plans. Light bridges, fusion reactors, holographics, swarm drones… The sky is the limit.

Here’s an example of how the Sorting Machine will be used. It requires Blutricity to operate, and it will sort incoming objects according to a set of rules entered via a GUI. Each item may be tagged with a color, and items tagged with a color cannot travel through tubes which are painted a different color. You can specify up to 8 different colors with one Sorting Machine, each of which can accept up to 5 different types of item.

Here’s the GUI as it stands now:

I just pushed a bugfix release, RP2pr3b. You can get it from the standard Download button at the top right.

Unofficial Recipe List

The Transposer bug in particular can be pretty nasty, so I wanted to get this out there quickly.

Bugs Fixed

• Stuffed up transposer pulls unlimited items.

• Fixed North/South distribution in Tubes.

• Outer sides of new microblock faces can now support torches, etc.

• No more dark item rendering.

• More helpful autoassign error.

• Make the inventory tweak pickier.

• Fixed bugs in item ID assignment.

I just uploaded a new version, RP2pr3. You can get it from the Download link in the upper right corner of the blog.

Unofficial Recipe List

Major new features

• Tubes now alternate between valid same-length destinations, allowing fair item distribution.

• Rubberwood Covers

• A preview version of Blutricity.

• A non-colored bundled cable.

• Transposers and Filters can insert or extract from storage minecarts.

• New Item Detector block.

• Ore Dictionary support.

• Transposer passive actions switch off when powered, allowing the Transposer to be used as a valve.

• A major secret feature.

Known Issues

• Some recipes are temporary, and a few have changed.

• Game balance is still not finalized.

• Volcanos and Rubber Trees are still using an even distribution.

• Creative Mode is still not supported. RedPower blocks can’t be broken in creative mode.

• The Blutricity energy network loses too much power and has too much line sag.

• A small save change will make jacketed wires in inventory invalid. Jacketed wires in the world will be fine.

Bugs Fixed

• Spilling items around full chests.

• Basalt covers preview as bedrock

• Bad ejection positions

• Filters accepting blocks backwards.

• Items entering stuffed up transposer.

• Not filtering on the sucking cone?

• Can disable silver, tin, copper generation

• Add a “autoAssign” option to the config file, to prevent the IDs from wandering.

• Fix tube item visibility in SMP.

• Fix a few cases where tube contents would not be saved.

• Somehow it’s possible to get opposing wires in the same block.

So, I just had the first sign of life from Control:

This time around, it’s not a mockup. It’s running a short 6502 assembly program that initializes the Redbus, sends the text to the display, and updates the cursor position.

Now for the gory technical details. This is for the people who actually know what an assembler is and want to do something with it. If you’re not one of those, don’t worry! You won’t need to know this to use the computer blocks in-game.

The Redbus controller is really simple. It opens a 256 byte memory window starting at 0x200, which is mapped directly into Redbus address space. There’s also a single byte at 0x300 which determines which device (of the 256 possible devices) to connect to.

The screen interface currently works like this: Byte 0 - The screen row to select for the memory window. Byte 1 - Cursor horizontal Byte 2 - Cursor vertical Byte 3 - Cursor off/on/blink Byte 16-55 - The characters on the currently selected display line.

The display is 40x25 monochrome text cells.

That’s what’s working right this second.

There are a few things I’m going to change before this becomes final. The controller byte is likely moving to 0x400, so that the memory window at 0x300 can be accessed by external Redbus devices. This will allow almost effortless networking between devices on the same line. Also, it’s likely that register 0xFF on the Redbus will have special meaning - I’m currently thinking that writing to it will be the interrupt request signal, and reading from it will be a presence detect method.

Also, the display block is going to get a bunch more registers for handling its built-in keyboard.