A key feature for the 0.0-demo9 release is something I am referring to as "logic powder". This is essentially redstone-like functionality being added to the system.

The first cut of this is working with basic sink and source blocks where their state is set by having multiple block variants, as opposed to a block having a different mode (not sure I like this idea but it does work in a pretty straight-forward way, at least for now). So far, there is a switch block (a source which can be on or off), I added sink functionality to the doors, so they can be opened/closed with a switch, and added a sink lamp which can be turned on/off with a switch. While these are generally working, they were just to create a basis for testing more generalized wiring of a data network.

The plan for this will be to add a "logic wire" block so that source/sink don't need to be adjacent to interact. The idea is to make this something akin to redstone, but using explicit wiring instead of solid block interactions of dust. There are a few ways of looking at this.

The first idea I had months ago was to actually design this as an explicit network on every line, where there would be input and output locations along a given track of wire, such that there wouldn't be distance concerns or power level degradation. Comparing this to Minecraft, it would be more like some modded functionality as opposed to vanilla redstone. I turned away from this idea since I didn't want to create a bunch of special-cases around how the network would split/join/grow, especially considering a partially-loaded world. Not to mention that it would have some odd interactions with the parallel data model. Still, I might come back to this.

The idea I have been recently prototyping is something with distance and power level limits, much like vanilla Minecraft redstone. My plan was that this could work almost exactly the same way as lighting, just with a different data aspect. This would be nice in that it would really just mean a generalization of an existing idea, so a single solution to any complex cases would implicitly solve it for both lighting and logic.

In this design, I will initially need sources and conduits to behave like the lighting engine (where place/break of source is just like a light but place/break of a conduit would be more like the inverse of place/break an opaque block). When there are updates, they would also need to notify adjacent sink blocks so that they could potentially change their states. While this would work within the rest of the system without too much of a change, it does introduce some issues.

The first issue is what to do once more complex blocks are introduced, which may be both sink and source (consider a diode or transistor). This would require that the "light" can only flow in a single direction, which would be an annoying change to the lighting system (and probably wouldn't give the right effect for things like directional lighting). Additionally, the performance on this may leave something to be desired as flicking a switch to turn a light on would result in: (1) the switch changes to on, (2) the data line is re-flowed, (3) the logic update reaches the lamp, (4) the lamp changes to on, (5) the light is flowed into the space. This 5 tick delay currently corresponds to half a second, which isn't very satisfying. Of course, even using the abstract network design would only maybe improve this by 1-2 ticks.

The only real way around this may be to handle logic and lighting updates within the same tick, although it would require adding a synchronization point into the tick (not a big deal since there are currently none of those so there are many options - also, it could potentially be a sort of "soft fence"... hmm). I am still not sold on the idea, though, since the abstract network might be right (while creating a totally new system, it may be one which could be reused by other features in the future).

For now, my plan is to continue with the lighting-based design, worry about hybrid blocks later, and look into in-tick logic and lighting updates if the observed performance feels wrong (even without this, it was bothering me for light changes - although that could be hidden on the client, with some work, or minimized with a future faster tick rate).

Interesting problems,
Jeff.