KANI Rail System

KANI
The KANI's logo, made by Gotter
KANI's coverage as of December 5th, 2021
Community Project
Goals:	Automatic Rail Routing Maintenance and Expansion of Rail Networks
Administrators:	Amelorate
Website:	amel.pw/kani/
Project Github	KANI
Discord:	4JuByFCQqJ
Status:	Inactive

The KANI ERS, used to route between rail stations

The KANI Rail System, usually referred to as just KANI (Knot and Nexus Interchange), formerly NIG(Nexus International Gateway) was a rail routing standard. It was the largest rail system in CivClassic 2.0, competing with the GOR, the AURA, and SARS. The system was originally based around many interconnected switching roundabouts, but later the system was retrofitted to support routing along straight rails such as the HITS.

The routing standard was created by Amelorate for the remodeled Nexus rail hub using the Icenia Transit System as a base.

Specification

The KANI was strictly specified from the system's inception. Originally the specification was listed on Amelorate's website, but it was eventually moved to the KANI discord. Routing data on the KANI is stored in a Github repository in TOML files in the data folder. By convention, Terminal Stations, Junctions, and Stations are stored in different folders based on the quality of the switch, however this is not required. Additionally, there was an unspoken rule that as long as things work equivalent to the specification, it is okay to bend the rules of the specification in order to be compatible with other standards or routing concepts.

Canonical Destination

A Canonical Destination is a unique identifier for a place on the KANI. Usually it is all lowercase, and to specify namespacing such as junctions or nations it uses a colon (:). If a Canonical Destination starts with j: that indicates it is a Junction. In the KANI data repository, the point's Canonical Destination is specified by the file's name, and its location must be set in the x and z attributes. Additionally, all files in the repository must specificy all destinations the point is connected to in the links list.

Terminal Station

A Terminal Station is an end-point in the KANI, and is the simplest possible station. This designation is used to indicate that the station is a "dumb" station, where the only possibility is to get out of your minecart if you arrive, or get on the minecart to depart. When routing using the ERS, the links list is only considered when the start or end destination is set to the Terminal Station. In the KANI TOML data file format, a Terminal Station is determined by the lack of a station or switch field.

Junction

A Junction is a point on the KANI where routing of some sort occurs. This is either a roundabout, a directional switch, or some non-standard switch. Non-standard switches are usually accompanied by a warning message because of how they often misroute players. A junction shall have switch = true in its KANI data file.

Station

Stations are a combination of a Junction, and a Terminal Station. At a station, you can be automatically routed towards another Canonical Destination, or automatically stop at the station. They were once required to have a track allowing easy disembarking from the station without using a special destination, but this requirement was dropped when the ERS was introduced because all routes to a station now included CanonicalDestination:exit in the /dest command. A station must have station = true in its TOML KANI data file in order to route correctly.

Routing on the ERS

The ERS routes players by following a strict algorithm. It starts at the player's starting point, and uses a routing algorithm such as A* to find the shortest path through Junctions and Stations to the player's desired destination. Then, for each Junction and Station in the path it adds the required destination to get to the next Junction/Station to the /dest, and then finally removes any duplicated destinations from the command. Additionally, if the player's desired destination is a Station, it adds the station's Canonical Destination followed by :exit to the /dest command.

Lines

Lines are implemented using the BadLinks subsection in the KANI data file format. Every three-way junction on the line is given its own Canonical Destination, but each data file should specify the junction that's "next" and "previous" on the line with a consistent BadLinks entry. For example, j:hits_atlantis has j:hits_ll to the north of it, so the BadLinks says that j:hits_ll should be replaced with hits:north. This is repeated for each switch in the line in both directions. When routing from one end of the line to another, the ERS would emit a destination similar to /dest thoria hits:south hits:south hits:south hits:south september september:exit. The next step of the ERS automatically removes the duplicate hits:south entries to become a valid /dest command.

History

