#24 Bonding boxes for upgrades per "Main Engine as Upgrade"

[Travis]

As per the discussion in the referenced thread in the forums upgrades should be handled as stripped down sub-units so that they can suffer independent damage depending on where the craft is targeted. They also should be repairable by the repair droid.

[Travis]

Should add these features to upgrades as well:
Durability: how many times can you repair it and expect 100% functionality
Resiliency: Resistance to damage
Reliability: likelihood of failure without external damaging factors

[Turbo Beholder]

Durability - just make field repair below 1.0 Max Functionality. Beyond that, the question is just how much of the original item remained and how much replaced.
Resiliency - this seems to be an equivalent of Hull strength, just for an upgrade.
Reliability - heh, yes. Allows an option for maintainance, like in Frontier Elite.

[Turbo Beholder]

Perhaps not stripped down sub-units, but close to stripped-down mounts (without weapon info, that is). Property-wise, we seem to need two or three objects:

---

• Hardpoint - unifying Prohibited Upgrades, mounts and lights placements, possibly also used for external attachments, i.e. subunit and dock systems.
  1. Vectors - Position/Orientation (i.e. the ship's design should define where the reactor is placed, where pilot's cabin, etc - just like mounts).
     • All-zeroes defaults to "somewhere in the available space", replacing collision boxes with cross-section probability.
     • Knowing where everything (including sticking out less-important hull parts) is placed, we can properly count them toward the ship's MoI tensor, not only total mass.
  2. Slot - list of compatibility tags (unifying "mountsize" and "Prohibited Upgrades" here). An untyped hardpoint means whatever is plugged in it counts integrated as one item (necessary e.g. for set+"mult" or "add"+"mult" types) - they are installed or removed as one and Functionality value is mirrored.
  3. Internal/Window/External?
     • I - mesh isn't shown
     • W - mesh is placed from the window, and by its alternate attachment point: this should apply to guns (they have muzzle coordinates in weapon info), thrusters (these parts need to have Lights, which have coordinates) and dock ports.
     • E - mesh is visible and is not counted and checked vs. volume (the type of volume is reflected in Slot tags) of the current part (or the ship, if hardpoint belongs to the hull "root")

---

• Upgrade (now more a "ship part") - ruleset wise we'll need almost exclusively existing common fields of a ship table, but internally would use them as an upgrade's own properties, unless the upgrade is a modifier ("add"/"mult").
  1. Mountable: List of tags required from the hardpoint where it will be placed ("Special Medium").
  2. Capabilities Required: List of tags the ship needs to have (somewhere, at all) for the upgrade to function (paired with numbers).
  3. Capabilities Provided: List of tags the upgrade adds to the ship's capabilities (paired with numbers) - if it works.
  4. Hull - Upgrade itself has durability, if not other properties.
  5. Mesh
  6. Collision mesh (hitbox)
  7. Sprite (on the ship schematics pictogram)
  8. Volume
  9. Hardpoints - list of slots (they will be placed relative to the upgrade's own coordinates, of course)
  10. Explosion (it's always fun, and then some are missiles or ammo containing antimatter)

---

• Joint (can be attached to either, or even be made an intermediary part, though preferably to hardpoint) - usually NULL, but even without using them for collisions and g-forces we need to keep joints for generic parts, because they are needed for:
  • Autotracking via servos with finite angular velocity, not just insta-aiming (unlike the current implementation).
  • moving turret guns without full subunit overhead (unlike the current implementation).
  • moving "accessory" eye-candy parts - or even working upgrades, like a scanning radar, etc - as ship parts, i.e. without full subunit overhead (unlike the current implementation).