Computer​Craft Based Rail Switching

Page under construction: this is an incomplete draft.

So, I was asking myself one day "how can I use Computer​Craft to improve vanilla gameplay?" and I decided to mash with one of the worst features of the entire game, minecarts. The most common uses for minecarts currently are for small redstone contraptions, or transporting entities either in a permanent circuit or a temporary way, not even passenger or freight is considered.

This switching system is designed for single cars with a player inside, but with some modification could probably run multiple car trains. This system is not designed with multiple trains running in mind, it is not designed to do any blocking, only switching.

The Problem

How do you share a piece of minecart rail with different routes efficiently? In other words, how do you synchronize the switches in a minecart rail network such that a minecart with any destination will get to it reliably and autonomously, and in a way that's easy to implement and uses few resources?

Worded like that, we know our constraints:

First Proposal

At first, the envisioned solution would be to have a central control computer, where the whole track could be controlled from. Wiring everything would be tedious and extremely difficult given a computer has only a handful of redstone outputs. CC has ender modems (equivalent to ubiquitous wireless data networks) however, and so you could replace the individual wires with a computerized switch. The downside of this though, is that you would connect a lot of computers onto the endernet.

However, there's a very fundamental detail that's underlooked and effectively shoots down this proposal. There are no guarantees that the switches themselves are loaded when the command to change them are sent out, or the central computer itself. This lack of guarantee means the minecart could encounter a switch in an undefined state, thus diverging from its route.

A Solution

After analyzing the first proposal, the following points are observed and inferred:

The switch must be loaded when being set, but there's a guarantee that relevant switches will be loaded, when the minecart arrives at it. Instead of sending switch set signals, the switch could ask the control computer the position it should be in.

The control computer must be loaded when setting, but there is a type of computer that may guarantee itself being loaded: the pocket computer. Pocket computers are items, and so, they can be taken with the player, and since the player always loads chunks, it's a guarantee that the control computer is loaded.

The switch must be set some time before the minecart passes it. Switch computers will be loaded when the minecart gets reasonably close to it, but long enough before the minecart passes it, a comfortable amount of time to set the switch.

The Switcher

The switcher in this would have three functions: detect an incoming minecart; querying how the switch should be set; setting the switch. Detection can be done very easily with an activator rail, and the communication can be done with a wireless modem, as the control computer will be close by.

The software on the switch computer could be structured like this:

static data:
    identifier set on installation
    querymessage = identifier .. " query"

define main:
    configure networking
    loop:
        pull event "redstone"
        broadcast querymessage
        let response = receive message with timeout
        if not message:
            continue
        let messageid, p = parse response
        if messageid ≠ identifier:
            continue
        output redstone p
        sleep for 2 seconds

The Control Computer

The control computer should be a pocket wireless computer carried by the player, it doesn't need to do much as it'll only answer query messages.

The software on the control computer could be structured like this:

define loadroute:
    let routes = load routes from file
    set switches = ask user to select route

define main:
    loadroute
    configure networking
    loop:
        let message = receive message
        if not message ends with " query":
            continue
        let id = parse message
        let switch = find in switches for id
        if not switch:
            display error message
            continue
        send message with id and switch state
        if no more switches left:
            return