[Concept] Structure QoL and improvements via DE computers/droids.

[Introduction]
As someone who runs harvesters, one of the most annoying aspects to me is the constant checking on external tools if a resource is depleted and having to set reminders on when harvesters are full.
With a the recent patches we already decoupled the need for external tools a bit by introducing the survey/report resource minigame with a way to check resources in the game which has been a nice QoL improvement.
I've been thinking about a way to provide some additional QoL to structures while also coupling them with some sort of game systems/progression.
The concept is a pretty long read and its not set in stone - its more like a suggestion/idea i'd like to share for discussion/inspiration for a final solution.
Most of this is done by re-utilizing existing droid mechanics in the game.
In addition a structure maintenance module for droids in the game which is pretty lackluster and does not really provide a lot of useful utility so it is barely being used.
The concept is based on expanding on this.
I've tried to seperate it into sections i hope it is somewhat decently readable.
Also please notice that wherever i specify values, these are just general examples or suggestions, i don't wish for this to turn into a balancing discussion about stats.

[General Concept]
In this concept we borrow core functionality from flight computers and normal droids to create a new type called "Structure Management Computer"
Essentially this follows flight computers design by being generated into your datapad - but not being able to be summoned into the game world.
However instead of utilizing flight computers memory to load programs, it utilizes normal droids module/module cluster system.
These type of "computers/droids" can be crafted by Droid Engineers and can be installed onto structures. (Just like the current maintenance droids via radial -> register droid)
Once a structure maintenance computer is installed onto a structure, it automatically starts working and utilizes functions depending on which chips were installed on it during crafting.

[Specifics: Structure Maintenance Computer]

• Crafted by droid engineers
• Require sub-component from architect (e.g. new item "structure computer mounting interface") - This is to make the crafting process more interesting and also give architects a new interaction with other crafters.
• Does not have battery %
• Instead once installed on a structure it increases the maintenance & power consumption rate of the building it is installed on
  • (i suggest something between 5-10% to not be ridiculous the modification rate could be based the sub-component crafted by architects)
• Comes in different tiers -
• The higher the tier, the more module slots/module cluster slots it has.
• One structure per computer - You will need one computer for each structure. (Economical reasons)
• When a structure is removed or the computer is uninstalled from the structure, it can be reinstalled onto other structures.
• Modules are crafted into the final computer and can not be removed/replaced unless a new computer is created. (Economical reasons)
• Can be installed on all non-city structures: Houses, Factories, Harvesters

[Specifics: Structure Computer Mounting Interface]

• Crafted by architects
• Have two stats: Structure Maintenance Modifier, Structure Power Consumption Modifier
• Stats can be experimented on.
• Should be simple schematic without sub-components to not make the whole crafting chain too complex.

[Specifics: Modules]

