mirror of
https://github.com/ParadiseSS13/Paradise.git
synced 2025-12-19 14:51:27 +00:00
04ba5c1cc9
* Adds the check components * Adds in trailing newlines * Converts all CRLF to LF * Post merge EOF * Post merge line endings * Final commit
147 lines
6.3 KiB
Markdown
147 lines
6.3 KiB
Markdown
<!-- TOC depth:6 withLinks:1 updateOnSave:1 orderedList:0 -->
|
|
|
|
- [Shuttle system](#shuttle-system)
|
|
- [Introduction](#introduction)
|
|
- [Docking ports](#docking-ports)
|
|
- [/obj/docking_port](#obj-docking_port)
|
|
- [Variables](#variables)
|
|
- [/obj/docking_port/mobile](#objdockingportmobile)
|
|
- [/obj/docking_port/mobile](#objdockingportmobile)
|
|
- [Modifications](#modifications)
|
|
- [Shuttle Controller](#shuttle-controller)
|
|
- [Airlocks](#airlocks)
|
|
- [Initialization](#initialization)
|
|
<!-- /TOC -->
|
|
|
|
# Important note:
|
|
The following readme was last updated during Late 2015. The changes between Paradise & TG's shuttle system has diverged greatly since then. Do not take the documentation here's description of differences between tg & paradise seriously without double checking.
|
|
|
|
# Shuttle system
|
|
## Introduction
|
|
This folder belongs to the "shuttle" system. The shuttle system is used to control the
|
|
"Shuttles" on the map, which are, at their core, a rectangular area of turfs that "move".
|
|
|
|
The shuttle system is comprised of two primary files.
|
|
[`shuttle.dm`](http://github.com/ParadiseSS13/Paradise/blob/master/code/modules/shuttle/shuttle.dm),
|
|
which contains the primary code, and
|
|
[`shuttles.dm`](http://github.com/ParadiseSS13/Paradise/blob/master/code/controllers/Process/shuttles.dm)
|
|
which contains the back-end controller system.
|
|
There are a few other files, but it isn't worth noting on.
|
|
|
|
Shuttles are used for many purposes, including the end of rounds, so it's important to
|
|
understand them.
|
|
|
|
## Docking ports
|
|
### obj docking_port
|
|
The `/obj/docking_port` type is the primary component of the shuttle system. Almost all of
|
|
the shuttle system is controlled by the docking ports, the only thing that isn't, really,
|
|
is the shuttle manager, which manages, you guessed it, the docking ports.
|
|
|
|
Docking ports are split into two main types: `/obj/docking_port/stationary`, and
|
|
`/obj/docking_port/mobile`, but they share a few variables and procs defined at the
|
|
`/obj/docking_port` level.
|
|
|
|
#### Variables
|
|
`id`: This variable is used for any plain-text references to the docking port. It should
|
|
always be lowercase.
|
|
|
|
`width`, `height`: The width and height variables are **absolute** value variables which
|
|
define the bounding box of the docking port. It is very important to note that these are
|
|
different from the `dwidth` and `dheight` in terms of how they are counted. As they are
|
|
absolute representations of the size of the bounding box, they need to be equal to the
|
|
amount of turfs on the side of the bounding box. An easy way to think of it is, if you
|
|
start at the very corner piece, you would start the count at `1` from that corner piece,
|
|
IE, you move 1 turf in any direction, it would be `2`.
|
|
|
|
A crude ASCII example:
|
|
```
|
|
||D|||
|
|
```
|
|
Would be classed by the values `width` = 6, `height` = 1.
|
|
|
|
It is important to note that bounding boxes are *always* rectangular. However, shuttles
|
|
are allowed to be any shape they so wish, as anything that matches the `turf_type` of
|
|
stationary docking ports will not be moved with the shuttle- by default, this is equal to
|
|
`/turf/space`.
|
|
Another quick example of this:
|
|
```
|
|
|||
|
|
|||
|
|
|||
|
|
|||||
|
|
||||||D
|
|
|||||||
|
|
||| |||
|
|
```
|
|
This, even though it is not exactly a rectangle, would be classified by the values
|
|
`width` = `7`, `height` = `7`.
|
|
|
|
|
|
`dwidth`, `dheight`: The relative offset of the docking port to the bounding box. These
|
|
values are calculated **relative** to the bounding box. The values are counted from the
|
|
bottom left corner of the bounding box, **relative** to the direction of the docking port.
|
|
The "bottom left corner" changes depending on the direction of the docking port object.
|
|
so a docking port **facing north** that looks something like this:
|
|
|
|
```
|
|
|||
|
|
|||
|
|
|||D|
|
|
|||||
|
|
```
|
|
|
|
Would have a `dwidth` value of `3`, and a `dheight` value of `1`.
|
|
A docking port **facing south** that looks like this:
|
|
|
|
```
|
|
||||||
|
|
|||D||
|
|
||||
|
|
```
|
|
|
|
Would have a `dwidth` value of `2`, and a `dheight` value of `1`
|
|
|
|
|
|
### /obj/docking_port/mobile
|
|
`/obj/docking_port/mobile`, or, "Mobile" docking ports are used to define and control the
|
|
movement of the shuttle chunks. The "Mobile" docking port moves with the shuttle, and is
|
|
essentially attached to it. A "Mobile" docking port only moves to predefined positions
|
|
on the map, referred to as "Stationary" docking ports.
|
|
|
|
### /obj/docking_port/mobile
|
|
`/obj/docking_port/stationary`, or "Stationary" docking ports are used as predefined
|
|
references for where "Mobile" docking ports may move. "Stationary" docking ports do not
|
|
move unless something has gone horribly wrong. They are essentially static points in
|
|
space. Going into details, whenever a "Mobile" docking port "moves", it registers with the
|
|
stationary docking port that it was requested to move to, and moves itself to it. It is
|
|
important to note that docking ports will switch direction on the fly, and a "Stationary"
|
|
docking port not matching the initial direction of the "Mobile" docking port will cause
|
|
the entire shuttle to be rotated in order for the "Mobile" docking port to face the same
|
|
direction as the "Stationary" docking port.
|
|
|
|
|
|
## Modifications
|
|
There are three main differences between -tg-station13's shuttle system and the one in
|
|
use on Paradise, and none are very complex.
|
|
|
|
### Airlocks
|
|
The biggest modification comes in the form of how docking ports interact with airlocks.
|
|
With -tg-station13's base code, any door on the shuttle will be closed, and any door
|
|
directly next to the mobile docking port will be closed off of the shuttle.
|
|
|
|
In Paradise, however, when a mobile docking port undocks from the stationary docking port,
|
|
it will look for any door in the machine list who's `id_tag` variable matches the
|
|
stationary docking port's `id` variable. When it finds these doors, it will close *and*
|
|
bolt the doors shut. Any airlocks on the shuttle will be closed as per usual, but any
|
|
airlocks within the shuttle with the `id_tag` of `s_docking_airlock` will also be bolted,
|
|
and will stay bolted until the shuttle has exited transit space.
|
|
|
|
### Initialization
|
|
In -tg-station13's shuttle system, all docking ports register with the shuttle controller
|
|
on `New()`. However, as Paradise uses a different system for the shuttle controller, it is
|
|
not yet created when `New()` is called.
|
|
|
|
To fix this issue, all docking ports will not initialize automatically on `New()`.
|
|
Instead, they are manually initialized by the shuttle controller when it is created, via
|
|
a proc called `initialize()`.
|