JadeOfMaar

The OP is specifically asking for in-atmosphere colonies. Blimps; Sky cities.

Your answer might be in here: Otherwise you might be looking at kOS scripting.

My concern is not about leaking (I know the balloon itself might have exit holes in the top depending on how it's meant to operate) but embrittlement: the airfoil becoming as wet tissue paper after prolonged exposure ot hot Hydrogen.

AirPark for KSP2? Likely.

Not so easily. A gas giant is full of the lightest possible gas, Hydrogen. And why do we keep Hydrogen in liquid form? Partially because it will phase through and compromise its container if left to warm up. Personally, I'm confident that this is in the realm of sci-fantasy and wouldn't pass for a possible stock feature (but you can bet that somebody will make a mod that allows this if they're interested enough). The obvious reason being: any sufficiently large facility will be quite massive and will require an active engine system to hold it up. This engine must be capable of an impossible (unrealistic) combination of TWR (to hold everything up) and Isp (to be fuel efficient and not force the facility to largely be a harvester). Remember, our favorite fusion fuel is not normal Hydrogen and normal Helium, but Deuterium and Helium-3, and we know those are super rare. And we don't talk about thermal control setup for a rocket-powered sky city. And that the engine heat will invite even worse "compromise" problems to the engine.

@Astra Infinitum The usage restriction text is because my flares are designed loosely based on the star's color and are intended to be used with planet packs that have many stars and diverse star classes. Mine are not like other sunflares that don't care what the star's classification is and may be freely applied to any star (like the Kabrams flares). Mine are such that you can tell what class of star it is once you see it (same deal as Galaxies Unbound with its flares). "Default G class flare? That's a yellow dwarf G class star, a Sun-like star" ... "Bright orange flare? K class dwarf (between yellow G and red M class dwarf)." ... "Blue flare?! ...Ooooh, that's one of the blue giant stars! O, B or A class." This is probably a clear explanation of something I expect people to do but I don't want them to do as it violates the Non-Derivatives license. (It also probably specified recolored textures rather than configs.) Since you have to ask, I figure you didn't know this, which is why that text is there. Also... amateur recolors (just splashing it with tint, as far as the less tech savvy will be capable of) are going to look like garbage. Unlike Flare Replacer, my flares are not designed to be tinted. You're free to make your personal edits. Thought police and cloud police don't exist (yet) but please don't share, as, well, my intents and my license choice are opposed to it.

I see it. The tank type name is defined with the name FBSM. Sorry. I thought I fully applied that. It was, for a short while, originally named FBCM. @linuxgurugamer PR sent with fix.

Umm @zer0Kerbal I don't believe a mod like this needed adoption. Like this person said above... It's a far better idea, concerning such a basic mod as this, to install the lightest fuel switch plugin out there and avoid adding parts altogether. The idea behind these two mods is the exact same: "I don't want parts mods or complexity at all. I just want only LF here and only OX there."

Hi. "Time to run: 1:00" this is the only line I see, with this exact value, for all stock experiments, with your two mods linked above. I got the impression that they have a combined function.

Well, it's on SpaceDock so you can definitely try it and share your findings with the class. https://spacedock.info/mod/34/Kerbal Tubes

The release.

Have you then installed and uninstalled Impulse Party to confirm that my mod is causing the problem? The only possible source of problems would be IMPP_WarpCoilsUpgrades.cfg which affects Angel's parts. And that config is in my mod's Extra's folder. It shouldn't be in your GameData by default.

Like I said earlier. If you can pack the energy (moreover, into a tiny volume) to land any capable sci-fi ship, you are already carrying doomsday levels of energy. It's only a matter of if and how terrorists can make it explode. In any case, sci-fi ships generally have security systems such that no one can just break in and cause a meltdown. I feel like half the time you're asking about SSTO propulsion, though. You should already have been informed on, and settled on something ages ago. Carrying around or riding in something that will cause mass destruction if it breaks in the right way is a very normal issue for sci-fi things. The threat thereof, generally only happens if you have people who can and deliberately want to cause that kind of destruction. It's a "Keep calm and live with it" kind of thing because the thing holding that kind of energy is usually built such that it's not going to be an issue 99% of the time. On the other hand, I haven't watched enough of StarGate SG-1 or Babylon 5 but I know StarGate has "ZPM" things that are basically near-infinite energy stored in a battery in the form of a crystal that you hold like a key or wear like a necklace. I'm sure those don't explode if you destroy them. So in comes another very big issue I'd like to point out. Where do you draw the line between hard sci-fi and soft (sci-fantasy)? You need to have some standards for what physics and technology apply in your ideal sci-fi universe, then you won't have to post a bunch of threads asking "How can I make illogical condition #2498 work?" and you'd be able to decide for yourself "Ehhh. I don't like how these things in this sci-fi work, because actual reason A, B and E." We look forward to questions like "I'm interested in SSTO propulsion tech X. What are its pros and cons? How can I reduce the cons or make them useful? What better tech can I use instead?" and it would be very helpful to us who come to answer you, if you made it clear if you're all in on hard sci-fi or if you want help spinning something realistic but extremely dangerous, to fit your established and well-defined sci-fi ruleset. I know what engine tech I would use, whether hard sci-fi or in sci-fantasy with custom rules. I'd love to see you reach that place. Please do some actual research, some worldbuilding, and define those standards. Project Rho/"Atomic Rockets" is a library of concept tech and Isaac Arthur is a YouTube channel that talks about, and feeds the imagination with, lots of plausible and semi-plausible scenarios. Indulge yourself. Your audience will love you for it.

If you need reaction wheels that big (and want to avoid using mods, which is usually the case) then I suggest you pack some LFO and spam some verniers. This is why they exist.

Hi there, @Mitokandria. There are three major components (I think) to a working Kerbalism refinery config. The first thing you need is a Profile{} to contain any and all Process{} that you create, and other parameters that are important to any Kerbalism profile config. So you want to have this: Profile { name = KerbalismSupport // Uses this value to (I believe) extend whatever the actual active profile (like "Default") is modname = Mitokandria Things // Can be anything but it's good practice to match moddir value. Can contain spaces and funky characters moddir = MitokandriaKerbalism // A mod folder name. Must exist in GameData/ Process { name = RegolithGasification // Personally, I don't like putting spaces in a name value. That's what title is for. Some mods don't like spaces here so I'm exercising a good habit title = Regolith Gasification // Something that I just made up isn't going to magically have a LOC entry modifier = _RG input = ElectricCharge@3.0 // 3 kW Furnace at 1800 C to begine coal gasification input = Ore@0.04 input = Water@0.06 output = CarbonDioxide@0.167 // 1g CO2 produced per day at 1800c output = LiquidFuel@0.000496445 // 1g CH4 produced per day at 1800c dump_valve = CarbonDioxide,CarbonDioxide&LiquidFuel,LiquidFuel } } The second thing you need is a resource definition for your pseudo-resource. It is a root node (a configNode that is not inside of any other, like Profile{} above and any PART{}). RESOURCE_DEFINITION { name = _RG density = 0.0 isVisible = false } The third thing is the actual insertion of modules into the part you want to use. Be careful with the :FOR pass. (You might not need it at all so test without it and see.) Don't use :FOR on a mod you do not own or your patch will tell MM that the named mod is installed when it's not. @PART[ISRU]:NEEDS[Kerbalism]:FOR[MitokandriaKerbalism] { MODULE // Must have a match inside a SETUP{} below { name = ProcessController resource = _RG title = Regolith Gasification capacity = 1 } @MODULE[Configure] // The switcher for converter or harvester chains { SETUP // Your chain added to the options/ other chains in the switcher { name = Regolith Gasification desc = Burn <b>Ore</b> and <b>Water</b> at 1800 C and get stuff. // Change as you wish. Basic HTML works here MODULE { type = ProcessController id_field = resource id_value = _RG } } } }

Actually, no. If you have sufficient energy to power any sci-fi ship's main engines, you're already sitting on doomsday levels of energy. If you know what the Kzinti lesson is, that would be great. All this mention of power banks is for naught. If you're concerned for their ability to explode then automatically, there will be a common knowledge of how to forcibly release that stored energy, and evildoers will be willing and able to do it. There are so many things wrong with this idea too... To put it simply, if a mothership needs to be gutted in order to land "safely" then it's not a mothership. At best it's actually a huge dumb payload and the same shuttles are its power source and main engines. And that leads back to my point above, about doomsday levels of energy. You don't want to leave those "shuttles" alone in orbit anyway. Bad things can happen and they'll explode with all the might that you're trying to ignore... and then the "mothership" becomes a beached whale without anyone dying (assuming no one is going to be on those shuttles).

Banned for admirating the pagination function

@GlaceAuPlutonium There'a already a mod called "Kerbal Galaxy Re-[something]" so... Ehh... Not too smart a choice. On the side, I recommend you start (very) small and make a mod for just one star and its planets, and then get better at making that mod look good. As things appear right now, you'll easily waste a good mod name and then learn the hard way that you were trying to bite more than you can chew.

I've been making exactly that. It's still rather experimental but it's mostly finished and is in need of playtesting so do try it out and give feedback. Wild Blue mods are required in order to provide proper behavior for the experiments since there needs to be more to them than just touching the water and being run in the span of a mouse click.

Release 0.9.3 Added Fishing Drone wedge: Produces Fish resource every few hours. (Requires Buffalo 2 but not also Snacks and SunkWorks.) Added CookBook / "Seafood Mis-adventures #1" basic experiment. (Requires Buffalo 2.) Added (untested) support for the Experiments Take Time mod. Converts WBI experiments to stock-ish and makes them require time. I happened to stumble over it while looking for the mod for extended info for stock experiments. I decided I'd whip this up for folks who really want just the ocean experiments and might strongly not want the WBI mechanics surrounding them. Some experiments may be disabled in accordance with this option. Fixed fuel tank patch problem that caused the fuel tank wedge to not appear. Gave parts shiny material where needed. Known issues Cargo bays don't want to aero shield their contents. Some Indicator Lights issues mentioned in the OP may remain. Allowed Planets (a spoiler function where these experiments are concerned) has a toggle to not show but that toggle isn't currently functional. Extra experiments on the Goo Response wedge and Bathymetry wedge become a cheat when there's no plugin for altitude ranges for experiments. Wild Blue Tools is currently the only mod that does provide for this. Linux's mod(s) don't appear to give correct time values for the experiments.

Banned for causing a bruh moment for Blueshift (mod) players.

there's a good chance that it works just fine. It's just models and configs. But the particular bug might happen (again?) where KSP may hang at any part that animates and has a solar panel module. You can send it further. Just build a transfer stage or tug with the necessary dV.

Where IS the NERV-US engine, anyway? It's supposed to be here!

@regex Yeah I noticed. That 1450s in vac is suptidly low. It's in solar thermal rocket territory and not a comfty roughly 2000. Material considerations are probably indeed in play since each of its chambers are 1.25m or narrower. Can't let such small and naked things (there's nothing that suggests they're immediately attached to a powerful heatsink...and the engine might be un-dense for its size if we may use the NERV as a yard stick) run at peak temperatures or they'll breach themselves. I'd love to see a true part upgrade system, now that you mention it. It would be a fabulous use of the resource "barter" system that this game seems to be pushing for.

Well. While the in-game NERV is based on a pretty early (and dare I say, crippled) form of solid core NTR (and solid core tech on the whole does get a lot better if you do a little googling), the SWERV tells you loud and clear that it's advanced and it means business. It is a (closed cycle) gas core NTR, and in my opinion, a gas core fission engine (especially an open cycle one) is something you don't want to operate in atmosphere or while landed, or have it pointed and firing at any planet you want to live on. KSP2 could be just right with such a restriction system and an associated penatly system attached to engines that use or produce fissiles (and gammas in the case of fusion and beyond). The two engines are literally a world apart in terms of type, and therefore, performance, and would still be so even if they were made the same size (that is, you put an equally large NERV to stand beside the SWERV.) The problem is actually that folks forget that KSP2 is not KSP1. It isn't about the tech and achievements and limitations and "nearly happened" of yester-year anymore. It's about the tech and intentions of the next 50+ years. We NEED the "so-called OP" engines in order to get anywhere with desirable payload masses in reasonable time scales. Furthermore, as in the above post by @SciMan the NERV was nerfed and was nerfed too hard for fear that it would make nearly every other chem rocket useless once you unlock it. Squad never bothered to develop a usage restriction system or a more interesting drawback to help the NERV stay niche while being rightfully OP vs chem, so it has remained a rather shameful cripple in the eyes of anyone who knows better about how nukes work.