CARBON

From MC Public Wiki
Revision as of 20:59, 2 May 2013 by TheRandomnatrix (talk | contribs) (Created page with "CARBON stands for Completely Automated Redstone Binary-Operating Node, and is an experimental rail system designed by TheRandomnatrix for use on PvE. It is intended to cut dow...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

CARBON stands for Completely Automated Redstone Binary-Operating Node, and is an experimental rail system designed by TheRandomnatrix for use on PvE. It is intended to cut down on rail/iron costs and digging time by using redstone to send routing information across hundreds or even thousands of blocks, usually along a single rail line. CARBON currently uses a series of pulses along a single redstone wire to send data(serial transfer), though it is not restricted to using other methods of sending information. A single CARBON is commonly referred to as a unit, while multiple units routing across large distances may be referred to as a network.


History

CARBON as a whole has seen countless revisions and redesigns, as new concepts have been implemented or replaced with better ones. The first records of what would later become CARBON exist around late PvE 9, just before the time that iron grinders were starting to become popular on the servers. Back then, the system was instead known as the now deprecated term SIN(serial interpreting node), and used a bulky design to capture up to 6 bits of information. The system was 3 times the size of current units, could not save the information it processed for longer than a second or so, and operated on 4 ticks per bit, which was considered extremely fast at the time.

After 1.4 which brought repeater locking, the system really began to shine, working at speeds considerably faster than the original under a much smaller space.

However, due to a bug with repeater locking, units could not operate using 1 repeater per bit without corruption when unlocking. After many redevelopments to try and compensate for this bug, it was eventually decided that units would have to save and resend data to the next unit in line. The data would still corrupt when unlocked, however it was irrelevant as it would only normally only unlock to receive a new packet. This particular method proved to be extremely effective at solving several issues facing CARBON at the time, as well as circumventing the repeater bug. Eventually CARBON units that were built in this manner were known under the Soda configuration.

Soda quickly became the standard, and is used a now used in most CARBON units today.