- Joined
- Jun 29, 2013
- Messages
- 245
- Reaction score
- 68
Preface:
The basic idea is that we can split the rail docker into a couple different blocks. Each one will behave differently in some respect, including the physics calculations they require (one big thing they generally have in common is to not need to worry about physics calculations with the parent entity except while moving).
The type of rail docker a vessel uses to dock to a mother ship will determine which type of docked entity it is. I will list each one's features here.
The Ship Part type in particular (as defined later in the post) can be potentially used in interesting ways, such as having detachable command bridges or jump drives.
Edit: Existing rail dockers would be converted to Ship Rail Dockers. Existing ships would thus need to quickly undock, re-fit, and re-dock their turrets and other non-ships upon this being patched.
Ship Rail Docker: Used for docking ships to your vessel.
-Receives full protection from mothership (or station) shields.
-Receives full protection from mothership radar jammers, cloaking, etc.
-Mass of the docked ship is merged with the mothership while docked (this affects jump drives, jammers, thrust, etc).
-Active AI modules will remain active, but will not actually do anything. Upon undocking, an active AI will begin controlling it as it normally would. Optionally, they may first try to fly straight forward a bit first, which could be useful for allowing them to exit the vessel without hassel.
-Cannot fire weapons or support system beams while docked (so no logic-powered guns).
-Can receive power generation from the mother entity, one-way only. Both vessels do NOT share power capacity however, and the parent vessel only gives it energy if its own power storage is full.
-Collision physics with the mothership/station are only run while the entity is moving (i.e. on a rail). Physics with other entities are run as normal.
When Ship Docker or Rail has been destroyed:
-The docked entity will detach and become a separate entity, as if it were undocked. If it has an enabled AI, then this too begins acting as if it were undocked.
Turret Rail Docker: Used for docking turrets (or pieces of them for multi-part ones).
-Receives partial protection from mothership shields. Can be damaged when mothership shields are reduced, much like current docks can.
-Receives full protection from mothership jamming, cloaks, etc.
-Mass of the docked ship is merged with the mothership while docked (this affects jump drives, jammers, thrust, etc).
-Collision physics with mothership/station is only run while entity is moving (i.e. on a rail).
-Can receive energy generation from the mothership one-way, and also shares energy capacity with it (preferring to use the mothership's power capacity over its own).
-Enabled AI blocks on turrets treat their entity as a turret.
New options: The main ship's options will include the following new features:
-The ability to set all turrets into one of three modes (this can also be selected individually by turret).
Mode 1: On (enables AI blocks on turrets).
Mode 2: Off (turns off AI blocks on turrets).
Mode 3: Manual (turrets will attempt to aim at where you are currently aiming, and their AI modules will target whatever you have targeted).
-if the ability to fire multiple weapons at once is ever implimented, then turrets in manual mode could be linked with other weapons, and would fire whenever they are able to fire in the direction you are telling your weapons to shoot it.
When Turret Docker or Rail has been destroyed:
-Turret does NOT undock from the mothership, and remains at its current location relative to the mothership.
-Turret becomes locked in its current orientation. Because it is no longer moving, it no longer worries about collision physics with the mothership (it does still collide with other entities though).
-The turret is no longer able to share energy or capacity with the mothership. It remains capable of using its own power generation and capacity, and if it still has its AI block can still shoot if something happens to fly in its (now limited) firing arc.
Ship Part Rail Docker: Used to attach moving structural parts to vessels.
-Is fully protected by mothership shields, jammer, cloakers, etc.
-Energy generation and capacity is fully merged with the mothership's (so when in build mode for the mothership, you will see the stats as if they were part of the mothership).
-Shield generation and capacity is fully merged with that of the mothership. This means it effectively has no shields of its own, since they now belong to the parent entity, and will start taking damage the same time the rest of the mothership does.
-Thrust from thrusters if fully merged with that of the mothership.
-Structural and system HP is fully merged with that of the mothership (as such, they cannot overheat alone while docked. It does however remember its default values, and undocking a badly damaged part could result in you instantly overheating said part and needing to reboot it).
-Obviously, mass and volume are also merged, so the parent vessel will need to worry about Ship Parts when charging jump drives, etc.
-Are destroyed when the mothership's overheat countdown finishes.
-Weapons or other systems on the ship part can be assigned to the mothership's number bar as if they were the mothership's weapons.
-However, you cannot link systems across the dock (so a weapons computer on the docked entity can ONLY be connected to weapons blocks on the same entity, and same for the parent vessel))
-An active AI module would act as if it were controlling the mothership.
-When in the Ship Part's core, you gain the mothership's number/ability bar, and your controls are linked to the mothership. This means you can use a smaller vessel to control a larger one as some form of detachable bridge.
-You cannot dock a Ship Part to a parent vessel unless you have permission to actually operate the parent vessel.
-Physics collisions ignore the parent vessel except when it is moving (i.e. along a rail or something)
Edit: (potentially optional) Since a ship part can be considered part of the ship, the parent ship's weapons would pass through it like it would any other part of the parent ship (and vice versa, in the event the ship part has weapons)
Edit: Ship parts do not need to show up on the HUD. There could be a toggle for them that defaults to "off" though, in case someone does for some reason want to see them in a particular situation.
-(Optional but would be useful): When in build mode on the mothership, a key or advanced build mode option would allow you to switch between the main ship and each docked Ship Part, allowing you to easily modify the attached parts.
When a Ship Part Rail Docker (or its rail) is destroyed:
-The Ship Part is no longer able to move and is effectively "jammed in place," but remains attached to the vessel.
-Since it is not moving, it doesn't worry about collisions with the parent vessel.
-All shared resources, energy/shield generation, structure HP, and etc are still shared.
-(Optional): However, upon the docker or its active rail block being destroyed, the vessel's merged structural and system HP may take some damage. Perhaps something like 10% of what the docked ship part contributes to the total? This represents the fact that a structural weak point may have been damaged, and adds a minor drawback to simply using the convenience of easily replaceable armor plates for a vessel instead of giving it "built-in" armor.
(Optional) For ALL docker types: Basically something that could help a ship "remember" that it has a jammed turret/ship block, so it doesn't spontaneously detach them.
-When destroyed, dockers are no longer removed from the ship. Instead, they act similarly to a "destroyed" ship core. Damage and shots will pass through them, but they will not disappear.
-A destroyed docker of the non-ship variety can be used to undock, but cannot be used to dock.
-A destroyed docker will not give you a part when removed.
-(optional, but useful) A docker of the same type can be used to repair the destroyed one without need for removal and replacement, therefor allowing you to make the repair without undocking an attached turret or ship part (is a moot point for ships since those would still undock).
Other notes:
-When I say "does not worry about colliding with parent vessel," I mean with the parent vessel itself. It still can collide with other docked objects on the parent vessel.
-When I say it only worries about collision physics when moving, this also means "when it has received instructions to start moving."
-In the event the developer is fine with "docked reactors," then Ship Parts could be permitted to have their own separate softcap when their power generation is merged. Otherwise, the softcap would be applied after merging to prevent such exploits.
The basic idea is that we can split the rail docker into a couple different blocks. Each one will behave differently in some respect, including the physics calculations they require (one big thing they generally have in common is to not need to worry about physics calculations with the parent entity except while moving).
The type of rail docker a vessel uses to dock to a mother ship will determine which type of docked entity it is. I will list each one's features here.
The Ship Part type in particular (as defined later in the post) can be potentially used in interesting ways, such as having detachable command bridges or jump drives.
Edit: Existing rail dockers would be converted to Ship Rail Dockers. Existing ships would thus need to quickly undock, re-fit, and re-dock their turrets and other non-ships upon this being patched.
Ship Rail Docker: Used for docking ships to your vessel.
-Receives full protection from mothership (or station) shields.
-Receives full protection from mothership radar jammers, cloaking, etc.
-Mass of the docked ship is merged with the mothership while docked (this affects jump drives, jammers, thrust, etc).
-Active AI modules will remain active, but will not actually do anything. Upon undocking, an active AI will begin controlling it as it normally would. Optionally, they may first try to fly straight forward a bit first, which could be useful for allowing them to exit the vessel without hassel.
-Cannot fire weapons or support system beams while docked (so no logic-powered guns).
-Can receive power generation from the mother entity, one-way only. Both vessels do NOT share power capacity however, and the parent vessel only gives it energy if its own power storage is full.
-Collision physics with the mothership/station are only run while the entity is moving (i.e. on a rail). Physics with other entities are run as normal.
When Ship Docker or Rail has been destroyed:
-The docked entity will detach and become a separate entity, as if it were undocked. If it has an enabled AI, then this too begins acting as if it were undocked.
Turret Rail Docker: Used for docking turrets (or pieces of them for multi-part ones).
-Receives partial protection from mothership shields. Can be damaged when mothership shields are reduced, much like current docks can.
-Receives full protection from mothership jamming, cloaks, etc.
-Mass of the docked ship is merged with the mothership while docked (this affects jump drives, jammers, thrust, etc).
-Collision physics with mothership/station is only run while entity is moving (i.e. on a rail).
-Can receive energy generation from the mothership one-way, and also shares energy capacity with it (preferring to use the mothership's power capacity over its own).
-Enabled AI blocks on turrets treat their entity as a turret.
New options: The main ship's options will include the following new features:
-The ability to set all turrets into one of three modes (this can also be selected individually by turret).
Mode 1: On (enables AI blocks on turrets).
Mode 2: Off (turns off AI blocks on turrets).
Mode 3: Manual (turrets will attempt to aim at where you are currently aiming, and their AI modules will target whatever you have targeted).
-if the ability to fire multiple weapons at once is ever implimented, then turrets in manual mode could be linked with other weapons, and would fire whenever they are able to fire in the direction you are telling your weapons to shoot it.
When Turret Docker or Rail has been destroyed:
-Turret does NOT undock from the mothership, and remains at its current location relative to the mothership.
-Turret becomes locked in its current orientation. Because it is no longer moving, it no longer worries about collision physics with the mothership (it does still collide with other entities though).
-The turret is no longer able to share energy or capacity with the mothership. It remains capable of using its own power generation and capacity, and if it still has its AI block can still shoot if something happens to fly in its (now limited) firing arc.
Ship Part Rail Docker: Used to attach moving structural parts to vessels.
-Is fully protected by mothership shields, jammer, cloakers, etc.
-Energy generation and capacity is fully merged with the mothership's (so when in build mode for the mothership, you will see the stats as if they were part of the mothership).
-Shield generation and capacity is fully merged with that of the mothership. This means it effectively has no shields of its own, since they now belong to the parent entity, and will start taking damage the same time the rest of the mothership does.
-Thrust from thrusters if fully merged with that of the mothership.
-Structural and system HP is fully merged with that of the mothership (as such, they cannot overheat alone while docked. It does however remember its default values, and undocking a badly damaged part could result in you instantly overheating said part and needing to reboot it).
-Obviously, mass and volume are also merged, so the parent vessel will need to worry about Ship Parts when charging jump drives, etc.
-Are destroyed when the mothership's overheat countdown finishes.
-Weapons or other systems on the ship part can be assigned to the mothership's number bar as if they were the mothership's weapons.
-However, you cannot link systems across the dock (so a weapons computer on the docked entity can ONLY be connected to weapons blocks on the same entity, and same for the parent vessel))
-An active AI module would act as if it were controlling the mothership.
-When in the Ship Part's core, you gain the mothership's number/ability bar, and your controls are linked to the mothership. This means you can use a smaller vessel to control a larger one as some form of detachable bridge.
-You cannot dock a Ship Part to a parent vessel unless you have permission to actually operate the parent vessel.
-Physics collisions ignore the parent vessel except when it is moving (i.e. along a rail or something)
Edit: (potentially optional) Since a ship part can be considered part of the ship, the parent ship's weapons would pass through it like it would any other part of the parent ship (and vice versa, in the event the ship part has weapons)
Edit: Ship parts do not need to show up on the HUD. There could be a toggle for them that defaults to "off" though, in case someone does for some reason want to see them in a particular situation.
-(Optional but would be useful): When in build mode on the mothership, a key or advanced build mode option would allow you to switch between the main ship and each docked Ship Part, allowing you to easily modify the attached parts.
When a Ship Part Rail Docker (or its rail) is destroyed:
-The Ship Part is no longer able to move and is effectively "jammed in place," but remains attached to the vessel.
-Since it is not moving, it doesn't worry about collisions with the parent vessel.
-All shared resources, energy/shield generation, structure HP, and etc are still shared.
-(Optional): However, upon the docker or its active rail block being destroyed, the vessel's merged structural and system HP may take some damage. Perhaps something like 10% of what the docked ship part contributes to the total? This represents the fact that a structural weak point may have been damaged, and adds a minor drawback to simply using the convenience of easily replaceable armor plates for a vessel instead of giving it "built-in" armor.
(Optional) For ALL docker types: Basically something that could help a ship "remember" that it has a jammed turret/ship block, so it doesn't spontaneously detach them.
-When destroyed, dockers are no longer removed from the ship. Instead, they act similarly to a "destroyed" ship core. Damage and shots will pass through them, but they will not disappear.
-A destroyed docker of the non-ship variety can be used to undock, but cannot be used to dock.
-A destroyed docker will not give you a part when removed.
-(optional, but useful) A docker of the same type can be used to repair the destroyed one without need for removal and replacement, therefor allowing you to make the repair without undocking an attached turret or ship part (is a moot point for ships since those would still undock).
Other notes:
-When I say "does not worry about colliding with parent vessel," I mean with the parent vessel itself. It still can collide with other docked objects on the parent vessel.
-When I say it only worries about collision physics when moving, this also means "when it has received instructions to start moving."
-In the event the developer is fine with "docked reactors," then Ship Parts could be permitted to have their own separate softcap when their power generation is merged. Otherwise, the softcap would be applied after merging to prevent such exploits.
Last edited:
