Shipyard Focused Logistics

[JadeOfMaar]

Introduction

During a talk on Discord concerning bases and stations, someone stated that they avoided landed bases like the plague (due to the known problems with those) so I happened to have a runaway thought process. These things came to mind quickly, and are arranged in this order:

1. Abstracting away the landed mining base and reducing its part count from 200+ to as close as possible to... just 1.
2. Empowering the orbiting station which is supported by the landed base, without significantly adding to part count.
3. Automating and abstracting the freight vessel between station and landed base.

Elaboration

[1] The Abstracted Miner, Fully Integrated "AMFI" is a part with a very simple shape and is cluster-able to increase harvesting rate. It has slots for drills but the player doesn't physically attach them. When the player equips a virtual drill and chooses its resource, they're actually changing the multiplier for how much of that resource is detected by the resource scanner module. Once landed and active, the one harvester module will produce that much more resource and will produce all of the desired resources at once, saving the player from suffering lag from many ISRU modules running at once.

The AMFI has slots for resource conversion too. Just like with the virtual drills a multiplier is being raised (like in other games, dedicating skill points) to the player's choice of any installed resource converter chains. This provides choices such as between faster LFO production or, say, faster MetalOre --> Metal for Extraplanetary Launchpads.

There's a cost to equipping and balancing the drills and converters, of course. Each of these has an EC demand and maybe, a heat contribution, and these add up. Power and heat can be handwaved entirely away as well, needing only to limit the player from going overboard on equipment. Since this is supposed to be set-and-forget, it shouldn't require the player to ever have to reenter physics range of it once it's landed and activated. However, if the player chooses to use the AMFI as the core of a regular landed base's operations, then the player could connect it to other landed vessels and pump resources out of it normally.

There's an additional and rather small controller part (1 master, many slaves kind of system) or if you have several AMFI parts in the vessel, one can be toggled as the master. This master takes note of the final tally of harvester and converter multipliers across all parts. All resource inputs are added/stacked/bundled together. All resource outputs are added/stacked/bundled together. This leads to absolutely only 2 ISRU modules running within the vessel: a tweaked multi-drill; a tweaked multi-converter. The vessel then becomes an item in a table and can be read and run in the background.

[2] Empowering of the station is facilitated by a large part that is a specialized dock and receives an imaginary vessel, an Abstracted Resource Delivery Ship "ARDS" from an AMFI vessel (so the player needs a dock for each AMFI vessel). When paired it receives the AMFI's data for the ARDS payload and cycle time. Technically, the dock can simply be attached to another landed vessel, rather than an orbiting station, and this would easily enable planetary logistics via suborbital hopping freighters.

[3] The ARDS is a tweakable virtual freight, just like the AMFI is a tweakable virtual mining base, and the ARDS is also represented by a large and heavy part that is attached to an AMFI vessel. ARDS has just one option to it and that is payload mass vs tolerated sea level gravity. If the player chooses more payload mass then naturally the gravity value goes down, the less it can lift from a more massive world. Worlds with atmosphere not allowed, or some penalty will be applied which scales non-linearly with atmosphere pressure. The ARDS cycle, and therefore, when the orbital station receives a lump sum of resources, are dependent on how long it takes to produce the payload mass. It is assumed that the ARDS's propellant is also produced by extra drills and converters.

Multiple ARDS parts could be attached with benefit to an AMFI vessel. This would have the effect of allowing more payload mass in the same ARDS cycle and won't require an extra dock to be added to the station.

Conclusion

In summary, the idea here is for a mod that provides parts and functionality for: Very low part-count mining bases with slots and capacity allocation for AIO harvesters and AIO converters; Orbiting stations that expand themselves and produce more vessels (when all the action is meant to be there) to become more attractive and more rewarding with a significant savings on increase of part count; A form of planetary logsitics and virtual transport ships delivering generous payload masses from one or more of these bases to a target station.

What this plan does not intend to provide are: Full and centralized planetary logistics like in USI MKS/WOLF; Orbital logistics (station to station transfers); Interplanetary logistics; Crew transfers...

