If we go with an in-universe explanation for the situation with limpets, it is as if Company A developed these beautiful, programmable, multi-purpose devices... but the controllers for each of the useful applications was each developed by a separate, different company (B, C, D ve kw, who collectively couldn't even co-operate enough to write their software to run on the same hardware, thus necessitating a clumsy system where each application has to reside on different physical hardware, and so that no-one can reverse-engineer the software uploaded to the limpet, the limpets are programmed to self-destruct, and the ship-mounted modules are made so large and complex because they are chock-full of CPUs and DRM hardware.
This is in contrast to the fighter hangar modules, which can be reprogrammed to change the physical and software structure of their output, can carry the materials needed to produce multiple replacement fighters, and can build an entire replacement fighter to any available design in just 80 seconds!
Some rationalisation of limpets and their controllers needs to happen. No longer should we be slaves to inefficient proprietary software and hardware, and buy multiple versions of what is effectively the same physical hardware just so that we can run different applications on the same physical programmable devices. No longer should we put up with controllers that ridiculously program the devices that they control to self-destruct in the name of intellectual property security.
An ideal limpet controller would be able to store and program a number of limpets that depends on their size... each should be able to store and program a number of limpets equal to half the capacity of an equivalent-sized cargo module. Each would be able to accept a number of different application programs, from 1 or 2 for an E-class module to 5 or 6 for an A-class module, much as the fighter hangars can accept 1 or more fighter designs.
These new modules would not launch limpets that just die and vanish after a few minutes - when the limpets run out of energy, they should return to their bay for repair and recharge. This might take a minute for each drone, during which they would be unavailable.
Limpets should be available through the ship/fighter/SRV panel, or through a role-based fire button as is currently in effect.
This is in contrast to the fighter hangar modules, which can be reprogrammed to change the physical and software structure of their output, can carry the materials needed to produce multiple replacement fighters, and can build an entire replacement fighter to any available design in just 80 seconds!
Some rationalisation of limpets and their controllers needs to happen. No longer should we be slaves to inefficient proprietary software and hardware, and buy multiple versions of what is effectively the same physical hardware just so that we can run different applications on the same physical programmable devices. No longer should we put up with controllers that ridiculously program the devices that they control to self-destruct in the name of intellectual property security.
An ideal limpet controller would be able to store and program a number of limpets that depends on their size... each should be able to store and program a number of limpets equal to half the capacity of an equivalent-sized cargo module. Each would be able to accept a number of different application programs, from 1 or 2 for an E-class module to 5 or 6 for an A-class module, much as the fighter hangars can accept 1 or more fighter designs.
These new modules would not launch limpets that just die and vanish after a few minutes - when the limpets run out of energy, they should return to their bay for repair and recharge. This might take a minute for each drone, during which they would be unavailable.
Limpets should be available through the ship/fighter/SRV panel, or through a role-based fire button as is currently in effect.
