So, following the forum and all thread opened asking for, it seems that a great part of the player base is toward a unified limpet controller. Many aspect of the current limpet controllers are very unbelievable from a realistic point of view (such as their weight!) and, obviously, are more like placeholders to provide a sort of balancing in outfit the ships and use it.
I think on an unified limpet controller ALWAYS I need to fit one in one of my ship: why a 7 class controller weight 32 tons, yet do not provide any limpet by its own? Ok, they can control a maximum of 4 limpets (not sure why, maybe caused by the power cbsumption and the limits a 7 class slot can provide to its child module) but WHY it can provide ONLY ONE kind of behavior? Limpets are drone: they do what they need do be done. Currently, they are all the same, so there's no point at all in having half a dozen of specialized controllers which control the very same limpet in different ways: we are talking about software here, not hardware.
That's point us toward two different scenarios to have a more polished limpets mechanic:
1) software controller limpets
In this scenarios, we have just one kind controller, available in 1, 3, 5 and 7 size slot, as current, whith software subslots (like hangars). Each class can control a limited number of limpets at the same time (same power consumption related hypothesis as introduction). They will store limpets as ammo, which must be restock by synthesis or market. Limpets could be stored also as cargo, of course, but they should need a short amount of time to be prepared.
Here a brief summary:
All controllers should weight the same when empty (2ton) and possibly able to be modified somewhat by engineers...
2) specialized limpet
Thus scenario probably us the less desiderable, yet provide a more realistic approach. It suggest have different kind of limpets, which could be deployed in some different ways, by a unified controller.
So, there could be limpets which can provide "remote action" (like collection, hatch braking, repair, etc...) or "remote acknowledgement" (prospector, recon, research, etc...). The controller still will be able to provide a limited amount of limpets as ammo, but they can be only of a type (silly balancing ��
. You can stock any amount of limpet as cargo, but again a time will be needed to process them and restock the controller. In this case, at least two controllers will be needed for a miner ship.
Summary:
A controller will have an amount of software slots, as previously suggested, but it can host only related softwares (remote "action" or "acknowledging"). It provide limpets as ammo, in the same way, but only of the same kind of softwares. Restock, synthesis and deployment as first scenario.
Both solution sounds quite appealing to me. I would love to hear about the community in regard.
Fly safe,
CMDR Spadino
I think on an unified limpet controller ALWAYS I need to fit one in one of my ship: why a 7 class controller weight 32 tons, yet do not provide any limpet by its own? Ok, they can control a maximum of 4 limpets (not sure why, maybe caused by the power cbsumption and the limits a 7 class slot can provide to its child module) but WHY it can provide ONLY ONE kind of behavior? Limpets are drone: they do what they need do be done. Currently, they are all the same, so there's no point at all in having half a dozen of specialized controllers which control the very same limpet in different ways: we are talking about software here, not hardware.
That's point us toward two different scenarios to have a more polished limpets mechanic:
- software controlled limpets
- specialized limpets
1) software controller limpets
In this scenarios, we have just one kind controller, available in 1, 3, 5 and 7 size slot, as current, whith software subslots (like hangars). Each class can control a limited number of limpets at the same time (same power consumption related hypothesis as introduction). They will store limpets as ammo, which must be restock by synthesis or market. Limpets could be stored also as cargo, of course, but they should need a short amount of time to be prepared.
Here a brief summary:
Class | Ammo | Slots | Max # limpets |
1 | 4 | 2 | 1 |
3 | 8 | 3 | 2 |
5 | 16 | 4 | 3 |
7 | 32 | 5 | 4 |
All controllers should weight the same when empty (2ton) and possibly able to be modified somewhat by engineers...
2) specialized limpet
Thus scenario probably us the less desiderable, yet provide a more realistic approach. It suggest have different kind of limpets, which could be deployed in some different ways, by a unified controller.
So, there could be limpets which can provide "remote action" (like collection, hatch braking, repair, etc...) or "remote acknowledgement" (prospector, recon, research, etc...). The controller still will be able to provide a limited amount of limpets as ammo, but they can be only of a type (silly balancing ��
Summary:
A controller will have an amount of software slots, as previously suggested, but it can host only related softwares (remote "action" or "acknowledging"). It provide limpets as ammo, in the same way, but only of the same kind of softwares. Restock, synthesis and deployment as first scenario.
Both solution sounds quite appealing to me. I would love to hear about the community in regard.
Fly safe,
CMDR Spadino