CARBON
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.
Revision 9) Only very small scale networks were created on an experimental level on creative servers.
Revision 10) An experimental loop based network above the nether bedrock was developed. This was only to test CARBON on PvE's laggy environment, and never saw large scale use. Much of the work on this network was insightful, though the network was incomplete and considered a failure.
Revision 11) A bidirectional, linear based network was secretly developed in the overworld at x +/- 800 alongside Ram21 and aliaspanther. This was to test various transmission techniques on a large scale. Some towns were encouraged to join to aid in experimenting, though it was never formally announced for usage. However, a centralized network was built in the nether that did see usage. This was the first implementation of a public CARBON network on PvE. Pico also used its own parallel transfer based smartline system developed mainly by tc_chris to successfully route carts hundreds of blocks in the overworld.
Revision 12) A bidirectional loop was created at +/- 600 blocks out from spawn above ground. As of this writing, it is currently functional and new rail connections are actively sought after. This network is largely funded by redstone donations and trades. A small network of smartlines derived from tc_chris's and mattman00000's work on parallel data transfer was implemented in the nether.
Rail Jargon and Terms
To simplify communication, many of the CARBON workers have developed jargon. This section may be useful for those who are not familiar with the terminology. CARBON units are alternatively referred to as: relays, repeaters, repeater stations, or nodes. CARBON units which have received modification to allow direction of traffic flow are more specifically referred to as "routers" . Smart lines reference rails which are augmented by redstone rail data, which in most cases is CARBON or a derivative. The term "Dumb lines"(referring to normal rails) is not necessarily a pejorative in this case, just creating an easy distinction between the two. Normal rails may also be referenced as "direct lines."
CARBON Encoder Stations/CARTS Converters
A bare-bones encoder is extremely cheap to create, but requires binary input from the user. The standard bit-rate of a CARBON encoder is 1 ticks/bit using pistons, but comparator based designs can transfer at 2 tick/bit if slime supply is low. Note that the same design is used in the Soda configuration across standard CARBON units.
Due to the popularity of CARTS and how buttons are preferred for ease of use over levers, a simple converter was developed to save routing data behind a button. Converters are simple use, but tend to double or even triple the footprint of the overall station. This is a tradeoff of size vs. ease of use, and both direct encoding or using a converter produce the same results.
A 32-button station was developed by TheRandomnatrix and later compacted by countfizix. Variations of button layouts have also been developed by tc_chris for easy of reach/sign readability.
Anti-spam system
By attaching an adjustable hopper clock to the station encoder, you can prevent players behind you from messing up your signal. While not necessary, it is recommended for towns that can expect large traffic flow.
Connecting to CARBON
Once a network is in place, towns can connect into it by following a few simple steps:
1: Speak with one of the owners of the network about connecting. Odds are this information can be found in the #carbon clanchat
2: If accepted, make 2 rail lines to the loop, one to and one from
3: Build a CARBON station connected to those rails
4: Build relays under the rails spaced about 100 or so blocks apart.
5: Contact the owners of the network to finalize the connection
6: Enjoy CARBON and report any bugs you find