• Crafted by droid engineer
• Work like normal existing DE modules.
• Provide specific functions that the computer automatically applies to the structure it is installed on.
• New module category: Structure - I would prefer to have them all go into general category - But i assume this would interfere with existing modules/droids that also have "general"-slots because you could cross mount modules with droids/computers not intended for it.
• ( Alternative: Instead of using existing module items, create its own item subcomponent-category)
• Has QoL modules and modules affecting structure efficiency
• QoL provide some QoL effect without downside (e.g. Send Mail when Hopper full)
• Efficiency modules always have a downside ("e.g. increased resource gain for increased power consumption)
• Option for high-end modules with schematics obtained from other content.

I also came up with some ideas for different modules.
However implementation wise - i am not sure if it would be smarter to make different modules for the structure types "general", "harvester, "factory" or have one module with internal IF/ELSE logic. (from user perspective, one for all is preferred due to simplicity)



[QoL Modules]

• Structure Maintenance Module
  • This one is easy.
  • Works like the current structure maintenance module.
  • Pay structure maintenance from your characters bank account

• Structure Name Registration Module
  • User can enter a name which the computer will automatically apply to the structure it is installed on. (Main use-case is for harvesters/structures where folks tend to rename their harvesters via macros at the current time)

• Structure Power Module
  • Only affects structures with power consumption.
  • This is tricky because it depends on implementation.
  • Also we do want to have it in a way where it does not make the "Make harvester self-powered"-kit obsolete.
  • Essentially there's two ways to implement this:
    • Variant A:
      • Gets a single inventory slot to deploy a power resource in
      • draws from that resource until its depleted
      • resources here cant be withdrawn like in current power using structures.
      • (resource amount can be capped - can experimentation based)
    • Variant B:
      • Deploy certain amount of power into a "power"-variable like its currently on power using structures
      • essentially same concept as A. but without the resource item slot
      • allows for redeploying power from mixed resources -
      • power cant be withdrawn like in current structures, however the computer can be uninstalled
      • max amount can be implemented (e.g. 10000(current)/125000(max))
      • max amount can be experimentation based

• Structure Forecast Module
  • When installed on harvester: Displays the remaining time (or timestamp) until the hopper of harvester is full
  • When installed on harvester: Displays the remaining time (or timestamp) until the factory run is completed
  • (Preferably IF/ELSE logic for structure type - alternatively separation into separate modules)

• Structure Info Module
  • Allows for remote /structureStatus on the harvester it is installed on.

• Structure Location Module
  • Provides a way to display location or retrieve waypoint of the structure

• Structure Notification Module
  • Automatically sends mail notifications to the structure owner on certain conditions like:
  • On all installed structures:
    • Out of maintenance credits (alternatively send notification at as example 24h remaining)
  • On installed harvesters:
    • Hopper is full (alternatively send notification at as example 10% capacity remaining)
    • Power depleted (alternatively send notification at as example 24h remaining)
    • Resource depleted
  • On installed factories:
    • Power depleted (alternatively send notification at as example 24h remaining)
  • (Preferably IF/ELSE logic for structure type - alternatively separation into separate modules)

[Non-QoL Modules]

• Harvester Efficiency Module
  • Comes in Basic(T1)/Standard(T2)/Advanced(T3) tier
  • Increases resource gain by x% for y% increased power draw
  • (varies by tier - suggestion: T1: 5%/10%, T2: 8%/15%, T3: 10%/20%)

• Factory Efficiency Module
  • Comes in Basic(T1)/Standard(T2)/Advanced(T3) tier
  • Increases factory speed by x% for y% increased power draw
  • (varies by tier - suggestion: T1: 5%/10%, T2: 8%/15%, T3: 10%/20%)

[Illegal Modules]

• High end modules
• Expensive to craft
• Drastically increases power consumption
• Only on highest tier of computers.
• Only one illegal module per computer
• Obtained from other content as schematics

• Illegal Harvester Efficiency Module
  • Craftable via schematic obtained very rarely from smuggler high level contraband missions (schematic uses: 1)
  • Requires T3 harvester efficiency module as component
  • Should generally be expensive to craft
  • Increases resource gain by 50% for y% increased power draw (suggestion: y% = should be in the ballpark of somewhere between 100%-400%)
  • Power draw can be experimentation based.
  • Idea is to have this be a high end module which is a significant upgrade to individual harvesters. Should be expensive - Power draw should be a significant downside so it is used selectively instead of constantly applied to all harvesters)

• Illegal Factory Efficiency Module
  • Craftable via schematic obtained very rarely from smuggler high level contraband missions (schematic uses: 1)
  • Requires T3 factory efficiency module as component
  • Should generally be expensive to craft
  • Increases factory speed by 50-x% for y% increased power draw (suggestion: y% = should be in the ballpark of somewhere between 100%-400% - x% can be 50% but could also be higher, the economical impact of this is less significant compared to harvesters. Could be experimentation based)
  • Power draw can be experimentation based.
  • Idea is to have this be a high end module which is a significant upgrade to individual factories. Should be expensive - Power draw should be a significant downside so it is used selectively for short burst factory runs)

• Illegal Factory Backup Schematic Module
  • Craftable via schematic obtained very rarely from smuggler high level contraband missions (schematic uses: 1)
  • Allows the user to upload one backup manufacturing schematic to the computer which is automatically applied when the current schematic in the current factory run has reached its end.
  • Automatically starts factory run when backup schematic is applied and resources are available.
  • Effectively allows double-runs on factories with the same item or even different items if the resources are provided ahead without user interaction
  • Increases power draw by 50%

Generally the whole module system is expandable just like the droid engineers system in general since its based on it.
Other modules are thinkable bound to class specific quests or different content (e.g. module that reduces merchant maint rate etc)



[Economical considerations]

• "One structure per computer": This 1:1 relation might sound inconvenient at first but economically it makes sense
  • You want people to have different computers for different structure to create some demand for these.
  • A big downside of flight computers as example is that they are essentially super cheap to craft and chips are free basically. This creates a situation where you buy it once and after that players never have to buy any more of them which limits the demand for these things drastically.
• "Modules are crafted into the final computer": Unlike flight computers models are fixed once crafted. This is also to create more economical demand and provide an additional revenue stream for DE's.
• Sub-Components by architects: This can provide architects with a "sub-component" type of revenue stream.
• Efficiency modules: These are up for debate because they obviously have economical impact. However i do not think it is that much of a problem if balanced out cost of obtaining/maintaining them.

[Legacy structure maintenance droids and migration]

• Old structure maintenance modules become deprecated and can be sold for a decent price to the junk vendor.
• The schematics for old structure maintenance modules get disabled.
• Existing manufacturing schematics for old structure maintenance modules become deprecated/get removed
• All droids currently registered to structures become unregistered.
• Current droids having a structure maintenance module installed have that module removed. Players with such droids are given a simple structure maintenance computer with installed "Structure Maintenance Module" in return.
• The radial menu entry on structures called "Register maintenance droid" gets renamed to "Install maintenance computer"