JadeOfMaar

Careful not to get the wrong idea. This is only an idea post for anyone who can make this and might want to, to run away with. I can't write dlls and I have enough to make already in parts mods. About your suggestion. Animations (while very welcome for immersion) are out of scope. I expected players to only ever have their eyes in the overview UI, and I expect the same immersion being requested to become a source of complaints. Shuttle dynamics are currently too generous (absolutely free adjustment of payload size and numerous engine profiles to allow for use in the early game) which makes for unnecessary programming and modeling work.

Now deliver it south of the Kerbisippi River.

inb4 someone deploys four-armed Buffalo nicknamed "General Grievous"

Galileo's screenshot there is simply JNSQ with EVE City Lights, in daytime.

Hi there. You want something like this. Should work just fine. @PART:HAS[#CrewCapacity[>0]]:AFTER[USILifeSupport] { %MODULE[USI_ModuleResourceWarehouse] {} %RESOURCE[Supplies] { %amount = 50 @amount *= #$/CrewCapacity$ %maxAmount = 50 @maxAmount *= #$/CrewCapacity$ } } You need to have a pass modifier to help the patch to know when exactly to be run (that's the :AFTER[ModName] bit). Your patches can be greatly simplified by targeting a key and using MM math processes on its value or if its value is true: "For every part that has crew capacity > 0, declare Supplies amounts and multiply these by the crew capacity." Finally, the % prefix means "If it exists, edit it. If it doesn't exist, create it. The value within [] there belongs to the name key"

@Strawberry This is a very nice proposal you have here. I didn't really have something to respond with at first, but now I'd like to comment that this post contributed some to the idea in my mod idea post for interplanetary logistics. My realization, at least granted the way my train of thought went, is that employing this circular economy is going to be its own mini-game and nearly require a scene change for the overview due to how much you'll have to see and consider once you've deployed the infrastructure for this at a handful or more of celestial bodies. You can read it here if you're interested:

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.

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: Abstracting away the landed mining base and reducing its part count from 200+ to as close as possible to... just 1. Empowering the orbiting station which is supported by the landed base, without significantly adding to part count. 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.

Yeah, that's still there. Those aren't getting fixed anytime soon, sorry.

@TLCore You might have to reinstall/replace KSP then. If every mod breaks then it's not the mods.

@TLCore Your screenshot over there tells me your test ship contains a Making History engine plate. For a time it was a cause of issues concerning crossfeed and engines failing. I hope you're not using it in your OPT ship. I don't know what to tell you since the Dark Drive contains its fuel so crossfeed and dV problems absolutely shouldn't be possible. Well... if the engine is the root part, don't let it be. I hear KSP doesn't like that.

@TLCore I'm not sure what to tell you. The warpjet engines are setup that if you have Community Resource Pack (and not WBI Classic Stock Resources) then they'll require IntakeAtm. If you have Classic Stock at all then the engines will require "Atmosphere" resource. Delete GameData/ModuleManager.ConfigCache and restart KSP. If this doesn't work, delete this file again and re-download and cleanly reinstall OPT.

@PrinceTides Do you have Community Resource Pack? If the resources aren't installed, you won't see anything other than Ore.

@Probird_23 RR support is here. See v1.41 or newer.

Release 1.41 Added Extras/RationalResourcesELCRP/RR_EL-RF.cfg This firstly changes the default resource link and resource recipe from LFO to Kerosene + LqdOxygen. This secondly adds other (hopefully popular) resource links and recipes. Added support for Quack Pack (planet pack). Added support for Real Exoplanets (planet pack).

There would be only one problem. That's if the system replacer's name is alphabetically later than this one and it flatly unloads all planets rather than specifically naming the stock planets and unloading only them. RR support will come quickly. I'm plenty curious to this pack ...and I just remembered I have Real Exoplanets support to release.

Hi there. No, it's not. It's up to its dev @NermNermNerm to provide compatibility. While I'm getting their attention I will mention that these parts have a "refPower" key in their configs which is used for converter throughput scaling and is used as a multiplier in the patches that apply all their modules. It exists because more parts are planned and redundant patch segments are a thing I try to avoid.

Can't trust stock inventory to remember for you!

Ah. Well no problem, I suppose. Send up adequate return vehicles when you can.

When you need a MOOSE (fitting Wild Blue's naming theme) to go with Buffalo. Lol. The APUS mod has a 3-seat pod you can use for escape/rescue situations.

Hard no, and due to the parts' intentions, don't expect it. You wouldn't expose a rover to reentry. You wouldn't expose a science station to reentry. And you wouldn't use parts for either of those for a spaceplane body. I recommend you make a habit of checking heat tolerances when you look through parts in-game. Hard stats: It looks like many or all of them have 2000K on the outside (same as the stock rocket fuel tanks and engines) but their internal limits are 1000K which is even lower than the stock experiments and most stock cockpits/pods. You don't want to take any chances with that.

https://kerbal-maps-ui-staging.herokuapp.com/ ... just JNSQ. Somewhat surprisingly, this site is still up. Open Settings. In the Settings window: Set your map width (this affects the map window in-game. Unfortunately if you want super high res, be prepapred to deal with that window running ultra far off the screen edge or the mod refuses you because of some upper limit). Export map to disk. Repeat after changing the map to resources or whatever. The current active map will be exported. Find the image in GameData/SCANsat/PluginData/ Changing the active map's color: Click Settings. In the Settings window: Go to Color Management. Go to or stay on the Altimetry tab. Change Palette Style from Fixed to Sequential. Click on any palette that suits you (Some of these gradients are easier or easiest to convert to a grayscale map in photoshop: Just desaturate and invert color. Pick the palettes that are closest to "White to Dark Color"). I believe the ones with pink ticks are the best. Apply palette. Export image. Find the image in GameData/SCANsat/PluginData/ Poodmund's suggestion is likely far easier to use. Sigma88's mods are suppose to be quite minimalistic and should "just work." But I've never used it so no straight answer, sorry.

You know of those. That's awesome. I wanted to give examples but I assumed the other person wouldn't be easily interested in installing a big mod just for that. Some OPT spaceplane parts (when Pathfinder is installed) also gain OmniConverters.

An OmniConverter is a resource converter that, rather then have every conversion chain available at once (which is basic, unrealistic™ and is information overload in the converter part's PAW when you add ISRU mods), has a number of slots (usually just 1) that you can equip a chain into, has a better resource flow multiplier for its size vs stock, does not care about radiator demand, and it can optionally cost you to change the equipped conversion chain later. More text in spoiler.

Those highlight bits are numerical input fields. That is a stock feature that is toggled by the # button next to the pin button at the upper right in the PAW handle. KSP remembers (possibly universally -- one state for all menus) whether you want number vs slider inputs. It may be an advanced tweakable and may be available (or not) per game save, alongside other certain things like the Autostrut options.