Minecraft Mod API Brain Dump

Quick brain dump from IRC on what I, as an engineer, would want out of a proper modding API for Minecraft:

<@Harmony> First suggestion: Study the plugin structure of N64 emulators.  Some folks hate 'em, but I've always been a fan of a-la-carte services.
<@Harmony> Have an input abstraction layer for input plugins, for example; define a standard set of messages that the input plugin will send to the application, and the input plugin can be written to accept input from whatever HID it wants.  Person's playing on a keyboard, with no force-feedback?  Fine, EVENT_DAMAGE_* (hypothetical name) will be ignored.  Person's playing with an X360 controller?  The input plugin can key off those events and send the motors a-spinning.
<@Harmony> Some sort of abstraction layer to allow assets to be easily dropped-in; not just textures, but block models, mob models, player models.
<Nightmare> block types, and block-block interactions (so we can make a brick which floods the map with molten cheese, etc)
<@Harmony> That should actually be considered separately, let's not get ahead of ourselves.
<@Harmony> The blocks themselves aren't so much data-driven, I imagine, as code-driven.
<@Harmony> It would be nice to have them data-driven, perhaps by the same asset replacement system as renderable assets, but depending on where the core gameplay portion of the engine goes in the future, it might be easier to have blocks conceptually be part of the core gameplay engine, and simply have each block have an associated render asset
<@Harmony> Perhaps that plugin or subsystem could communicate with a render abstraction layer, which could allow people (like me) to write custom materials
<@Harmony> Imagine, dirt that's lit and has low specular like dirt
<@Harmony> Genuinely bumpy stone
<@Harmony> Environment-mapped water, with a soft UV wobble applied depending on the water current
<@Harmony> A modified fur shader for lush-looking grass
<@Harmony> Bright, bloomy snow
<@Harmony> Man, if I could get my hands on the original source code and not some decompiled bullshit, that's the first thing I'd do, is change that "OpenGL 1.1!" yellow text line to "OpenGL 3.0!"
<@Harmony> And think even further down the rabbit hole - nice, polished-looking mob, animal and player models, with plenty of bones, nicely skinned
<@Harmony> None of this requires any modifications to the physics side of the engine, so that could remain the same :D

74LS47, 74LS390, and 7-segment Decoder Complete!

Full tour video here: http://www.youtube.com/watch?v=RJIbZ-NzniQ

Not really much more needs to be said.  Check it out.

7400-Series Emulation Library for Minecraft: SELF-MC

One thing I've noticed with growing amazement is the circuitry that people have been laying down in this one game, Minecraft.  It turns out that due to the fairly simple rules that are followed by Redstone Dust in the game, you can build all of the necessary logic gates to re-create the inner workings of simple CPUs, ALUs, and other circuits that use binary logic.

However, one thing that has consistently bothered me is the lack of any sort of off-the-shelf solution for certain circuits - for example, the initial 16-bit ALU demonstration in Minecraft required the user to read binary, whereas I'm shooting for something a bit more visual.  It's with this in mind that I've implemented a working framework for the 7447 BCD-to-7-Segment Decoder IC, which takes four bits as an input and outputs seven lines that can be used to drive seven LEDs (or, in our case, torches) in the standard configuration to form digits.

More screenshots and videos will be posted after I get home from work, but in the meantime, here are the results of my test suite of all 10 single-digit decimal numbers being fed into the circuit:

0: Segments A, B, C, D, E, F

1: Segments B, C

2: Segments A, B, D, E, G

3: Segments A, B, C, D, G

4: Segments B, C, F, G

5: Segments A, C, D, F, G

6: Segments C, D, E, F, G

7: Segments A, B, C

8: Segments A, B, C, D, E, F, G

9: Segments A, B, C, F, G

The primary goal with this circuit was to be compact in two ways: First, the ability for the 7447 circuitry to be located entirely underground, and second, and using a minimum of X/Z real estate by building upward rather than outward.  In both ways, it was a rousing success.

Below is the logic diagram of the 74LS47 chip.  It consists of four primary inputs and seven primary outputs, with some glue logic - omitted thus far in the Minecraft implementation due to irrelevance - to control things like output blanking, lamp testing, and so on.

Source: 74LS47 Datasheet from Motorola

As mentioned, the areas highlighted in red were omitted or modified:
- The four red NAND gates were converted to NOT gates.
- RBI, RBO, BI and LT are not hooked up due to being relatively irrelevant to the functionality of the chip in Minecraft, though they could be trivially added back in.

At any rate, the sky's the limit for what I want to do next.  The only real downside is finding datasheets that actually contain a comprehensive logic diagram.  The end goal, however, is to begin converting the core functionality from other complex 74-series chips in order to begin building up a library of chips.

Stay tuned for a full schematic at some point.