JadeOfMaar

Hyyyyyyype! Blue Steel lives!

Assuming you're not interested in Eve (which is a warm planet and needs the likes of LiquidFuel added onto it, and the sole reason I didn't suggest the following sooner), then Huygen and other cold, outer worlds such as Tekto are applicable for the likes of Explodium Breathing Engines due to the Methane gas and LqdMethane ocean presences that RR will give them, and this was planned far in advance with the knowledge of planned exploits for the IRL moon, Titan. Your mod would be perfect for Methane-breathing jets and rockets if you go this way. That's what I would do, personally, once Eve, with its affinity for heavy hydrocarbons, is ruled out. That said, there's a self-contradiction at work where a methane planet's atmosphere won't have much methane in it, and modest amounts would be found instead in the atmosphere types: Vulcan, Ice-Water (thick) and Ammonia (and certain gas giants). So maybe it's better you stuck to the whitelist key. I may be setting you up to disappoint myself, yourself, and your fan-base. The reason behind this is logic from @OhioBob: If a body has a Methane ocean, then it's cold enough that virtually all the Methane froze out of the atmosphere.

Hmm. Now I really wonder about that. I'm considering certain factors now that I really didn't when I contributed to configuring it. There should be a B9 module on it that lets you switch between LFO and LH2O but that *might* only be available for Classic Stock. I don't remember which is the case.

@OrbitalManeuvers Correct.

@Captain Sierra That's some golden feedback! I assume you're using CryoTanks, however? (This seems to be a very popular combination). The aerospike's thrust does not change to adjust to the (rather great) difference in wet mass when Mk-33 holds LFO vs LH2O. I could make this change but then you may end up with much less opportunity to use the filler wedges and their adapters/engine mounts, and this may upset its usability (through it's 3.75m adapter variant) with non-Mk33 parts.

@Gordon Fecyk Your resources being purged is a feature, not a bug. Part of RR's behavior is that it removes any handwavium presence like USI's Karbonite, Karborundum and The Gold Standard's Unobtanium. Simply insert into your distribution nodes, Tag = Spared (any value works, actually, but you can take the opportunity to uniquely ID your mod by the value as may be done for some planet packs) . RR does not add anything that is placed and could be purposed as an alternative to ExpVapor, and you're a very logically minded and and realism-oriented fellow so it's better that you whitelist your own resources.

@BobTheKerbalTrying to get around in GU (or any real interstellar environment) with stock engines and Hohmann transfers is -not- how things work. There are mods for appropriate fuels and engines, including GU itself.

As a spaceplane guy I didn't like that @damonvv's KSC Extended only cares about rockets so I made my own major space center expansion! With Blackjack and h#$%^&s! But they're totally meant to be a pair!

@InfamousAsHell Uninstall Buffalo and then try to install Pathfinder. The Pathfinder download contains Buffalo so maybe CKAN is confused by this.

Basically, should ResearchBodies be stock in KSP2? The answer is obviously yes.

@Clamp-o-Tron Yes it is. Ninja'd by Bob. But particularly, it doesn't add or subtract moons from the stock planets. Doing so may be outside of Galileo's vision. Other things concerning the planets (not their numbers and positions) do wait to be done, like biomes and anomalies.

