Minecraft @ 3decibels.net

Who wants to spawn a couple of horses on my island here: http://minecraft.3decibels.net/map/#/-1534/64/1081/-2/0/0 ?

Don't worry, even with a delayed launch, there will be plenty of game-breaking bugs, and there will be at least two updates rushed out the door in an attempt to correct some of them.

Guys, he left an MSN Messenger address!

They've been scrapping the lighting engine rewrite for three (?) versions now.

Quote from: Malaclipse on February 23, 2013, 07:01:12 PM
TARDIS

I should have known you were a Doctor Who nerd...

Do it.

Quote from: Malaclipse on December 17, 2012, 11:31:13 PM
I like part 2 better.

I've looked at Tekkit before, and I think it's pretty awesome. It's a far cry from the plain vanilla experience we've had here. But I'm a big fan of Railcraft and RedPower.

Edit: Yuck, I just tried single player Tekkit and realized that it's still using 1.2.5.

Hi everyone!

I have a renewed interest in the game, so I'm totally down for a fresh start.

Let's start with the 1.4 release.

Quote from: nekoKaori on November 14, 2011, 10:29:42 AM
I have a random question. The red stone signal would be traveling with the player so why do you need mods to keep certain chunks active?

The problem is that the signal pulses need to trigger actions (redstone logic) in an unloaded chunk before you start traveling. Redstone signals are not transmitted outside of viewdistance, but redstone state is. Unfortunately, since the logic is controlled by pulses rather than constant signals, this doesn't help.

I tested this myself. Drop a long line of redstone and put some TNT at the end of it. Put a button on the other end and press it. When you return to the TNT, it'll still be there. The pulse did not travel far enough. However, if you replace the button with a switch and throw it, the TNT will explode as it enters your viewdistance since the state of the switch was on as you traveled.

With the new server running and the possibility of a couple (please?) mods (namely something to make redstone signals transmit over very long distances), I may finally get to build something I've been planning for a while: an automatic train switch. The current system with stops and rail changes in the middle is a little annoying and pretty rudimentary. It gets the job done, but we can do so much better. I would much rather be able to start in a station, select my destination, and be done with it. This post represents my initial ideas for a system to do just that.

Overview
In the system I envision, each intersection or group of nearby intersections has a numeric address. We control any particular switch by addressing a message to it and then sending it a chunk of switch-specific binary data. In the simplest case, this data could be a simple true/false value to control the direction of the switch. A more complex example might be a group of switches (picture four tracks coming together), where the part of the data-value is used as a secondary (localized) address, and another part is used to control an individual switch.

In my mockups, I have done my best to control the amount of circuitry required to decode these messages and control the switches, but building each train station is still a significant undertaking. To help with this, I imagine we could turn most of the rail endpoints into "leaf" nodes in the system. For example, the track to nightbuilder's house south of SilentKiller89's place would be one such node. The station that SilentKiller89 is building would be one of the hub stations, where most of the heavy lifting and track selection is done.

Despite the relative simplicity, I can see ways in which this system can be extended to send more general-purpose signals to a larger number of places. There is only one basic requirement (well, three, since I just made it a compound sentence). We need to run two redstone wires (1) through chunks that aren't necessarily inside someone's viewdistance (2, the mod) and allow two-way communication across those wires (3, mod possibility, since bi-directional repeaters are really messy).

Technical details
This system uses a simple cooperative bus to send messages. Only two data input lines are required at each switch: clock and data. To keep the amount of space required to an absolute minimum, I've chosen to use four bit addresses and four bits of data per message (this also lets me recycle parts of the circuit, which you can see below). I think the easiest way to explain the operation is to look at some example messages.

First, the simplest possible case: Three tracks coming together -- a single intersection with a binary on/off value to control the switch in the middle. Let's give this intersection an address of 0x7. The three high-order bits of data can be completely ignored, since we only need one bit to control the switch, but they still need to be sent, so we can pad them with 0s. The two complete messages we would send to this switch would be, in binary: 0111 0001 and 0111 0000, where the first nybble (0111) is the address and the second is the data value. To actually send these values, from the station, we hold the data line high or low (to represent a 1 or 0, respectively) and send a clock pulse. We need to send exactly nine clocks for every message (eight bits plus a reset pulse) because of the lack of interrupt line. (I could manage without the reset pulse at the expense of some extra circuitry -- we just need to agree on the convention.)

I think it should become easy to see how we'd control a group of switches (up to four at one address) now. Just use the entire data value to represent the position of each switch. So, let's expand the system. The most obvious limitation you can probably see is that a four-bit address limits us to just sixteen possibilities. What if we need to address a larger number of things? Easy: Send multiple messages.

For this reason, I reserve the four-bit address 0xF (1111). If we still want to have four bits of data, we need to send three messages. The first two messages' data contains half of the real address and the last contains the data. If we want to send a 0x1 value to the address at 0xCC, we send 0xFCFCF1 (1111 1100 1111 1100 1111 0001). This works because the circuitry will simply ignore a message not addressed to it, and since the all-ones address is reserved for this purpose, the switches without extra intelligence will just silently ignore all three shorter messages. At the smarter switches, we end up having to combine the first two messages to determine the address, (ie. 0xFCFC gets reduced to 0xCC, just like we wanted).

The stupidly-technical details
So far, I have worked out the exact (version 1, of course) design of only the receiving-end of the messages. I figure this is the part people will need the most help getting started on. There are also way too many different possibilities I can see for the stations (which are basically just buttons that activate a 9-clock attached to a ROM bank -- of which there are many examples on Youtube).

The receiving circuit is simple. It uses a 4-bit counter (I used T flip-flops) and a 4-bit SIPO (serial-in-parallel-out) shift register, real-world examples of which you can find on Wikipedia (which is incidentally where I learned everything about this. Thanks, Internet!). The address of each station is hard-coded, and the output of the circuit is entirely synchronous. Here's what the switch at address 0x3 would look like:



Larger address spaces like I described above are easy to implement with this design. Simply hook another counter up to the reset line and save the data lines to a register each time it pulses. After two pulses, you've got your address loaded, and on the third you'll find the data.

Questions, comments, additional ideas, accusations involving questions about my sanity?