Unified Limpet Controller - with bootable 'Firmware'

[John Stoutbeard]

Unified Limpet Controller
Replace the implemented "Limpet controllers" in favor of a unified version.
The new "Limpet Controller", where you can buy and install firmware packages, such as:
- Prospector Software
- Cargo Transfer
- Fuel Transfer
- Collector
Each software package comes with a pricetag roughly in the range of 50.000 to 100.000(?) depending on how advanced the program is.
The method is flexible enough to allow for new pieces of firmware to be installed on a existing controller in a ship.
Hence the owner doesn't need to redo his ship slot layout when a new controller is out there on the market. Just get the software.

Multislot behavior:
The advanced modules have enough storage to allow for several firmwares to be stored. However, only 1 program may be run on one controller at any given time.
To change software in a multislot controller, one needs to active which program to run through the Function menu on the right MFD. Only one program can be active at any given time. For example, booting from 'collector' to 'fuel transfer' program may take 5-10 seconds.

---
New unified Controller in 2 flavors - a choice of:
a) a Utility-slot variant, Max 1 limpet programmable.
b) an internal-slot, from 1-3 limpets in operation at any given time.

---
Utility-slot version:
Small Controller (E-D grade) price ~50k CR to 100k CR.
- 1 firmware slot.
- Powerusage roughly equally to one of todays limpet controllers.

Medium (C-B grade) est pricerange 500k CR to 1Mill CR
- 2 firmware slots
- Powerusage roughly equally 2-3 limpet controllers.

Premium A grade, est pricerange ~2.5Mill CR to 15Mill CR
- 3 firmware slots
- Powerusage roughly equally 3 limpet controllers.

---
Internal Module variant:
A Grade: 3 limpets in operation, 3 software slots. (max 1 program running at any given time). High powerusage / weight.
B-C Grade: 2 limpets, 2 software slots (max 1 program running at any given time). Med-High powerusage / weight.
D-E Grade: 1 limpet, 1 software slot (max 1 program running at any given time). Low-med powerusage / weight.

---
Clarification:
Ship owners may have 2 or more controllers, with 2 programs on both, a total of 4 programs.
Only 1 program per controller is active, but with 2 controllers, you then have 2 active programs running.
They then need a way to select which program to run on both controllers. Perhaps it's better to use the 'Module' screen to select the program on the controller.
Controller must be listed (inc priority, powerusage etc), with a child-list of programs (where only one can be enabled at any given time).

 

[John Stoutbeard]

At a later stage it may be possible to even enhance further by
- Adding a 'Software' tab on the right MFD, before/after Functions.
- Add a 'Computer' module. Unified.
Allow ship computers using 'unified modules' similar to the Unified Limpet Controll.
May run new pieces of software such as 'docking computer', 'survey scanners with advanced features' etc. These 'computers' or modules are separate modules with limited storage space and varying.

Pros:
a) With a 'software' feature in place in the ship it will be easier for the ship owners to upgrade the ship without having to get into a dry-dock.
b) Savegames / persistent state of the ship may no longer be affected by 'static modules' such a "docking computer" which is a specific module, instead software will become a separate entity of it's own and not affect the ship slot-layout.
c) Easy to introduce new features for a ship, since it should be available for a single module only (the computer), and not have to introduce multiple variants of a specific module (with grade, power-usage, weigh) and all the other static measurements required.
d) less cluttering when retro/outfitting a ship. The module-shop lists are cluttered enough already.

Cons:
Somewhat a new direction & design requirements. ~ more work.

 

[treguard]

This would be great. It's annoying that I have to use separate slots for each different type of limpet. I'd welcome this

 

[John Stoutbeard]

A new program that may be introduced:
- Subsystem Repair Firmware for Limpets.
Allows a ship in space to remotly service broken subsystem for a remote ship.
May allow a new subprofession for the Fuel / Service Rats.

 

[DocLooshkin]