Ahh. Well you can try this patch and lower its value, and let me know how things go. @PART:HAS[~gTolerance[*]] { gTolerance = 50 // default value }

Go into Difficulty Settings -> Advanced at any time and turn on part G-force limits (right next to kerbal G-force limits and part pressure limits). You'll be a happy camper. These are off by default because they're meant for use by players who like extra realism and extra hard mode like users of KCT, failure mods, RSS & RO...

The 2.5m probe core is actually super powerful but you won't easily notice in the stock system. If you put this, 2 kerbals (preferably pilots, I think) and a few RA-100 dishes together, you get a DSN hub/outpost and can control drones and probes over several comm hops without needing a comms link back to Kerbin. If you like mods then you can add Science Relay, and setup this hub craft to be a science depot which can receive all transmittable science, which can then be transmitted or shipped in bulk back to Kerbin.

@Svish CLS compatible hollow parts would need to be made separate from these (with only one option: structural, to spare this mod's maker from basically remaking his parts. Making a part that has many variants is not an easy task). It is unknown if B9 Part Switch naturally agrees with CLS and can control when a part is passable. This is the easiest of 3 possible solutions to this problem.

If you can indeed make a KSPedia, ask any modder whose own still works, such as DMagic or SuicidialInsanity, maybe JPLRepo, and hopefully they'll show you what to do differently. But you may have the added challenge (if it applies) of acquiring or producing source files.

@FrancoisH The Unity updates (from what I've seen) are what break KSPedia, so KSP 1.4 and 1.8 are where this happens.

Change the top line in the config to this/ Add this NEEDS to it: @PART[sspx-cargo-container*]:AFTER[StationPartsExpansionRedux]:NEEDS[!ClassicStock]

@stephm Material: Extremely important. Do not use additive/emissive/glow shaders for smoke. Those are used for fire/energy/plasma. For smoke and vapor plumes, use a shader that is not emissive. Unity is not working for me so I can't open it and list the exact ones for you to use. They probably have "Alpha" in them so look for non-emissive alpha shaders to use for your material. Simulate World Space: This makes particles respect their position in the world. This is how trailing plumes work but trailing plumes only look good at low speeds (under Mach 1). Only use this for custom smoke for engines in atmosphere. You won't enjoy using this on high speed or orbital engines. In most cases, untick this immediately. Size: When a particle spawns, it gets a random size value between the two numbers. Max Size only really needs to be turned up to 3. Beyond that, particles can get enormous which will punish the CPU. Energy: The lifetime of a particle. When a particle spawns, it gets a random value between the two numbers. Emission: The spawn rates. When particles spawn, the amount is random between the two numbers. Size Grow can be very subtle depending on how you set other parameters like the particle lifetime ( Energy ) and speed (Local Velocity + (Random Force)). If you set a very high Size Grow (like 10 or 20) and a low Energy you can get the effect of a vacuum engine with RealPlume. Local Velocity: only use this one. Don't use World Velocity or Random Velocity. They produce unwanted behavior where KSP is concerned. Force is self explanatory. Particles are pulled or pushed with a constant force and their path steadily bends while they exist and move. Random Force is where each particle is pulled with an amount of force between all zero and the numbers you set. It's good for wild plumes like a flamethrower or SRB. Random Rotation applies random rotation/orientation (not spin) each time a particle spawns. This is very good for smoke and fire plumes. Angular Velocity applies a uniform spin rate to particles as they spawn. This allows you to make whirlpool like plumes to a limited degree. You cannot make perfect particle whirlpools in KSP, however. Random Angular Velocity applies random spin rates (per particle) between 0 and the number you set. Use this to add a feeling of turbulent flow to your plume. This can be used with Angular Velocity and their combined effect is random addition or subtraction to each particle's spin rate. Animate Color: The most important property of a plume when you do this is the alpha curve. Alpha (in RGBA) is opacity. This needs to drop, not rise, as the particle goes on. The alpha value is shown as a very narrow white/black bar under the color bar in the gradient step. Pay very close attention to it.

@Bombaatu Oh. I didn't anticipate that but yes, these are incompatible (and meant to be so). I'll fix the SSPXr patch to not try to run when Classic Stock is present.

You're welcome. But I don't think there is any actual concept for an electric pulse jet. I highly doubt it would be possible or worthwhile to attempt this. The electric jet engine concepts that I've seen and I can remember easily are a form of super powered Hall Effect ion thruster, and the microwave air plasma thruster which is effectively an air-breathing rocket.

@cyberKerb What is this "FuelScience"? What makes it special?

@flart B9 Part Switch can do everything that stock variants can, so it's good practice to only use one of these switchers, or if you will mix them, only use variants for switching the mesh or textures, and let B9 handle everything else (mass, resources, nodes...)

Size Grow is the plume's ability to change size during its lifetime. The higher the value, the faster it grows. It also accepts a negative value to make the particle contract or shrink (as far as -0.9999 but don't put -1 which will break the plume). I don't use Length Scale or Velocity Scale but I do use Max Size which controls how large the particle can get. Raising this setting is important for particles used on engines that the player will want to zoom in on because they look good. If you don't raise this for such plumes then the particles will become small and unsatisfying when the player zooms in. I guess Length Scale or Velocity Scale therefore affect how the particle's length and speed change when the player zooms in. A critical thing you'll want to do when you make your own particles is to add the checkbox to edit Gradient, and make a gradient curve (especially in the Alpha channel) so that your particles can visibly fade in and out over time. Look at this Imgur album of particles I created for trench flames under a super heavy rocket and be inspired.

You're trying to name the "WarpJet" engines. They use a magnetic rail system (resembling a Star Trek warp nacelle) to compress air and manipulate plasma streams, making a way to escape the need to combust oxygen to be useful. It's definitely a far future breed of air-breathing engine and is partly based in real concept propulsion tech. OPT's J-81 has an undefined and unreasonable combustion scheme but is finally going to be changed to resemble, in performance, something reasonable: a KSPI fusion aided ramjet. Its air-breathing mode will only require IntakeAtm and will require EC, and its rocket mode will only require EC and LiquidFuel (cease to require Oxidizer), and EC demand in both modes will be higher. Anyone who is willing and able is invited to create a config to give these engines more "realistic" behavior. I can do my part, where needed, by making the web of OPT Reconfig's engine patches not fire under a certain condition, and so won't complicate things for such patches. Show me your WarpJet config and I'll help you out. I'd like to say that there's a certain depth to my reasoning behind making the engines very OP. Part of which is in trying to make the engines attractive to players of up-scaled or highly expansive planetary systems, and I've seen many players who do well not to be bothered to spam engines as usual, to make a spaceplane fit for their purposes. I'm pretty interested in what it would look like-- a config that balances OPT's engines as if Nertea made them.