The first prototype of the KANI was a simple one-way roundabout RailSwitch system around downtown Icenia (CivClassic 2.0). Using this system, Amelorate reasoned about the various rail systems they've seen around the server and eventually came upon one solution for the spaghetti junctions RailSwitch had become known for. At the time, there was no modularity to the destination command, so the only two ways to implement a routing network was to either have all rails return to a central hub for routing, or to have every switch be aware of every destination in the network. Most networks did neither.

Amelorate modified the RailSwitch plugin to implement the now well-utilized word-splitting OR mechanic in the destination command, and then started to remodel Nexus and the j:knot junction. Nexus featured several elements that weren't nearly as emphasized in future stations. For example, Nexus had a disembarking track that ran back and forth for about 20 seconds to allow players to get off the switch and retreive their minecart. This was implemented at the time because players were expected to write their destination commands manually and they would likely omit the 0,0:exit element. At this time, all switches were documented on Amelorate's personal website, and players were expected to write their own destination commands.

The first iteration of the NIG ERS

After a few switches were built, the KANI started to outgrow its TiddlyWiki documentation. Most players didn't understand the layout of the network, which made it very difficult to write a /dest command and get to their desired destinations. To significantly ease these issues, Amelorate wrote what was at the time called the Nexus International Gateway Express Routing System (NIGERS, pronounced nai-jers). An announcement was made upon the CivClassic subreddit, and Amelorate was quickly threatened into renaming the NIG because the post lacked the pronouncement of the web app.

During this time, Amelorate contempted ending their efforts on the NIG because of this threat. However, in a sudden revelation it was revealed to Amelorate a suitable name for the rail system: KANI. Not only was the name based on the Japanese word for crab, but it also sounded like Cunny. Additionally, if the KANI were to ever be connected to the GOR the combined acronym of the two (KANI-GOR) contains the rail system's original name. These factors helped to reinforce the idea that Amelorate was a true anime fan, so continuing the KANI became a desirable idea for Amelorate.

Earliest map of the KANI on CCMap

With the new name and an increased presence on the CivClassic subreddit, the KANI entered a new age of player contribution. Gjum rewrote the ERS web app to compute the command in the web browser which significantly reduced load times for the ERS, as the previous version downloaded a JSON file containing the command for each pair of origin and destination. More nations got connected to the KANI, and a KANI layer was added to CCMap.

Around this time, the KANI also got competition. Namely, the AURA and SARS. The SARS eventually became OneDest on future servers, however on CivClassic it never expaned outside the South Augusta area. The AURA aimed to be a strict superset of the KANI, however it eventually fell victim to its complexity as it allowed too many different kinds of switches. However, taking influence from the AURA, the KANI implemented functionality to implement two-way trunk rails. This eliminated a common complaint that destination commands for trunk rails were too long. Before this change, destinations that traveled from one end of a trunk rail to the other would refer to each junction along the rail. This functionality could have one day been used to integrate the KANI with the GOR without impacting the usage of the GOR without the KANI.

When Amelorate's interest in CivClassic waned, the routing system slowly decayed into disrepair. At this time, Amelorate expected the community to fix rails as they came across issues. This did not happen and the KANI gained a poor reputation for being in poor repair by the end of CivClassic 2.0. One factor that compounded this issue was the fact that there was no one central NameLayer group for KANI infrastructure. In fact, most infrastructure was on unknown groups after being repurposed unused rails, and thus was very difficult to repair.

When CivClassic 2.0 ended, Amelorate announced the KANI would not move to any future Civ server although others would be allowed to implement the standard. Nobody implemented the standard as the OneDest standard was better, so the KANI naturally dissolved at this time.

Trivia

• The KANI connected to the GOR through Mount Augusta (CivClassic 2.0)'s rail system around South Augusta, specifically j:sa:west. South Agusta had a section of rail that went above ground and eventually merged with the GOR. This was not represented in the ERS in order to prevent controversy.

External Links

• Nexus International Gateway's original documentation
• Express Routing System
• KANI Github