Mods that contain features reflected in this mod idea:

• Wild Blue Tools: "OmniConverters:" a resource converter with slots and easy scaling, and every part that is this can detect and receive any converter chain as provided in a new config. No need to MM patch it into every part.
• Wild Blue Tools or Pathfinder: "Prospector:" a resource harvester that produces all resources at once, in accordance to what the resource scanner shows.
• Kerbalism: enables a slot system for resource harvesters and resource converters as does Wild Blue Tools.
• Wild Blue Tools/Snacks: allows for lump sums of one or more resources to be added to a vessel after a set cycle rather than adding them per second like normal. Kerbalism's greenhouse module also has this.
• USI WOLF (comes with MKS): Planetary logistics and on-demand virtual ships for resource delivery to and from any two major vessels.
• Davon supply mod or Kerbal Space Transport System: allows for launches from KSC to an LKO station (or anywhere in Kerbin SOI, depends on the mod) to be recorded and then used for automated, abstracted delivery missions afterward.

 

Edited October 25, 2022 by JadeOfMaar

[Angelo Kerman]

Hm, this is intruiguing. It sounds like a setup and forget, automated system that periodically flings resources to a destination. Pathfinder's existing Pipeline system does a good chunk of this, and the core functionality is implemented in Wild Blue Tools. WBIResourceManifst is used to list what resources to ship and where, WBIManifestScenario handles the logistics, and WBIKisInventoryManifest ships individual KIS inventory items. What Pathfinder's Pipeline does is provide the UI and requirements needed to ship an item through WBT's manifest system.

You'd need an abstracted resource harvester that would look at the resources that can be harvested and then calculate how much per hour/day/6hr cycle (the "catch up" time used by stock converters) the abstracted harvester could produce. This would be akin to the Breaking Ground science system's Power Units produced and Power Units consumed: they're just numbers, and no production cycle is actually being run. The harvester would just tell the scenario object what it can produce, and the automated transport would know how much mass it could transport and how often.

Converter chains are much harder to automatically calculate outputs from inputs and consolidate them, so I'd just go with the abstracted harvester and transporter, and then use standard converters to convert the resources, and use the automated transportation system to periodically receive shipments. To do something like the Breaking Ground science, you'd need a new "converter" that works similarly to the harvester; it doesn't convert resources like the stock converter does, it just specifies how many input resources it consumes and how many output resources it produces in the hour/day/6hr standard converter cycle.

In thinking about the design, you could have something like:

ModuleAbstractConverter: specifies INPUT_RESOURCE and OUTPUT_RESOURCE config nodes (the same ones used for stock converters). The total units consumed/produced is multiplied by the standard production cycle time that all abstract converters and harvesters use.

ModuleAbstractHarvester: derives from ModuleAbstractConverter. It's outputs come from the local ground resources/ocean/air/exosphere instead of OUTPUT_RESOURCE nodes. Input power could come from an abstracted power generator (a part with ModuleAbstractConverter that produces Power Units/Electric Charge).

There are NO actual resources being consumed or produced by the above modules. Storage for the resources is... abstracted.

ModuleAbstractResourceSender: This module would specify how much mass it can send to a receiver. Any output resource from a ModuleAbstractConverter (or its derivatives) can be sent by the sender. It works with a scenario module to set up the resource chain. A UI lets you specify the vessel that will receive the resources. Derivatives of this class can impose restrictions such as resource requirements- think of the requirements set up by the Pipeline from Pathfinder.

ModuleAbstractResourceReceiver: This module receives the resources sent by a sender. This is the only module that produces traditional resources (LiquidFuel, etc) for the vessel to consume. The amount it produces depend on how long it's been since you last visited the vessel. This module could in fact be derived from the stock BaseConverter; it just pulls its outputs from the scenario module instead of from another source.

Anyway, these are just my thoughts. Unfortunately, I don't have enough time between now and the end of the year to implement this; Buffalo 2 is taking all my free modding time and way behind schedule. But maybe the above can be a starting point for someone to work with...