JadeOfMaar

Years ago, I read somewhere that while it's relatively very easy to make the hardware (and its firmware) that provide for multi-threading and hyperthreading, it's very hard to produce the software (mainly games) to truly take advantage of the same. Unless I'm mistaken, my understanding is that you can create all the parallel processing you want, but the end of these processes all come back to a singular one, the master thread that relies on all their outputs, and the idea of multi-threading is self-defeating to whatever degree depending on what the game is trying to do. Or it's (still) beyond the game dev's imagination to write, or the popular game engines/program languages to execute truly multi-threaded code. It may still not be common knowledge yet but Squad used KSP to learn to use the Unity engine, so a lot of KSP's faults are due to literally "beginner mistakes and the band-aids for the boo-boos" ...and also that the Unity engine and its ecosystem were still very young back then so there would be a certain lack of docs, features and assets to borrow from. KSP2 will handle large part count crafts much better: Intercept Games promised it, even naming a feature "Stateful Physics." Intercept Games is an experienced game studio before KSP2 existed, unlike Squad who got experience because they made KSP. The Unity engine is 10+ years older than when KSP1 first started. Increased use of procedural parts (of more kinds than just wings) means less parts to do math on for a given ship, especially on huge ships (interstellar transports or not).

Molten Salt Reactor One of 2 major fission reactor types which will be provided. Unlike nuclear reactor parts in other mods, these and their brothers, the Pebble Beds, run on a pump-able fuel resource and not the usual non-transferable fuel rod type resource. Sizes: 3.75m, 2.5m, 1.25m, 0.625m

Weird! I just installed MOLE (in a dedicated troubleshooting install) and I don't see this problem. (Pathfinder and Buffalo 1 are also there) Send your KSP.log (let it only generate as far as letting KSP reach the main menu screen), GameData/ModuleManager.ConfigCache, and your KSP/Logs/ModuleManager/ (all in one zip file please).

"Kerolox" is supposed to be LFO. Classic Stock doesn't care about RealFuels.

Sometime ago I asked Blowfish about ModuleLiftSurface (just to have static wing sizes in one part) and they gave me a pretty solid no for that so I expect nothing will be provided for any use cases with ModuleControlSurface. Feel free to dig through my mods: Rational Resources and OPT Reconfig. In there you'll see B9PS configs for: Fuel switching on engines, RCS thrusters and fuel cells; Thrust & Isp switching on engines, with tooltips that show accurate and different values per subtype; Upgradeable heatshield properties; Hopefully these are useful to your plans.

@Bombaatu Thanks for noticing. The associated tank definitions don't have CommunityResourcePack in their NEEDS so they're created by KSP when they shouldn't be (created when CRP is not present). I've posted the fix onto GitHub. The commit and diff.

"recommended?" Wild Blue Industries doesn't manufacture weapons.... Drax Aerospace might... It's a supplier for the villains.

I'm surprised that actually broken config ever worked. Use this and have a nice day. // Intakes @PART:HAS[@MODULE[ModuleResourceIntake]] { @MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeA??]],* { %disableUnderwater = true } } // Engines @PART:HAS[@MODULE[ModuleEngines*]] { @MODULE[ModuleEngines*]:HAS[@PROPELLANT[IntakeA??]],* { %disableUnderwater = true } } Note the resource panel shows IntakeAir (hidden in the stock window) and IntakeAtm (in case of mods' jet engines that don't need Oxygen in the air).

This thread was never there. This is the Addons Discussion board. You're welcome. I didn't even think of this but it works too.

It's... a good opportunity to learn making robotics.

I wouldn't know but I raised the suggestion to have this Shuttle II be larger (approximately 5m for the body, not the original 3.75m) so it stands in the same size class as Tundra Exploration's Starship and Angel-125's Mk33. As a spaceplane junkie, this makes this mod more interesting to -me- because of the obvious reason that stock Mk3, SOCK and other cargo spaceplane mods will hold 2.5m cargo at best. "Just use those then" and "It might appeal more to upscale players and RSS players if it's bigger" were my thoughts...and this size allows all the engines to be 1.25m and 0.625m, not forcing them to be 0.9375m and 0.4??m with size adapter variants. Actually, one engine is shown twice: The STME is dual mode: Short-nozzle SL optimized; Long-nozzle Vac optimized. The other is the STBE. No extra features there. The designs have changed since, and are still bound to change.

Have you been underwater on Kerbin with Parallax 2? Kerbin has become 4546b. Now you have to change Mun's orbit to geostationery and make Minmus closer and have a polar orbit.

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.