I'd have done these seperately, but they all interlock.
Fuel and consumables:
We could add consumables containment based on the current energy tank blocks. All of these could become valuable trade goods, particularly if there were some trade-mechanism for refilling a ships tanks. Just like energy tanks, these blocks add storage capacity for these consumables to a structure.
Energy generation and Consumable Replenishment:
(note: it's best not to run fusion reactors and Deuterium synthesis units on the same structure. They cancel each-other out, or maybe bleed energy
Propulsion:
Relativity?: I'd like to see the addition of relativistic effects. on high speeds. I don't see a good way to really do time dilation, but we could make the approach to the server speed limit asymptotic. Treat it like the speed of light. Let ship mass increase with speed such that as you approach the server speed limit, your mass increases without bound, so you can never actually reach the limit, just get closer and closer to it.
So, if m is the resting mass of the ship, C is the standard server speed limit, x is the speed of the ship and m' is the effective mass of the ship after relativistic acceleration:
m'=(-Cm)/(x-C) So as x approaches C, m' approaches infinity, and acceleration approaches zero. So even if you have a nimble ship with big engines, no more bang-zoom to maximum speed.
Warp Drive:
Not really a drive exactly. Warp changes the rules of acceleration within a "bubble" around the ship. Normally, your ship mass is described as m'=(-Cm)/(x-C). Warp locally changes the speed of light by a "factor" of W: m'=(-CWm)/(x-CW) allowing you to exceed the normal server speed limit. W is normally 1 This process should consume VAST amounts of -e per second, probably requiring at least one antimatter reactor. As the speed of the ship exceeds an actual hard speed limit set on the server, the client no longer renders the universe, and the server no longer instructs the other clients to render the warping ship. The star-field on the client is replaced by a streaking stars effect. The ships position is tracked virtually by the server until the ship decelerates to render-able speeds.
Warp relies on a 2 part system.
Fuel and consumables:
We could add consumables containment based on the current energy tank blocks. All of these could become valuable trade goods, particularly if there were some trade-mechanism for refilling a ships tanks. Just like energy tanks, these blocks add storage capacity for these consumables to a structure.
- Deuterium (2H) containment pods: Fuel for Fusion reaction.
- Oxygen (O2) Containment pods: Oxidizer.
- Hydrogen (H) Containment pods: Oxidizee and reaction mass.
- Positron (AKA Antimatter) (+e) Containment pods: Antimatter containment requires constant power, so they are constantly using part of their own stored power to maintain containment.
Energy generation and Consumable Replenishment:
- Elemental separator: engaged via "T" menu. Alters the function of the mining beam such that mining ice replenishes H at 66%, O at 33% and 2H at 1%
- Deuterium Synthesis Unit: Consumes -e, and H over time. Replenishes 2H.
- Hydrogen scoop: Replenishes H over time in interstellar space (void systems) at a rate proportional to the speed of the ship.
- Solar Collector: Produces -e. Production rate based on inverse square of distance to star. 4X resistant to solar damage, doubles as heat shielding
- Positron Collector: Produces +e. Production rate based on inverse square of distance to star, but capture rate is at most 1% of solar capture.
- Current generators(Gravitational wave capture?) Produce -e Free energy! Yay! Great for alpha versions of the game, but can we nerf output severely as we approach production, or make it server-settable?
- Fuel cell: Consumes Hx2 and O. Generates -e. spawns an ice block in the vicinity of the ship
- Fusion Reactor: Consumes 2H. Generates -e and H.
- Antimatter Reactor: consumes +e per second. Generates VAST amounts of -e.
(note: it's best not to run fusion reactors and Deuterium synthesis units on the same structure. They cancel each-other out, or maybe bleed energy
Propulsion:
Relativity?: I'd like to see the addition of relativistic effects. on high speeds. I don't see a good way to really do time dilation, but we could make the approach to the server speed limit asymptotic. Treat it like the speed of light. Let ship mass increase with speed such that as you approach the server speed limit, your mass increases without bound, so you can never actually reach the limit, just get closer and closer to it.
So, if m is the resting mass of the ship, C is the standard server speed limit, x is the speed of the ship and m' is the effective mass of the ship after relativistic acceleration:
m'=(-Cm)/(x-C) So as x approaches C, m' approaches infinity, and acceleration approaches zero. So even if you have a nimble ship with big engines, no more bang-zoom to maximum speed.
- Current coil thrusters (Impulse drive?) Reactionless drive! Yay! Consumes -e. high thrust. symmetric thrust. Great for alpha versions of the game, but can we nerf thrust severely as we approach production, or make it server-settable? I'd drastically lower the thrust per energy consumption and per block.
- Chemical Rocket: High thrust. relativistic. Consumes Hx2 and Ox1 very quickly. Rockets only provide thrust if they are the rear-most block in their longitudinal row. Thrust is asymmetric, imparting pitch or yaw if not aligned with ship center of mass.
- Ion Drive: low thrust. relativistic. Consumes H and -e very slowly. Ion drives provide thrust only if they are the rear-most block in their longitudinal row. Thrust is asymmetric, imparting pitch or yaw if not aligned with ship center of mass.
Warp Drive:
Not really a drive exactly. Warp changes the rules of acceleration within a "bubble" around the ship. Normally, your ship mass is described as m'=(-Cm)/(x-C). Warp locally changes the speed of light by a "factor" of W: m'=(-CWm)/(x-CW) allowing you to exceed the normal server speed limit. W is normally 1 This process should consume VAST amounts of -e per second, probably requiring at least one antimatter reactor. As the speed of the ship exceeds an actual hard speed limit set on the server, the client no longer renders the universe, and the server no longer instructs the other clients to render the warping ship. The star-field on the client is replaced by a streaking stars effect. The ships position is tracked virtually by the server until the ship decelerates to render-able speeds.
Warp relies on a 2 part system.
- Warp coil: The size and geometry of the warp coil should determine the factor W, where W= (2 (5 x-11))/(x+5). Warp coil blocks must all be contiguous. Each must be touching exactly two other warp coil blocks. Each block must be touching exactly 2 Antimatter reactors. Each antimatter reactor consumes 1 +e per second
- Warp Enhancers: The second part of the system is the warp nacelles or "enhancers" that expand and shape the warp bubble around the ship in exactly the way the docking and turret enhancers define the docking space. All of the blocks of a ship must be within at least one defined field or the warp drive does nothing. Overlapping fields have no negative effect. Fields are generated around the bounding box of each enhancer cluster, as well as around the warp core to a radius of half the average longest dimension of all the enhancer clusters