+1, if only to reduce the obscene number of limpet controllers in the module list. With the caveat that I don't actually use the things myself, I would venture to suggest that the game doesn't appear to obviously benefit from players having to buy either pre-programmed limpets or dedicated control modules. Would being able to select their function at will in the game, without special cost, unbalance the game? What problems would it create?

 

[Winterwalker]

A good idea this, imo.

 

[John Stoutbeard]

+1, if only to reduce the obscene number of limpet controllers in the module list. With the caveat that I don't actually use the things myself, I would venture to suggest that the game doesn't appear to obviously benefit from players having to buy either pre-programmed limpets or dedicated control modules. Would being able to select their function at will in the game, without special cost, unbalance the game? What problems would it create?

I was thinking that the controller needs to load the software from storage, and emulate a 'reboot' of said controller. This to introduce a delay, so switching software instantly is not possible, instead it may take 30-60 seconds to load the program.
You may own several pieces of software - but may only have 1-4 loaded depending on the number of unified controllers and software slots you have.

You may even own the software, but remove the controller - and at a later stage buy the controller, and loading it up with the software you own.
---
The same would go for the 'computer' suggested in Post#2. Similar behaviour, you may own several piecies of software, you may reprogram it in flight, however a delay must be introduced so no instant switch is possible.

Hence, after a long exploration trip, you may return and load up the docking computer. You would have to come to a stop in subspace to do this.

Would this be sufficient you think?

 

[Cmdr. Numa]

While I welcome the basic idea, keep in mind, that there are at least two professions who would need two programs active, or else it would become a hassle. Miners need prospector limpets, pirates need hatch breaker limpets, and both need collector limpets, both in rapid succession. So limiting to one firmware active is impractical.

 

[John Stoutbeard]

While I welcome the basic idea, keep in mind, that there are at least two professions who would need two programs active, or else it would become a hassle. Miners need prospector limpets, pirates need hatch breaker limpets, and both need collector limpets, both in rapid succession. So limiting to one firmware active is impractical.

Please read post one. It allows for multiple controllers, as well as multiple programs per controller.
As well as choosing to use a utility slot vs a internal module slot.
Please let me know it is unclear - sorry, english isn't my native language.

 

[Cmdr. Numa]

Please read post one. It allows for multiple controllers, as well as multiple programs per controller.
As well as choosing to use a utility slot vs a internal module slot.
Please let me know it is unclear - sorry, english isn't my native language.

I did. It clearly states that only 1 firmware should be active, and switching should take time. I pointed out why IMO that isn't a good idea.

 

[John Stoutbeard]

I did. It clearly states that only 1 firmware should be active, and switching should take time. I pointed out why IMO that isn't a good idea.

Ah, agree. Perhaps my explanation is a bit vague. This is where I tried to say that you may have 2 controllers, both run 1 program each.
You may have 3 controllers for that sake:

Ship owners may have 2 controllers, with 2 programs on both, a total of 4 programs.
They then need a way to select which program to run on both controllers.

Updated the post to try to make it a bit more clear. Thanks.

 

[DocLooshkin]

[...] Would this be sufficient you think?

I have no idea - I'm hoping you can tell me! I don't understand why the current system - and your proposed new system - need to have all these caveats and limitations. I assume it's like this for a reason, but I don't know what it is. What purpose do the limits serve? Wouldn't it be better to have just a single, freely-flexible multifunctional tool instead?

 

[John Stoutbeard]

I have no idea - I'm hoping you can tell me! I don't understand why the current system - and your proposed new system - need to have all these caveats and limitations. I assume it's like this for a reason, but I don't know what it is. What purpose do the limits serve? Wouldn't it be better to have just a single, freely-flexible multifunctional tool instead?

I would assume you need some sort of balance for the modules. Modules cannot have 0 cost, 0 powerusage and run 10 different functions at the same time. That would defeat the purpose of choosing a setup which works for your ship while having to make some compromises.
All current ship modules have some sort of negative effect, like A grade are great, but they cost more both in CR and powerusage.

Hence the new proposed modules would need some sort of balancing as well, while improving the issues we've identified.
Input regarding positive bonuses vs negative consequences (balancing) - or for that matter, other ideas are welcome.