Make a universal limpet controller using AFMU style mechanics, and make limpets context sensitive

A universal limpet controller would be lovely, so why not make the module like this:

Grade of module equates to its effective functional range and the amount of limpets it can have at once (A being the best, E being the worst). There is no distinction between conrollers (i.e. hatch breaker, collector etc), they all do everything.

All limpets are synthed, and made 'on the fly' from the controller. They do not take up cargo space.

The size of the module is how much limpet synthesizing it can do (akin to the ammo from AFMUs). This is logical since you need space to store the base components. Refills are like the AFMU and its base material can be synthed (so no more 'I forgot' nonsense). You can also synth longer lasting drones which are hardier.

All limpets are universal and context sensitive. So, if you fire one at a rock it will prospect it, if you fire another at a hatch it will hack it. Its you fire one at something floating its collected, and so on. If its fired and nothing is selected it collects randomly, as now.
 
I personally don't agree the limpets should be synthesized, but I think switching to a universal limpet controller would be great. To save on errors, though, I think the single controller should open it's individual functions to be bound from the Fire Groups panel, to maintain individual bindings.
 
I can imagine the bugs. And resulting confused forum threads. :D
"I was interdicted, shot almost to pieces with dead thrusters. Then the attacker proceeded to fix my hull and fill my fuel tanks. 😵 What just happened?"

But thats quite difficult, since there are very few instances of crossover- you explicitly target something, this object is copied to a property and checked for integrity (so thats two properties) that then dictate what that limpet would do. So Asteroid = prospector, Null = collector (general) Floating = collector (specific), module (is not hatch) repair.

The only possible confusion would be with hatches- you could make it so hatches could only be repaired via drone if integrity was <10% for example (below the threshold for cargo spilling). They take the chance of a malfunctioning hatch over it being hacked, but even then thats fine because a malfunctioning hatch spills the cargo :D
 
But thats quite difficult, since there are very few instances of crossover- you explicitly target something, this object is copied to a property and checked for integrity (so thats two properties) that then dictate what that limpet would do. So Asteroid = prospector, Null = collector (general) Floating = collector (specific), module (is not hatch) repair.

The only possible confusion would be with hatches- you could make it so hatches could only be repaired via drone if integrity was <10% for example (below the threshold for cargo spilling). They take the chance of a malfunctioning hatch over it being hacked, but even then thats fine because a malfunctioning hatch spills the cargo :D
This is FDEV we're talking about. You can rely on the bugs. ;)
 
All limpets are universal and context sensitive. So, if you fire one at a rock it will prospect it, if you fire another at a hatch it will hack it. Its you fire one at something floating its collected, and so on. If its fired and nothing is selected it collects randomly, as now.
I definitely like this idea, though there's a few context issues which would need sorting still, I think:

- fuel, repair, decon and hatchbreaker limpets can all take a ship as a target. Hatchbreaker you could disambiguate by selecting the hatch subtarget, not sure how you'd do the rest [1]
- repair and decon self-target if fired without a target, so how do you pick that over "fire area collector"?
- firing a prospector limpet destroys the oldest prospector if you're over your control limit, all other limpet types won't fire, could be messy if they're on the same controller
- you can't target rocks, so how does it decide between "fire prospector" and "fire area collector"? (Allowing rocks to be targeted would be an interesting solution, I guess)

Still, there's definitely room to compact based on context a bit:
- Prospector
- Collector + Hatch Breaker + Recon + Research (called retrieval)
- Repair + Decon (called repair, decons if needed for less hull strength)
- Fuel
(you could in theory stick Fuel in with Collector+ as it's not ambiguous, but probably shouldn't)


[1] Auto-prioritising fuel if on fumes, then decon if needed, then switching between repair and fuel whichever was at the lower percentage? Feels like it would do the "wrong" thing enough to be a problem.
 
+1
I tried getting the same snowball rolling in 2015 it seems, still wishing for some more intelligent and userfriendly intent and design for the limpet controllers. Annoying that they are physical different modules when all they do is releasing the 'same limpet' all day long.
 
Universal limpet controller, imagine how sensible that is!

Not for Fdev though, they are in the stratosphere of eggheads where simple solutions do not exist.
 
