# Tram v6 (Subsystem)

## Abstract
The tram has grown in functionality over the past couple years, with the continual addition of new features. Running on the industrial lift code (elevators) each passing update the tram uses more and more edits to the elevator code. Elevator code has also received enhanced functionality for lifts themselves.

As tram and elevator complexity rises, and the amount of trams (now at 3) and elevators (now at 10+) continues to grow the code is still pretty specifically made for Tramstation's main station tram and is full of exceptions and alternate functionality.

The piecemeal approach makes the tram code less optimal than it could be, with duplication of procs and unnessecary processing which frequently traces back to the tram itself never really 'knows' where it is, particularly during movement.

This means that all the components around the tram independently use their own methods to keep track of the tram and keep it running properly. These components aren't communinicating with each other so end up duplicating things such as caclulating tram direction, position, destination, power, operating status, etc.

Auxillary features are on fastprocess while the tram is on tram_process, running twice as often as required and really don't need to be processing between tram movements.

This unifies components of the tram under the 'Transport' subsystem (a more generic naming scheme since this new system potentially could be used elsewhere in the future. Tram/elevator aware MULEbots? etc.)

## Goals
* Replace ssTramProcess with a transport control system that can easily scale with minimal additional code required for adding additional trams, and be open enough to be used for any type of 'transport'
* Refactor tram code to eliminate duplication of procs running on each atom that are better served with centralised control, move shared procs to a common subtype where possible
* Add new functionality that creates optional maintenance activities for engineering, without being critical to the tram's functioning
* Add strategic points for minor sabotage by antags
* Improve the 'tram malfunction' random event to be more interesting by adding player interactive elements. (Similar to radiation leak)
* Add more resiliency to the tram commands, allowing it to self-test/reset if something errors out vs. just breaking for the rest of the round
* Add logging for tram related actions (so issues can be actually looked into post-round)
* Make tram more player/admin friendly with status indications, context helpers etc. on how to repair the tram
* Move logic from auxillary machines to the subsystem, turning things like buttons etc into mostly dumb terminals that are player buildable/repairable (think blast door controller)

## Non-Goals
* Allowing new tram creation
* Expanding into material-system tram walls