Search the Community

A proposal for what hopes to be a relatively simple system for resource sharing between planets and moons at a given star. Derived from my Shipyard Logistics idea and aimed at interplanetary by request. It is practically a complete mini-game, possibly bringing EVE Online to KSP. Miners The beginning of this system is deployable, upgradable, single-part mining infrastructure. Land it, splash it, park it in the optimal altitude for an exosphere resource and turn it on. Per the names and values given by the resource scanner module, the player can choose which resources to harvest, and invest upgrade points to raise the output multiplier of a desired resource. Resources harvested are not immediately available to be pumped into other vessels. They are first converted to “resource credits” (MKS users know) so they do not have mass as to encourage the tank mass/joint strength kraken, and they are all collected by the depot. Purchase upgrade points by spending funds and a construction mod resource. When points are used, the miner part will increase in height and width to reflect increased mining capacity. Power and heat systems are not relevant at all. These are assumed to be perfectly settled before the miner is packaged, and all components are assumed to be standardized and perfectly lego-able for ease of upgrading in-flight. Features and upgrades Part can produce each resource found via resource scanner module but requires Equipment Points invested into that resource. Each point represents a harvester slot and raises the resource multiplier by 1. (Multiplier starts at 0). Part can be upgraded to have more total points invested in it (effectively: raising the drill slot limit). Equipment Points would be produced by a depot and can only be taken from the controlling depot. The part may increase in size when upgraded. ID info Each miner vessel identifies itself, its host body, situation, resource production rates, and it appears in a list under its controlling depot, and in the category of Production. Depots Next comes an upgradable single-part transport hub infrastructure. This is by default much larger than the miner as it represents the parent vessel for all abstracted resource freights and a branch office of a bank. A landed depot encapsulates all landed miners on a given body and an orbital depot encapsulates all miners orbiting a given body (excluding any moons). The depot has the capacity to produce upgradable abstracted shuttles for resource transfers, and by extension, has resource converter capacity and tankage for converter outputs. Every depot (per situation: Orbiting or Landed) has shared access to a single cache of all resources produced by all miners in the same situation. Player vessels that require resources can dock with these and withdraw from or deposit to the cache. The depot ideally should never experience a dynamic mass situation. The UI for this exchange will resemble any fuel pump mod, showing transfer speed options, allowing to exchange any combination of resources, and respecting locked tanks and crossfeed. Features and upgrades Provides infinite tankage for resources collected by miners under its control. Resources are not physically stored but stored as massless credits. They are converted between these forms as needed when a real, player-built ship docks to it or is at least within 100m of it. Provides ISRU within the resource credit system such as to produce Equipment Points or construction mod resources. Provides a system for the holding, application and upgrade of virtual shuttles for resource deliveries. Part can be upgraded to hold any number of shuttles. Note that if shuttles arrive and the depot has no available bays for them, the shuttles will wait in a coorbital situation and their payload will be inaccessible. Part can be upgraded to have greater throughput rate for a given ISRU chain and to hold more Equipment Points to give to miners under its control. The part may increase in size when upgraded. ID info Each depot vessel identifies itself, its host body, its situation, resources held, resource conversion chains and if they are active, shuttle bay count, and each shuttle bay with the relevant info of a shuttle, if occupied, and the depot appears in the categories of Production and Storage. Shuttles These imaginary vessels come in a few types, will cost some amount of construction resource and propellant resource to build, and must be produced on demand. Logistics (surface-to-orbit and interplanetary) will not properly work until they exist. Shuttles have launch and delivery cycles depending on the sum of: Construction time (unless it already exists. This can be affected by Production factor – how fast the depot can perform construction); Ascent time if surface-to-orbit “SO” (depending on ascent dV and TWR, if ascent dV can be easily computed, and depends on the engine type); Transfer time if interplanetary “IP” (depends on automated transfer window planner functions and the engine type). SO shuttles can be made to loop and will automatically launch repeatedly, either infinitely or a requested number of times with a countdown of the total time and an optional alarm at the end. If an IP shuttle needs to go from a moon of planet A to a moon of planet B, only consider the transfer time between the parent planets and not planet-to-moon. Engine profiles Profiles allow for the shuttles to benefit from progression and to be optimized and dedicated to specific use cases. If it isn’t too much trouble to implement, the system should be able to produce and simulate a virtual ship with the desired payload mass, propellant type and mass, engine type and size, resultant TWR and dV, then compare this dV with the dV required for an interplanetary transfer, and finally offer a slider control for how much dV to spend to optionally expedite a transfer (this slider defaulted to the lowest setting which equals just enough of a burn to get a transfer done), and get the transit time and its changes dependent on the dV fraction to be used. If it is too much trouble to implement, the system should only need to be able to get transfer windows and transfer times, then provide profiles (which unlock with respect to certain tech nodes) which require a baseline amount of propellant per unit mass of payload and provide the option to expedite transfers by increasing the propellant required per unit mass of payload. SO shuttles have these example profiles: Name: Fuel mix; Vac Isp; Is atmo-capable?; Engine Mass; Engine TWR Chemical: LFO; 340s; Yes; 4.2t; 30 Nuclear I: LF; 800s; No; 3t; 1 Nuclear II: LF; 970s; Yes; 3t; 10 IP shuttles have these example profiles: Name: Fuel mix; Vac Isp; Engine Mass; Engine TWR Nuclear I: LF; 800s; 3t; 1 Nuclear II: LF; 970s; 3t; 10 Fusion A: FusionPellets; 1,020,000s; ?t; ? Fusion B: D+He3; 35,372s; ?t; ? BCAM: H2 + AM; ???s; ?t; ? Features and upgrades Shuttle has tweakable payload mass limit, propellant mass limit, engine type (during construction) and resources can be added or subtracted by text input/search and slider control or number input. Shuttle dV expenditure can be tweaked between Baseline and High/Max Energy to save dV or save transfer time. Shuttle can be destroyed to recover some fraction of construction resources and recover all propellant resources to build a different shuttle or convert to physical resources. ID info Each shuttle identifies itself by name, the source depot (if moving), destination depot (if moving), if it’s looping (STO only), current depot (if idle/parked), time launched, transfer time elapsed, transfer time remaining, payload resources, and appears in the categories of Storage and Transport. Conclusion Miners. These are large, upgradable, single-part vessels placed where desired on the surface of a celestial body, under the sea thereof, or in the peak altitude of an exospheric resource. Resource production is decided by the results of a surface scanner module and the investment of “upgrade points” into enabling choice resources and raising their multipliers. Resources do not physically occur here and cannot be accessed. Depots. These are larger, upgradable, single-part vessels placed on a body’s surface or in orbit, and they possess the cache for the resources produced by all miners in the same situation as itself. Resources collected here are in the form of massless credits, and can be exchanged between credit form and massive form to be used by resource converters as usual. They are also the hubs and assemblers of virtual shipping vessels which carry resources surface-to-orbit, the opposite, and even interplanetary. Shuttles. These upgradable, imaginary vessels embody resource transfers and can be created on demand, scheduled, looped and tracked. Most of the challenge of implementing this logistics system is in the interplanetary shuttles as dV expenditure, transfer times, their many associated factors need to be properly rigged and calculated. Spreadsheet-gaming interface. The player needs to be able to, at a glance, see what all the miners at a given body and in a given situation are producing; their controlling depot; that depot’s cache and activities, shuttle capacity; shuttle activities/statuses/schedules and more.