I definitely like this idea, though there's a few context issues which would need sorting still, I think:

  • fuel, repair, decon and hatchbreaker limpets can all take a ship as a target. Hatchbreaker you could disambiguate by selecting the hatch subtarget, not sure how you'd do the rest [1]
  • repair and decon self-target if fired without a target, so how do you pick that over "fire area collector"?
  • firing a prospector limpet destroys the oldest prospector if you're over your control limit, all other limpet types won't fire, could be messy if they're on the same controller
  • you can't target rocks, so how does it decide between "fire prospector" and "fire area collector"? (Allowing rocks to be targeted would be an interesting solution, I guess)

Still, there's definitely room to compact based on context a bit:
  • Prospector
  • Collector + Hatch Breaker + Recon + Research (called retrieval)
  • Repair + Decon (called repair, decons if needed for less hull strength)
  • Fuel
(you could in theory stick Fuel in with Collector+ as it's not ambiguous, but probably shouldn't)


[1] Auto-prioritising fuel if on fumes, then decon if needed, then switching between repair and fuel whichever was at the lower percentage? Feels like it would do the "wrong" thing enough to be a problem.

I forgot there were so many types :D

Its a shame that a lot of things can't be targeted- if they were you'd simplify things greatly. For example selecting the fuel tank transfers fuel, select rocks to prospect. It would also mean then that you could repair whatever is selected.
 

Robert Maynard

Volunteer Moderator
Its a shame that a lot of things can't be targeted- if they were you'd simplify things greatly.
When mining, selecting a target for a collector limpet means that it retrieves one item then self-destructs. Collector limpets need to be able to be launched with no target.
 
When mining, selecting a target for a collector limpet means that it retrieves one item then self-destructs. Collector limpets need to be able to be launched with no target.

Thats why that would be the 'default' behaviour (i.e. no target it pops out and collects whatever is in range). Its sorting through everything and seeing how each is used so there is no confusion- since there are a lot of types the information of the target is the only way to give the limpet context in other uses.
 
I definitely like this idea, though there's a few context issues which would need sorting still, I think:

  • fuel, repair, decon and hatchbreaker limpets can all take a ship as a target. Hatchbreaker you could disambiguate by selecting the hatch subtarget, not sure how you'd do the rest [1]
  • repair and decon self-target if fired without a target, so how do you pick that over "fire area collector"?
  • firing a prospector limpet destroys the oldest prospector if you're over your control limit, all other limpet types won't fire, could be messy if they're on the same controller
  • you can't target rocks, so how does it decide between "fire prospector" and "fire area collector"? (Allowing rocks to be targeted would be an interesting solution, I guess)

Still, there's definitely room to compact based on context a bit:
  • Prospector
  • Collector + Hatch Breaker + Recon + Research (called retrieval)
  • Repair + Decon (called repair, decons if needed for less hull strength)
  • Fuel
(you could in theory stick Fuel in with Collector+ as it's not ambiguous, but probably shouldn't)


[1] Auto-prioritising fuel if on fumes, then decon if needed, then switching between repair and fuel whichever was at the lower percentage? Feels like it would do the "wrong" thing enough to be a problem.
The thing is that we always buy the same 'generic general purpose limpet' at the outfitting though. So what you say makes sense.
Aka, the 'fuelhose and universal-connector' (fuel limpet) or the 'arms/harpoons' (collector / breakers) is something that is fitted in the Limpet Controller as part of the deployment process.

Darn, we just have to make up this lore here today just to make sense of all of this.
I still wish for less modules though, there must be a way to justify reducing it to the few generic types you mentioned.

How about the Limpet itself contains these tools by design:
  • General purpose connector w/Miniature robotic arms (probe to ship connector / repair / collect)
  • Scientific probe and instruments (prospector / research / recon / hacking)
So now two designs. Could it work, lore and design wise?

Two type of Controllers.
Software needs to be updated at dock / fc to change it's purpose.
 
Last edited:
I'm currently trying to summarize all limpet controllers informations in order to see if an universal limpet controller is doable. At the moment I think that a simple module who does everything at once would be difficult without seriously boosting or nerfing some old modules (range and active limpets can be very different), but I wonder if a unique module with additional "program" slot (similar to FLS and planetary vehicle, where you can choose which ship you put in the slots) could work.

