Search the Community

SimpleLogistics is a Polyglot! It now speaks twelve languages. (English, Spanish, French, Italian, German, Chinese, Japanese, Korean, Russian, Swedish, Norwegian, and Brazilian Portuguese) Additions and corrections solicited and welcome! SimpleLogistics! (SLOG) An add-on for simple resources sharing between vessels within physics range. By zer0Kerbal, originally by @RealGecko adopted with express permission and brought to you by KerbSimpleCo Preamble by @RealGecko See more YouTube review by Kottabos Gaming Help Wanted Localizations: SimpleLogistics! is a polyglot and speaks 12 major languages! Just in case of some of your kerbals are picky (in this sense)! Installation Directions 1 Dependencies Either 2 Module Manager /L Module Manager Toolbar Controller [Click Through Blocker][ctb] (not required >= v2.0.99.0-prerelease) Kerbal Space Program 3 Recommends Blizzy's Toolbar (tool) Suggests Other addons by zer0Kerbal Biomatic (BIO) Field Training Facility (FTF) Field Training Lab (FTL) Kaboom! (BOOM) another way to not go to space today Keridian Dynamics Vessel Assembly (KDVA) Komplexity (KPLX) MoarKerbals(MOAR) Not So SimpleConstructon! (NSSC) OhScrap! On Demand Fuel Cells (ODFC) Papa Kerballini's Pizza (PIZZA) ScrapYard SimpleConstructon! (SCON!) SimpleLife! (LIFE) Solar Science (SOL) The Gold Standard! (GOLD) Transparent Command Pods) (TCP) Supports GPO (Goo Pumps & Oils') Speed Pump (GPO) On Demand Fuel Cells (ODFC) Blizzy's Toolbar (tool) TweakScale (twk) B9 Part Switch (B9PS) Community Resource Pack (CRP) Conflicts none known Tags addon, resources red box below is a link to forum post on how to get support Be Kind: Lithobrake, not jakebrake! Keep your Module Manager up to date Credits and Special Thanks Legal Mumbo Jumbo (License provenance) How to support this and other great mods by zer0Kerbal Connect with me Track progress: issues here and projects here along with The Short List Release Schedule

From what I gather from interviews (Nate and EJ_SA for example), mature KSP2 gameplay will have a lot of elements similar to Factorio / Satisfactory / Dyson Sphere Program. I have to say Factorio is one of my favorite games so I really appreciate that. I imagine that we will have to build our extraction / processing / transport vehicles and colonies and set up logistics networks using our creations. I have a hunch this delivery routes system will have its own management interface for automation. I think it's really cool because we'll be able to build "cheap" transports with basic materials we obtain and "expensive" exploration spaceships with more exotic elements. So basically we'll have to adapt to each planet and make the best designs we can (rovers, trucks, aeroplanes, helicopters, boats, rocket ferries etc.). There's a lot of reasons to design a new vehicle and constantly iterate. We'll always have something new to build or improve, even without contracts. But what I found a little bit stale about automation games is the lack of interesting end goals. I think it's a really good idea for KSP2 to have exploration as its main purpose. Discovering the planets inside a new star system and their secrets, entering the atmosphere and landing for the first time, doing scientific experiments, exploring interesting anomalies.. I think that this is a good motivation to "grow the factory". How do you feel about the construction and management simulation elements of the future KSP2? Any specific things you would want KSP2 to borrow from the other games I mentioned?

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.

I'm wondering if anyone has had a career game go really south on them. Reason being is I've taken on about a dozen high rep high payout contract to do some pretty tuff stuff like flags on eve etc, however several years have passed and after killing several kerbals i gave up and decided to go science the jool system, then i heavily scienced duna and I'm currently sett up a pretty comprehensive logistics and life support network in the kerbin system. Obviously all of these things have eaten into my millions considerably but I've still got loads left and I'm thinking if I blow the lot before the bailiffs turn up I could probably have a couple good ssto's out around the ksc and then........what's the worst that could happen? Oh and i still have six tourists stuck around from various uncompleted contracts(one of them is a level three!).