I’ve decided to turn RedPower into a standalone game, based on a custom engine.
It’s going to have a feel rather similar to the mod, but quite different from Minecraft. I’m going back to a lot of my old Minia ideas, and my original inspirations.
I’m holding back on revealing the signature content at the moment - I have mobs, player characters, and other things, but I’m not ready to start the hype just yet.
What does this mean for the Minecraft mod? I’m still not sure. I’d like to continue it, but I don’t currently have the resources to. During the main development period of the mod, I was unemployed. It was a full-time job to develop and maintain it. Since I started working, I tried updating it several times, including a major redesign, but constant code churn between MC, MCP names, and Forge kept erasing the progress I made.
With my own engine, there are no issues with code churn. The base game can’t change and invalidate my game design. I’m not stuck in Java, nor in ancient versions of OpenGL. My engine takes full advantage of multi-core CPUs and modern GPUs. It should run well on next-generation console hardware also.
The other big advantage is that I can get my game on Steam, and other major distribution channels. More people see it, and I have a chance at making enough to pay the bills. I don’t like that I have to think like that, but working all week leaves me only a little time on the evenings and weekends to do game dev. This applies even more now that I have a full-time artist working on the game. Those aren’t free.
Anyway, assuming this post actually uploads correctly, I’ll try to keep this site a little more up to date.
]]>Thanks to direwolf20 for the timely spotlights, which should get you up and running in the new version:
And a video on how to use the Sortron:
]]>WordPress was an okay system, but it required too much maintenance, accepted far too much spam, and used so much RAM that it would crash the database.
Octopress generates static pages, so the site should be much more reliable in the future.
In the meantime, here’s a small teaser of PR7:
What could it mean?
]]>Added some achievements.
Support for Buildcraft oil.
Support for Railcraft/MCL minecarts.
Moss spreads.
Recycle fine wire, armor, tools.
Igniters can extinguish portals.
Independent output buffers for the Sorting Machine.
Added iron, tin, copper, silver nuggets.
IConnectRedstone is now respected by redwire (fix for Railcraft connection).
Make use of the new MCL getItemsDropped() for minecarts.
Fixed bottom of thermopile texture.
Fixed jitter when near bedrock.
Deployers using screwdrivers
Fixed bad linksize computation.
Fixed frame sky excursion.
Fixed frames leaving loaded chunks.
SSP volcanos now generate properly.
Carts crashing into transposers now have a draining delay.
Sorting machine no longer loses the column.
Items bumping the input of the sorting machine are correctly sorted.
Fixed HD texture animations on Frame Motors.
Fortune on gems.
Fixed bug in Assembler filling water buckets, etc.
Boot disks now spawn in dungeon chests.
Battery boxes drop contents when broken.
Rubber tree leaves had the wrong light opacity.
Placed rubber leaves no longer decay.
Change the FORTH boot disk rarity.
Nugget merge recipes in alloy furnace.
Added jungle wood microblocks.
Made diamond blocks harder to cut.
Added a workaround for people who insist on setting the world time backwards.
Fixed issues with Redbus IDs over 127
Fixed KEY?
New Words: 0SP 2SWAP ( \ ” AT-XY
New words: >NAME NAME> DOES>
New words: U. / MOD U< U>
New words: PROBE TOP FREE
New words: IMMEDIATE LITERAL POSTPONE RECURSE
New Words: BLOCK FLUSH REVERT UPDATE LIST WIPE PP LOAD
WORDS no longer clobbers the TOS.
TIB no longer overwrites SCRATCH.
CPU: Fixed interpretation of the E flag.
CPU: Add unsigned divide support (C=0), fix divide bugs.
CPU: C and Z flags are no longer swapped.
CPU: Added unsigned multiply support (C=0)
CPU: Fixed the carry flag for SBC.
ERASE is now called FORGET
TIBFIND is now called ’
CPU loader no longer crashes when loading from a disk >64k
TIMES can now be used as a compiling word.
Make ALLOT smarter
Attempt at fixing mac enter keys in Control.
Cleaned up Control. Now uses the translation table, fixed the disk being treated as a block instead of an item, etc.
Drives drop disks when broken.
Fixed SMP rendering bugs in Control.
The Assembler no longer crashes when multiple bundle-mode Assemblers are adjacent.
Screwdrivering pumps no longer crashes.
Frames are much less likely to crash with other mods, and will drop far fewer block types when moving.
Fixed the << word in MineOS.
Frame Motors no longer lose power on chunk reload.
Memory structure:
1 2 3 4 5 6 |
|
The MMU instruction, which is not documented in the instruction tables, takes a single byte parameter. The currently defined MMU commands:
MMU OpCode:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
The Display registers:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
IO Expander:
1 2 |
|
Disk Drive:
1 2 3 |
|
1 2 3 4 5 6 7 |
|
Added Frames and Frame Motors.
Logic rewrite with lots of new logic gates and new “mirror” modes.
Added RedPower Control computers.
Added Pumps, Fluid Pipes, and Grates.
Added the Ejector, Relay, and Assembler.
Basalt is now creeper-resistant and microblocks are explosion-resistant.
Added the Wool Card.
Removed the Array package.
Added the Athame.
Frames currently have some trouble moving things that need support. Levers are especially effected by this, as is anything with an active redstone state. This is caused by vanilla behavior, and while I have a planned solution, it isn’t ready yet. Expect this to improve in the future.
The OS for Control is currently very basic, and nearly undocumented. I hope to fix that in the future.
There may be certain small refresh glitches in SMP on chunk boundaries.
The Logic rewrite isn’t very compatible with the pr4 series. Logic tiles in inventories are going to get corrupted, and the current state, including rotation, will be lost on load, although they should convert tiles in world. This was unfortunately unavoidable.
In addition to 1.2.3, there are a bunch of new blocks, and more bugfixes than I can count.
Added Magtubes, Accelerators.
Added Restriction Tubes.
Added Igniter.
Added Regulator.
Added Blulectric Alloy Furnace.
Tubes no longer eject items, use a Transposer for deliberate ejection now.
Battery boxes can be powered with redstone to prevent discharge.
Retrievers now have sliding window.
Fixed the scheduler bugs.
Fixed the recipe for the Thermopile.
Fixed Deployer glitches.
Lots of other bugfixes backported from the pr5 branch.
The biggest change in this version is simply that it runs on Minecraft 1.1.0, but there are a few new features too.
Added the Project Table, an improved manual crafting table. This is not an automatic crafting table, please don’t ask me to make it into one.
Added the Thermopile, which generates power from a temperature differential across it. Now you can run your sorting setup in inconvenient locations.
Filters now have color tagging support.
Fixed the Deployer interacting with animals.
New recipe handling, which removes microblocks from the default recipe list and eliminates crafting lag.
No more glass jacketed wires.
This is an incremental bugfix release, with only a few changes. One bug has been causing a fair amount of trouble, and there was previously no way of getting Blutricity in the Nether. Moving batteries around is less than ideal, but since Sorting Machines and Retrievers use so little power, at least now you will be able to sort things in a nether base.
Improved damaged item comparisons.
Fixed counting bug in Filters, etc.
Fixed default coloring in empty Sorting Machines.
Back-ported the new Battery Box.
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.
]]>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.
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.
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?
]]>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.
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.
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.
People following on twitter may have seen 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.
]]>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.
]]>The Transposer bug in particular can be pretty nasty, so I wanted to get this out there quickly.
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.
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.
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.
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.
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.
]]>