Actually, for the five "main" limpet controllers (collector, fuel transfert, repair, prospector and hatch breaker), the price of each module is exactly the same for similar class and rating, mass is the exact same for all but A and E collector, integrity is the exact same for each but hatch breaker who have E/D and A/B switched, power draw is mostly similar but with some weird difference (fuel and repair are the same except for 5B, prospector is the alway the same as either fuel/repair or collector...), engineering is the exact same except for repair who have none, and only simultaneously active limpet number, effective range, and unique effect (duration for collector, hack time for hatch breaker, amount repaired for repair) are unique to the type of limpet.
That's mean we can have an unique module with price, mass, integrity and power draw who can then slot one to several "limpet program" with unique number of limpet active, range and additional properties. I still trying to determine how much program slot each module class/rating should have to retain actual (or different but acceptable) balance, and how to keep the increased stats of range and unique properties along the class/rate with only one program of each type.

Different binding for each function remain a must, tho. One button for multiple limpets action seem dangerous to my eyes.
 

Robert Maynard

Volunteer Moderator
Thats why that would be the 'default' behaviour (i.e. no target it pops out and collects whatever is in range). Its sorting through everything and seeing how each is used so there is no confusion- since there are a lot of types the information of the target is the only way to give the limpet context in other uses.
In which case the best way would be to have a different fire-group binding for each limpet mode.

Not seeing why limpets should no longer require to be stored in a cargo hold though.
 
One way:

Just as we can scan other ships for cargo / bounties, maybe have a systems scan which has a list of modules like a mirror of the right hand panels. Next to it you could have a repair icon for each module, fuel levels etc. If you click the icon it automatically sends a limpet to repair it / refuel.
 
In which case the best way would be to have a different fire-group binding for each limpet mode.

Not seeing why limpets should no longer require to be stored in a cargo hold though.

Scan probes have no mass so its harmonizing with that- and with this idea limpets are made on demand using the ammo that is stored rather than having bought them before.
 

Robert Maynard

Volunteer Moderator
Scan probes have no mass so its harmonizing with that- and with this idea limpets are made on demand using the ammo that is stored.
Scan probes very likely have no mass due to being introduced so late in the game during a significant change in the way that exploration works - very probably due to the fact that there will have been players in deep space, far from any port, who would have been disadvantaged when the change was made.

A bit like the AFMU remaining weightless....
 
Scan probes very likely have no mass due to being introduced so late in the game during a significant change in the way that exploration works - very probably due to the fact that there will have been players in deep space, far from any port, who would have been disadvantaged when the change was made.

A bit like the AFMU remaining weightless....

Indeed, this module would certainly have mass with its size simulating its ammo capacity. So the larger it is, the more it can make. Although I can see the argument from a programming context for a specific controller for a specific effect, at the same time it seems overkill having so many now. To me that would suggest a level of condensation is needed, but if thats practically possible I don't really know.
 

Robert Maynard

Volunteer Moderator
Existing limpet controllers have mass and no ammo - they require hold stored limpets to operate, effectively restricting their use to ships that can carry cargo, a compromise required if one wishes to use limpets.

The "free" limpets part of the proposal seems aimed at removing that compromise, letting ships that would use limpets but not carry any cargo install one module rather than two to be able to use limpets. Which would end up in the situation where a player could use hatchbreakers with no ability, much less intention, to collect the spilled cargo.

Coupled with the "thruster disrupting drones" proposal, it seems that both together would be a way for non-pirates to stop ships with less compromise to their build.
 
Existing limpet controllers have mass and no ammo - they require hold stored limpets to operate, effectively restricting their use to ships that can carry cargo, a compromise required if one wishes to use limpets.

The limpets are not free though- its just the size of module that dictates how many can be made from the available ammunition the module carries. A T-9 could fit a module that houses loads for example. The difference is limpets are no longer discrete.

The "free" limpets part of the proposal seems aimed at removing that compromise, letting ships that would use limpets but not carry any cargo install one module rather than two to be able to use limpets. Which would end up in the situation where a player could use hatchbreakers with no ability, much less intention, to collect the spilled cargo.

Again, the smaller the module size, the less you carry. But it then also opens up more options for ships- is this bad?

Coupled with the "thruster disrupting drones" proposal, it seems that both together would be a way for non-pirates to stop ships with less compromise to their build.

Although this is not the intention and both suggestions are separate, why is this bad? Its also illogical because I can sense the 'misuse' angle here. Why would someone who wants to grief someone use thruster disrupting drones to stop them, when all they want to do is kill you regardless? Why stop you, then kill you, when they'll just swoop in anyway?
 
Back
Top Bottom