Faster Than Light Travel

(Note: this is an entry detailing the procedures of faster than light travel. For the technicalities of the geometry drive, you may refer to the relevant section.)

This entry was written by navigation AI Aqualonde.

Travelling faster than light only has one hard requirement: the presence of a correctly sized geometry drive aboard a ship. The rest, all the rest, like navigation systems, aren't needed.

If you do not mind waiting a few hundred years for your regular onboard chip to calculate the translation that is.

The main commodity of faster than light travel is computing ability. Geometry drives are not exactly hard to come by - though not extremely common, they can be rather easily manufactured when the right conditions are met. Geometry drives, however, are just tools. On their own, they are useless. In order to be usable as a faster than light device capable of translating a ship, they need to be fed navigation data.

Now I need you to fully understand what I mean by navigation data. Geometry drives do not need a simple trajectory on a map - and the universe knows how hard it can be to figure out the shortest practical route between two points on the ground. What they need is translation data. Translation data to tell a possibly alien device capable of folding three-dimensional space where to send a ship. Saying that this is somewhat hard would be the understatement of the millennium. In fact, I am not sure there is a single person alive who actually understands the full process involved in the calculation of navigation data. And for that matter, yes that includes AI persons. 

Oh, I forgot something. In the beginning, we assumed that the complexity of translations was proportional to the distance travelled. We quickly realized the relationship was in fact exponential. In other words, computing a translation over two lightyears is roughly four times more complex than over a single lightyear. This is the reason why most ships prefer multiple short-range translations over a single long-range one. Even with the downtime between jumps and the multiple engine burns required to match the relative velocity of the target, several short jumps will always be notably faster. Of course, navigation data doesn't have to be performed by the translating ship directly. In fact, what generally happens for everyday translations is that ships will transmit a computation request to a local station, which computes the translation and beams the data back to the ship, leveraging its bigger size and better heat dissipation to achieve greater computing speeds.

Now you may have a great idea at the back of your head: why don't we pre-calculate the most common translations and feed them directly to ships without re-computing them constantly?

Because translations are relative and everything is always in motion: stars relative to each other, ships relative to celestial bodies, and celestial bodies relative to the centre of the galaxy. There are never two identical translations and even slight differences require complex recalculations. Everything has to be recomputed constantly.

In short: you cannot escape the tyranny of the geometry drive. If you want to get far and fast you need powerful navigation computers or dirty theoretical tricks like the ones the Starmoth Initiative uses to streamline calculations in gravitationally lensed regions.

One last parameter has to be taken into account, one which is often overlooked by surface dwellers. Given that translations are relative and conserve momentum, a ship that wants to drop in a stable position must be able to meet the relative velocity of its target. Even with modern equipment, determining the exact relative velocity of a distant celestial object can be a challenge, hence why exploration ships often perform a translation to a mid-point location to ensure a more accurate drop.

In short, the full process for a geometry translation will look like this :

1 - The ship's navigation officer announces the beginning of a translation process.

2 - The distance, relative position and relative velocity of the target point are assessed.

3 - The ship begins the calculation process or asks a navigation station for data.

4 - The navigation officer announces a high-g state and the ship begins its engine burn to match the relative velocity of the target. If the ship is only equipped with low thrust engines, this phase actually began several hours or days before.

5 - The ship finally completes the calculation (or receives the data). On-board systems wait for the ship to reach the desired velocity and orientation.

6 - The navigation officer announces pre-translation sequence, also known as "blue sequence." The geometry drive is powered up. At this point, the translation cannot be cancelled anymore.

7 - The ship translates away.

All content in the Starmoth Blog is © Isilanka
Written content on Starmoth is distributed under a Creative Commons Attribution Non-Commercial Share-Alike 4.0 license