Consolidated thrusters ideaguys discussion as well as summary of end round shuttle / escape shuttle / pod gameplay design.

# Transit to Central Command (Centcom)
Firstly, this process NEEDS to be automated. Leaving the piloting of shuttles up to players will result in people never reaching centcom. I don’t care how emergent that may seem for gameplay but I foresee a 99% chance of people never making the trip and that’s without any antag intervention.

Solution: Autopilot
Solution explained: This aint particularly easy.

# Autopilot
This will either be a variation of the shuttle console or an actual module placed on the shuttle that can /possibly/ be interfered with by a traitor. This will have to be a mapped entity if we want to keep the AI as simple as possible and only focus on pathfinding and operating the docking airlocks. I’ll leave the logic upto the intrepid dev who wants to pursue this anyway.

# Escape Pods
Escape pods are another mapped feature which should typically be at maximum a 1x3 or 2x3 interior space (SS13 had them as 1x2 usually. They will have to be autopilot enabled as you can’t trust a botanist or assistant to be a pro pilot and navigate deep space to an end point. The autopilot will also likely have to be able to orient the pod as the docking will be in a different orientation to it’s launch (180 degrees if we’re decelerating with the same set of thrusters).

For escape pods to be space efficient we will need to make wall mounted atmos devices such as wall mounted air tanks and a wall mounted space heater so that the journey isn’t a death sentence. We can however make it uncomfortable unless the occupants are in an emergency suit (so still having cold debuff so they’re weaker on exit).

# Transit Process
Now that we’ve covered that autopilot is near enough necessary for end of round to be reliable gameplay, we need to discuss how we actually get from deep space to central command.

First and least likely candidate is just using thrusters to get there. This is unrealistic in that thrusters can’t go fast enough to represent how remote and isolated the station is. This however can be a stop gap until we have warp mechanics (Z levels). We need end of round gameplay soon rather than just hard restart at the end so this is step 1.

The second and more likely approach will be bringing back warping from SS13. In 13 this was probably to make up for the fact you didn’t have working moving shuttles (only pods which were singular entities like mechs). In our scenario, the shuttle will undock and accelerate up to speed and then warp from the existing grid into “transit space”.
This gives the illusion of long distance movement while time passes for X amount of time (say 1-2 minutes?). The shuttle then drops out of warp at a free point in space at the end Z level (this will need to account for other shuttles and escape pods all appearing at the same or similar time).

So now we need to discuss how the warp mechanic works in gameplay. Do we have an actual warp drive entity on board? Can it be a tiny sub floor module for small craft like escape pods but a full size anchored entity like the gyroscope for shuttles? Or do we have a warp gate as a point near the station that opens up at round end to let the shuttles and pods fly through in convoy (this would also be used for the cargo shuttle? Blip a monitor on the command deck for shuttles coming into range?). If we want shuttles etc to be piloted instead of autopilot then this works if the console has a pointer on where to go (if we do this then I totally want some sort of radical destruction mess up for people crashing into the gate structure).

Both systems have merit, personally a warp drive seems logical and easier for autopilot sake etc.

# Ancillary Considerations
As mentioned for escape pods, we need wall mounted atmos devices to make time in space tolerable and not a death sentence.

Others mentioned in discord chat that current air tanks don’t have the capacity for lots of people spending time in space (I mean the stations have infinite miners for this reason). So ideally we would have a mapped in super capacity air tank).
Antag opportunities
In SS13 this was often shuttle bombing. Since we have pilotable shuttles I envision some creative ways of sabotage such as emagging pod autopilot systems so they don’t decelerate and instead just smash into the centcom station. Similarly for the shuttle maybe we have a random selection of sabotage modes such as opening the airlocks during warp, not decelerating, ending up at the wrong end point (could have a bunch of different outcomes for this one such as syndi outpost, planet, crashing into another shuttle etc)

# Thruster Rework
Currently thrusters use a large amount of power to a point of roughly 1 generator per 2 thrusters (plus ancillaries). We need a variety of thrusters going forward.

Firstly, keeping the existing thrusters as a sort of low cost, electric propulsion for docking, RCS etc. But for larger, faster and more powerful thrusters we need to go fuel based.

Insert, the plasma thruster! The idea is that bigger 1x2, 1x3 and 2x3 thrusters will have a gas intake which will be for a plasma / oxygen fuel mix. (further I proposed having the actual burn mix be a randomly selected optimal burn so scientists can work on finding the best burn ratio). This makes sense that thrusters would consume a high flammability fuel and alleviates the need to have tons of generators on bigger shuttles.

Ideally thrusters will be more like they are in SS13 in that there will be a space facing component and an interior facing atmos blocking component so that the thruster can be accessed from inside the shuttle and not separated by walls. This means they can be maintained, interacted with and tampered with.

Regarding fuel mixes, you can just have a generic mix of say 70/30 plasma to oxygen but without knowing the optimal mix you’ll be wasting fuel and losing performance. We also have space for more gases (2 to be exact, 1 if we already earmark a slot for N2O). But to make the science more interesting you could also add in having N2O, tritium or other exotic gases into the mix for potential performance benefits or disastrous results (maybe not immediately either so shuttles won’t know till it’s too late.

It was also proposed that if finding the optimal fuel mix was too easy we can incorporate cooling to a degree so that if you want the thruster to work at its peak performance you may need to restrict the flow of fuel unless you incorporate active cooling. Since we don’t really have / want(?) plumbing of liquids, cooling would have to be done with gases and cycle in one side and out the other to a radiator on the exterior (or interior if you want to recycle some heat) and back.
This means if you don’t properly cool your thrusters and go balls to the wall with performance then you can expect them to malfunction, melt or blow up. (This aint fun without disaster and failure modes right?). The idea with having an interior facing component to thrusters is that instead of it just exploding to space and not having an effect, the interior section (or two if we want to go that way) will fail inwards, potentially melting a bunch of people fast and causing chaos.

Alternatively, we just have a plasma engine / TEG that produces absurd power for the thrusters but IMO that doesn’t scratch the itch of rocketry research but could also use the same idea for power generation.