Search the Community

SMURFF: Simple Module adjUstments for Real-ish Fuel-mass Fractions For people who want real-ish fuel mass fractions without too much hassle. Formerly "Simple Mass adjUstments for Real-ish Fuel-mass Fractions." Features SMURFF is a Module Manager patch that reduces the dry masses of fuel tanks and engines and improves engine performance so that KSP rockets can have fuel mass fractions closer to what we make in the real world, without going into per-part configurations like e.g. Realism Overhaul. Most of a real rocket's structural strength comes from the fuel inside of it, rather than the tanks themselves -- the "tank" is just a metal shell to hold the fuel together. KSP fuel tanks, on the other hand, seem to be made of lead plates and rebar. This is all well and good for a planet where you only need 3.5 km/s to get to orbit, but it's not a lot of fun for the real solar system. To help ease the transition to RSS (without requiring per-part configurations, thus allowing any mods to be supported), SMURFF makes several adjustments to engines, tanks, crew modules, and heat shields. These adjustments are calibrated so that stock and stockalike-balanced parts will have their performance (TWR, fuel mass fraction, and ballistic coefficient) improved to be "real-ish" -- representative of typical aerospace technology of the last few decades, so that rockets built in RSS or 10X have mass fractions similar to real rockets. You can reduce the buffs applied to parts (without tinkering with the mathematics) by reducing the values of "tanklever", "enginelever", and "podlever" at the top of SMURFF.cfg (or with a patch). When they're set to 1 (as they are by default), the adjustments are made at their full values, and when they're set to 0, parts are left at stock performance values. In-between is in-between, so those interested in intermediate-difficulty solar systems may want to experiment with setting the values to 0.5. There are some built-in protections to prevent part masses from being sent into negative values, but otherwise, SMURFF will patch parts as if their mass and thrust values are balanced with stock parts. If you want to exclude parts from being patched (e.g. because they already have real-ish TWR), include "SMURFFExclude = true" in the top-level config. To avoid griping from KSP when SMURFF is not installed, you can use a patch like this one: @PART[whatever_parts]:NEEDS[SMURFF] { %SMURFFExclude = true } The specific adjustments are as follows: Stock and stockalike liquid fuel tanks (LFO, LF, Monoprop) have a fuel mass fraction of 87-89%; SMURFF increases this to 97% by reducing dry mass by 76%, putting them in line with real spacecraft fuel tanks. Tanks that have fuel-switching patches from Stock Fuel Switch will get the appropriate mass buff for their equivalent Liquid Fuel and Oxidizer contents. Other parts with switchable fuel tanks get their dry masses divided by 4.2, except for parts which are switchable in-flight, which only get a 50% dry mass reduction. Xenon gas tanks are adjusted from 56% to 90% (86% reduction in dry mass). I've seen some NASA sources saying xenon tanks are 95% fuel (or suggesting that they will soon be so), others suggesting 85%, so I went with 90%. Ore tanks are adjusted from 86% to 95% ore-by-mass (70% reduction in dry mass), to baseline against 55-gallon drums. Several mod resources are also handled (mostly from Nertea's various addons, since those have enough parts to produce a consistent balance). LH2 tanks get their mass fractions adjusted from 83% to 78% (a slight increase in dry mass). Because of the LFO buff, hydrolox "lifter" fuel tanks still go from 84% to 93% fuel by mass. The zero-boil-off power requirement is increased by a factor of 15, so they now require 1.2 EC/sec per 1000 L of hydrogen stored. (That's nearly 1400 EC/sec for the largest LH2 tank. The best way I can think of to handle that is with a dedicated 2.5m nuclear reactor.) Real zero-boil-off systems also require a heavy mass investment in passive thermal isolation and dedicated cryocooling systems, so it wouldn't be possible to use a rocket tank for zero-boil-off storage just by connecting it to a nuclear reactor, but this is one place where I bent for gameplay reasons. Argon gas tanks from Near Future Propulsion are adjusted from 75% to 62% fuel (an increase in dry mass). In stock, they match the efficiency of xenon tanks for gameplay balance reasons, but in reality, xenon tanks are much more efficient, and argon not nearly as much (xenon atoms are heavier, so a much greater mass of xenon can be packed into a given tank design). Argon is more abundant (and thus cheaper) than xenon by orders of magnitude, so for large missions, the reduced fuel cost may be enough to make up for the mass penalty. If anyone has a reference for the mass-efficiency of lithium storage and vaporization systems for spacecraft, I'd be happy to hear it. Until then, I'm buffing them to 87% fuel, which corresponds to a volume density between LFO/MP and LH2. NFP's xenon tanks are 75% fuel by mass (and they adjust stock xenon tanks' masses accordingly), so SMURFF's xenon patches will adapt themselves if NFP is installed. Karbonite is not handled at this time, as its tanks' mass efficiencies are already better than 95%. Bipropellant (LFO and LH2/Ox -- or anything with Oxidizer) rocket engines' thrusts are increased by 50%. Any that are not crew containers or multi-mode engines also get a 62.5% reduction in mass. Comparing the stock LFO engines to real RP-1/LOX rockets (as opposed to the LH2/LOX SSME, as I did previously), the "orbital" (i.e. stackable) stock engines have TWRs from 15-25, while real engines have TWRs from 60-100 (and getting up to 150 nowadays), so the TWRs need to be quadrupled. The Skipper is actually a pretty good analog to the Merlin (several hundred kN of thrust, 2-3 meters tall), but rather than just cutting the weight to match TWRs, I increase the thrust so that stock rockets don't need ridiculous numbers of engines (recall that SpaceX uses nine Merlins on their first stages -- and incidentally, it turns out that SpaceY engines get their TWRs pushed into the 120-150 range, just like SpaceX's). SRBs (baselining with the Kickback compared to the Space Shuttle SRBs) get their dry masses reduced by 40% and specific impulses get buffed by 40 seconds. Their thrusts are left unchanged -- fuel density and TWR are already close to reality. Nuclear thermal rockets, jet engines, monopropellant rockets, and ion thrusters are left alone. (Oxidizer-burning modes of multi-mode engines still get the thrust buff.) Crew containers (pods, cockpits, cabins, etc.) and heat shields have their masses reduced by half (and their pyrolysisLossFactor doubled). I justify this by looking at the mass-per-passenger of space capsules and jet liners, ballistic coefficents, and comparing crew cabins to fuel tanks of the same size. For example, the Mk1-2 command pod weighs as much as the Apollo Command Module despite being nearly 40% smaller (by diameter -- 26% of the volume) and carrying half-sized astronauts. The Mk1 and Mk2 crew cabins weigh as much as a full fuel tank of the same size, despite being mostly air-filled. Same for heat shields -- the Apollo heat shield was 3.9 meters across and weighed 850 kg, vs. 2800 kg for the stock 3.75m heat shield. (The reason that I didn't cut heat shield masses by 70% is so that shields can still be used for landing larger masses than just a capsule.) Most of the patches stack (e.g. a service module with both monoprop and liquid fuel will have its mass reduced appropriately), but not the ones that divide tank mass by a factor (crew capsule, bipropellant engine, and general-purpose switchable tank) -- only one of those may apply to any part, and they get applied in that order. The result is that rockets have more Earth-like mass fractions and thus are able to achieve Earth-like payload masses without requiring the construction of horrible asparagus monsters. To compare: with stock part masses, to get the Mk1-2 capsule (plus parachute and heat shield) up into space, I need to convert the Kerbal X into the "Kerbal X Triple-Heavy" (or "Kerbal 7"), with 6 asparagus-staged size 2 boosters identical to the core (actually, identical plus the round X200-6R tank from TurboNisuReloaded) and an extended upper-stage tank (an X200-32 instead of the stock -16). It gets just shy of 7 tons into LEO (not counting the spent upper stage) with a 465-ton rocket (not counting the payload -- almost 70 times as much rocket as payload) which blows up the launchpad at takeoff. With SMURFF, I just have to make the Kerbal X into the "Kerbal Xtended" by doubling the upper-stage fuel tank (the stock Kerbal X is entirely capable of getting into orbit on its own, but the extension is necessary to add the heat shield...), putting 3.52 tons into orbit (not counting the spent upper stage) with a 113.9-ton rocket (not counting the payload -- 32.36 times as much rocket as payload). The Falcon 9 v1 got 10.5 tons into orbit and weighed 335 tons (31.9 times as much rocket as payload), using slightly less efficient engines than the Skipper and Poodle, so I figure I'm close enough for Kerbal work. Dependencies SMURFF depends on Module Manager version 2.6.16 or later to function. Recommendations SMURFF is mainly intended for use with Real Solar System. It's why I made it, and that's where the default balance is set. Try setting the levers to 0.5 for intermediate solar systems, like 64K or SKY. Big rocket fractions (i.e. 1 kg into LEO = 25+ kg of rocket) call for big rockets, so SpaceY and SpaceY Expanded (alternatively, Behemoth Aerospace Engineering or Near Future Launch Vehicles) are recommended to get big rockets without big part counts. 1.875m rocket parts from Home-Grown Rockets (maintained by yours truly) and MOLE are also great for large upper stages and for payloads that are just too big for 1.25m rockets, but where 2.5m is overkill. (Since thrust increases with the square of scale, and mass with the cube, all else being equal, the jump from 1.25 to 2.5 is proportionally much steeper than the jump from 2.5 to 3.75, so I've found 1.875m parts to be surprisingly handy.) Of course, the other way around needing massive launch vehicles is to make smaller probes, so I've also gotten quite a bit of mileage out of RLA (Recontinued) and Modular Rocket Systems. (Most of that mileage is from the "Sparkler" engine in MRS.) Suggestions Other addons that bring "real-ish" capabilities and challenges to Kerbal Space Program include: SCANSat, to make biome and elevation maps globally available (vs. the limited-view and limited-access KerbNet system) and optionally require just a bit more effort when scanning for resources. DMagic Orbital Science, Impact!, MOLE, Nehemiah Engineering Orbital Science, and the Breaking Ground expansion add science experiments that have actually been run in space. Station Science is in the same vein, although it's a little more on the 'fantastic' side. (If you're going to run most or all of these, you should probably use an expanded tech tree or dial back science returns in the difficulty options, to preserve game balance.) USI Life Support, for a life support system which is simple and forgiving (unless you configure it to kill Kerbals). USI Kolonization Systems and/or Pathfinder, for ISRU that allows self-sustaining colonies (with some effort). You should also consider picking up Global Construction and/or Extraplanetary Launchpads and OSE Workshop (and Kerbal Inventory System, OSE's dependency), as an extension of NASA's real-world interest in in-situ manufacturing and repair. (And to give your bases something new to do.) To (loosely) simulate long-term physical impacts of microgravity, there's KeepFit. (Be advised that it does require specific mods for "exercising" spaces. Currently Civilian Population, CxAerospace, DSEV, Stockalike Station Parts Redux, SXT, Tokamak Industries, and UKS are the only mods with "recognized" exercise rooms. It is much more generous when it comes to mods with "neutral" habitation space.) As an alternative to KeepFit and USI-LS's habitation effects, KerbalHealth looks promising. Nertea's Cryogenic Engines, Kerbal Atomics, and Near Future Technologies provide cryogenic, nuclear thermal, and ion and plasma propulsion systems, as well as a simple boiloff and boiloff mitigation mechanism for liquid hydrogen. SMURFF will adjust their respective fuel tanks to match their actual or predicted performance. (Except for lithium, which I haven't found any references for -- it gets adjusted, but it's largely a guess on my part.) For more realistic handling of engine throttles and attitude control (because real rocket engines can't be throttled down to 1% of their maximum thrust), check out Throttle Limit Extended and MandatoryRCS (I recommend turning on the option that permits reaction wheels in crewed pods to operate, since otherwise that's just yet another part you'll have to add to a vessel). Feel free to suggest other "real-ish" addons! To give you some idea of what I'm looking for, addons suggested with SMURFF shall adhere to the following criteria: They shall not require individual parts to be configured in order to function (as e.g. RealFuels does) -- if an addon can't work out-of-the-box with any other addons that people use, it doesn't belong on the list. They shall improve the realism of some aspect of KSP that is not very or not at all realistic. (KSP has no life support whatsoever, so USI-LS is included, but it has mildly realistic aerodynamic and heating systems, so FAR and Deadly Reentry are not.) Of course, criterion zero is that I won't suggest an addon that I don't like and use (or have used or considered using) myself. Download and install GitHub CurseForge From there, just unzip the "SMURFF" folder into your GameData directory. Please let me know in the forum thread or on the GitHub issue tracker if you find any issues! Version history and changelog 2015 08 08: Initial release. 2015 11 19 (1.1): Renamed to Simple Module adjUstments for Real-ish Fuel-mass Fractions (since we're not just touching mass anymore). +50% to non-SRB engine thrusts and -62.5% to mass, to bring TWRs in line with RP-1/LOX engines and reduce need for ridiculous engine clusters. +40 seconds to SRB Isp, to bring Kickbacks in line with Space Shuttle SRBs. Mass reduction of resource containers is now proportional to their contents, so parts which have resources and do other things (e.g. command pods, wings with fuel) only get mass reduction corresponding to the part of them which holds resources (e.g. command pods are now slightly lighter because of their monopropellant storage, but not by a factor of 4). New patch to act on Procedural Parts. Based on RealFuels data and further research, LH2 and argon mass fractions no longer improved. Adjusted patch to properly grab all engine modules. Compatible with Stock Fuel Switch and Cryogenic Engines. If you replaced or modified Cryogenic Engines's fuel switcher patch, make sure you restore it to the original -- otherwise, tanks might get double-buffed. 2015 11 20 (1.1.1): Minor bug fixes. Fixed Procedural Parts patch (thanks to speedwaystar). Excluded air-breathing jets, nuclear thermal rockets, monopropellant engines, and ion engines from TWR buffs. (They're close enough to reality already.) 2015 11 22 (1.1.2): More compatibility (inspired by Atomic Age). Improved selectivity of engine mass buff by excluding multi-mode engines and IntakeAtm-breathing engines. (All Oxidizer-burning engine modes will still get a thrust increase.) 2015 12 07 (1.1.3): More selection adjustments. Changed engine mass buffs to apply to engines which only have oxidizer-burning modes (so that SpaceY's engines get buffed -- they use a MultiModeEngine module to simulate the all-nozzle vs. center-out/center-only modes of operation, so excluding all multi-mode engines wasn't fair.) 2016 01 08 (1.1.4): Argon adaptation New ArgonGas patch for the tank efficiency changes made in Near Future Propulsion 0.6.0. I've made some slight changes in the backend for handling Cryogenic Engines. In my testing, I haven't noticed any changes in spacecraft mass (either in the VAB or in flight), but please be careful! 2016 01 27 (1.2): Entry, Descent, and Landing Masses of crew containers and heat shields are reduced by half, to permit reduced (and reasonable) capsule ballistic coefficients. Now pods are more likely slow down in time to get their chutes open. Added a "reserved mass" system so that engines and pods only modify mass which is not accounted for by fuel tanks and batteries. Added a "SMURFFCONFIG" section -- adjust the "tanklever", "enginelever", and "podlever" variables to control how much of a buff is applied. 1 for real-ish performance (default), 0 to leave stock values alone, and everything in between is in between. Try 0.5 for the likes of 64k or SKY. Changed patches to run FOR[zSMURFF], so that the patches run later. SpaceY's engines now get properly buffed when Cryogenic Engines is installed. (SpaceY replaces the ModuleEnginesFX modules of some engines in that circumstance, and since SpaceY comes after SMURFF, the thrust buff was being overwritten.) Added a "fix" for parts whose mass gets sent into the negatives (i.e. any part which weighs less than it "should" by stockalike standards): their masses get restored to their initial values. Added support for "SMURFFExclude" -- add "SMURFFExclude = true" to any part you don't want to get buffed. 2016 02 02 (1.2.1): De-icing Adapted to new Cryogenic Tanks LH2 mass fractions and tank setups. (LH2 tanks actually get hit with the nerf-bat.) 2016 02 20 (1.2.2): Sore throat Added some new patch logic to catch ablative engines. 2016 03 17 (1.3): Wild Blue Yonder Parts with WBIResourceSwitcher (e.g. the Titan fuel tanks from MOLE) are now included in the switchable-tanks patches. Switchable (FS and Interstellar Fuel Switch) tanks with different tankMasses now get proper mass buffs, thanks to the new array-editing features in Module Manager. This feature is only present in MM version 2.6.16 or later, so this version and later versions are not compatible with KSP 1.0.4. 2016 05 17 (1.4): Inb4B9 Handles B9 Part Switcher, and the corresponding updates to Cryogenic Engines. Also changed patches to run FOR[zzz_SMURFF], so that it comes after the cryotanks patch. Because the corresponding version of Cryogenic Engines was released for KSP 1.1.2, this version and later versions are not compatible with KSP 1.0.5, 1.1.0, or 1.1.1. Handles the tankResourceMassDivider variable from the generic IFS patch. Lithium tanks now get buffed. 2016 05 26 (1.5): Ore Rly? Ore tanks are now adjusted, baselined against 55-gallon drums. Compatible with tank types included in Near Future Construction 0.6.2. Added new "Extras" folder for patches that are too part-specific to be included in the main distribution. The first Extra patch is for the CryoX and soft tanks from Ven's Stock Revamp. I make no promises about their balance when used with CryoTanks or other fuel-switching plugins... 2016 05 28 (1.5.1): Mass Deregulation Relaxed one of the "overdraft protection" checks. 2016 05 28 (1.5.2): Ore you sure? Added procedural ore tank type. 2016 05 28 (1.5.3): B9-B Made the CryoTank patches less brittle, to handle parts with multiple B9PartSwitch modules (e.g. Fuel Tanks Plus). 2016 08 15 (1.5.4): Tanks F-Ore Nothing Added an "Extra" patch to fix the procedural ore tank. If you're using Procedural Parts, drop the "ProcOreFixer.cfg" patch in your GameData folder (anywhere will do). The license is changed to the GPL v3 (or later). 02016 10 29 (1.5.5): Snow Miser Updated CryoTanks patch to adapt to rebalance. Because the corresponding version of CryoTanks was released for KSP 1.2, this version and later versions are not compatible with KSP 1.1.2 or 1.1.3. 02017 01 28 (1.6): Happy New Year Removed "Extra" patch for the procedural ore tank, as they've accepted my PR to add it directly to the part config. Engine patches now operate on minThrust as well as maxThrust (if someone should ever release an engine with nonzero minThrust). Reduced reaction-wheel authority on command pods in proportion to their mass reduction. Adjusted IFS patch. It works again, but note that IFS already has its own RSS patch, so SMURFF defers to that. Added support for Mark IV tank types. Because the corresponding version of Mark IV was released for KSP 1.2.2, this version and later versions are not compatible with KSP 1.2.0 or 1.2.1. 02017 02 24 (1.6.1): B9-C Another tweak to the CryoTank patch, to avoid stepping into B9's CryoTank patches. 02017 04 10 (1.6.2): Kerbals Not Smurffs Exclude Kerbals from SMURFF patching. Add pure-LF IFS patch. 02018 02 09 (1.7.0): Zero Level Adjusted tank math to remove divide-by-zero error. Feel free to set tanklever = 0 now! Rebalance of tank adjustment factors to adapt to changes in Near Future Propulsion and CryoTanks (and some in response to user feedback). LFO and hydrolox tanks got a bit of a buff, most everything else stays put. Because the corresponding versions of NFP and CryoTanks were released for KSP 1.3.1, this version and later versions are not compatible with KSP 1.2.2 or 1.3.0. The "Extra" patch for Ven's Stock Revamp is more detailed, and now has different behavior for when CryoTanks is or is not installed. Their performance is baselined to the Super Lightweight (Space Shuttle External) Tank. 02018 03 21 (1.8.0): Kerbal Equinox Updated xenon patches to new balance of stock tanks. Because those changes were made in KSP 1.4.0, this version and later versions are not compatible with KSP 1.3.1. 02019 05 19 (1.9.0): The Power of the Special Vintage Kerbal suit variants now excluded from patching. Moved Ven's "Extra" patch into the main SMURFF folder, now called "Special". Squad's new capsules (Mk1-3, Mk2, and Mk2 Lander Can) now have a "Special" patch, since they're much lighter than their predecessors. Update ZBO power requirement patch and Procedural Parts patch to adapt to CryoTanks update. New "Special" patch for Universal Storage II tanks. New "Special" patch to handle Tundra Exploration fuel tanks. 02019 11 12 (1.9.1): Green Origin Adding support for CryoTanks' liquid methane tank variants. Because these were added for a version of CryoTanks made for KSP 1.7, this version and later versions are not compatible with KSP 1.4 to 1.6. Futuristic Kerbal suit variants (Breaking Ground) now excluded from patching. Roadmap As I get the time, I'll publish to CurseForge. If you find any classes of parts (i.e. anything that can be described by using Module Manager to filter by module, resource, mass, etc.) that get horribly mistreated, I'll make an adjustment. I might even make a special patch for a particular mod's parts, if it's not too much trouble on my part. Roadmap As I get the time, I'll publish to CurseForge. If you find any classes of parts (i.e. anything that can be described by using Module Manager to filter by module, resource, mass, etc.) that get horribly mistreated, I'll make an adjustment. That being said, I'm not planning to include special patches for parts that are already themselves outliers in the main distribution (although I might add some to the "Extras" folder) -- the whole point of SMURFF is to avoid that level of complication. Credits Thanks are owed to NathanKell and the entire Realism Overhaul team for making an incredibly detailed, thoroughly researched and calculated system...and convincing me to make something simpler. The tank-mass spreadsheet was a handy resource! Even more thanks to ialdeboath and sarbian for the power of Module Manager. Seriously, half of my addons wouldn't exist if not for them. License Simple Module adjUstments for Real-ish Fuel-mass Fractions ("SMURFF") is copyright 2015-2018 Kerbas_ad_astra. Configuration files are released under the GPL v3 license (or any later version). Any redistributions must use a different name and folder (per section 7c). All other rights (e.g. the SMURFF logo) reserved.

Imagine WW2 never happened, imagine that the Dutch would have developed a far better relationship with their colonies than that did in our universe. Perhaps rather than consistently marrying Germans, the royal family would marry Indonesian royalty, and rather than speaking of the Dutch-Indies, the economic scale would speak of the Indo-Dutch. Regardless, the world is a different place and we find ourselves in 1951 as we start a new playthrough in the north of the Netherlands as we try to avoid the US and USSR tech lines as much as we can since I've already done playthrough with these. Episode 1: Fresh beginnings In this episode, we launch several V2-derived rockets from our new launch complex at Texel Island and discover that film and parachutes do not work well together. Epsiode 2: Bio-breaks In this second episode the Dutch stretch the performance of the V2 and manage to send a hamster to space. It's about bio experiments and many things break, hence the name Episode 3: Orbit In this episode, we finally make it to orbit finish our Kerbal Konstructs work at Texel Island, and finally get our downrange contracts done. Big thanks to @seyMonsters as we are using a lot of his engines. Go check out his work in "a very British space program". I have taken some inspiration and am making configs from the Delft Sparrow project but that will come much later. Episode 4: A Plane Escape Our finances look grim and we take the program we didn’t want to take: planes! Over more than 20 flights we get our space program back on track, but it will rack the nerves and your bandwidth. We'll call it a plane escape. Skip to the end if you just want to see the last rocket of the year and learn why it is called the “Van Speijk” class. Episode 5: Space Planes In this episode, we continue our exploration of low earth orbit with the IRAS program which has a real-life Dutch analogy. We explore the story of the heen-en-weerwolf and return our hamster from orbit. And we have the first woman passing the Karman line. Episode 6: Look at you In this episode, we play with orbital cameras and deploy our first Nautical Navigation Constellation. We continue our search for high-radiation particles and optimize our current fleet of rockets. Episode 7: constellations Comm Sats and spy eh weather satellites are the main topics for this episode. Finally, we have good coverage in LEO! and we scour a lot of science. Stick to the end, because we give a peek view at the new launch complex in the Molukken called Surya base! Episode 8: hello neighbour As we wrap up the Earth observation satellite program, we launch an orbital perbutation experiment and then start sending the Chandra probes towards the moon. By the end of the episode, the Moon has a new satellite. Episode 9: Manned Orbit We complete our communication network in LEO, and have a flyby of Venus, in 2 days! After the US and put the first woman in space despite major issues with our ascent guidance computer. Episode 10: Evolved In this episode, we start with the European Space Agency (ESA) and soft land on the moon. We also show off the new volumetric clouds and HUD replacer changes. Episode 11: Moon cheese Our new European Space Agency (ESA) wastes no time and sends 8 probes to the moon to discover its composition. Half of them soft land on the moon, the other half.. Hugens 4 becomes the first probe to orbit another planet and we start mapping the surface of the moon. Episode 12: Firsts We turn back to Texel where we launch the next-generation spacecraft that can carry 2 astronauts. We have the first spacewalk, rendezvous, and a tedious and difficult first docking. Episode 13: Fly me to the moon In this episode, we land rovers on the moon, but that doesn't turn out as expected. The Dutch put up a prototype space station, man and resupply it and we see two attempts to do a manned lunar flyby as well as an unexpected lunar lander. Episode 14: Lunar manned orbit In this episode, we put the first astronauts in an orbit around the moon, spacewalk with a tether, and add the first international module to our space station: jita kyōei. We also have yet another failed rover, but a successful test of our little lander. Episode 15: First on the moon In this episode, we become the first to put a human on the moon, using a launcher that can only bring 20t to LEO. This mission could have gone wrong on so many levels! The docking fails, ladder shenanigans, we forget to stage the drop tank of the lander, and some advanced parkour when our astronaut runs into major problems but then thinks of Newton's first law. Episode 16: International spacestations After deorbiting our first space station it is time for a fresh one, a bigger one, a better one, a more collaborative one! We will see an unexpected new arrival, upgrades at the lunar gateway, and finally working rovers. That and a secret launch for the Dutch military. Episode 17: back to the moon After our collaboration with the Soviets in Spacestation Alpha, it is time to get our focus back on the moon with JAXA and NASA playing a pivotal role in this episode. We also launch a probe to Jupiter, and test a new spacecraft that has some suspicious activity in polar orbit.

UPDATE ON MOD'S STATUS 20/07/24 I do not really have any incentive to develop this mod anymore as I would like to focus on other projects. For anyone looking for a mod that adds similar content, I highly recommend RSS-Origin by Charon_S. It adds a lot of the same content but at a significantly higher level of detail and fidelity and is also highly compatible with other content. Thank you so much for the support I've had for this mod over the years!!! Hi there, and welcome to the Real Enhancements development thread. This mod aims to continue and expand pozine and imkSushi's Real Solar System Expanded mod. I plan to incorperate and restore the majority of objects in the mod My aim is to create a modular experience, so people can download packages based on their interests and their ability. I know this seems ambitious (especially RealStars, that one is going to take a while) RESPOSITORY LINK (outdated): https://drive.google.com/drive/folders/1oCeqlZ4fBs6TNvnN0R57TMqhKbSBVzzO?usp=sharing Github: https://github.com/AR3S-Vega/RealExpansion/releases It is recommended to install RealPatch to fix inclinations, other wise the inclinations of newer objects will be broken Discord Server (because Kopernicus won't give me a channel): https://discord.gg/pWfYbfm Requires: Kopernicus ModuleManager ModularFlightIntegrator RealSolarSystem Skybox requires TextureReplacer Catalog: As i said i wanted the mod to be modular, and you will be able to download each package individually. So if you are less experienced with RSS/RO you can download the NEO package, and if you want a challenge you could download Stars or ExtremeTransNeptunian objects Things i want to add (yeah i stole this image from imkSushi's thread) Current Status: Abandoned Credits: Me ("Our Benefactors") for doing something @Xurkitree for help with Kopernicus and RealAftermath @Noah the Smol and @GurrenLagannCWP (if I have the right accounts :P, most of the discussions have been done on discord) for working on RealHypotheticals pozine for making RSS Expanded in the first place imkSushi for restoring RSS Expanded NathanKell for Real Solar System AndrewDraws for RealExoplanets Gregrox for letting me use his sunflare TSMP for Kopernicus Squad for KSP imkSushi's old thread: pozine's old thread: This mod is licensed by the Creative Commons Attribution 4.0 International - http://creativecommons.org/licenses/by/4.0/

I have TUFX, PlanetShine, Scatterer, EVE, RSSVE and GGE installed as visual mods. First of all, I had this problem with clouds not working so I first reinstalled Scatterer and EVE, after that it did not get fixed, but the shadows on all the gas giants were fine. Then I reinstalled RSSVE and the clouds were back and working, but now for some reason the shadows on all the gas giants are very sharp and doesn't look right. Please help! Images:

After a couple days of research and understanding the Real Solar System files, I've finally figured out how to change the date in RSS DateTimeFormatter. It's not too complicated and just takes a few minutes. The first thing you need to do is go into your Kerbal Space Program file (with your GameData and whatnot) and type into your file explorer's search bar, "persistent.sfs". Depending on how many saved games you already have, there will be the same number of these "persistent" files. Choose any because what this will do is going to affect all your saved games (if you don't want your other games to have a different date, take them out of the KSP saves folder). Once the .sfs file is opened, you need to scroll down until you see "UT" which itself is under "FLIGHTSTATE". Next to UT is a set of numbers. For those that don't understand what these numbers mean, they represent the number of seconds since the start of the game. This is what you need to change to have the save game set to a different date. Now you must figure out the number to replace the current one. Go to this website and, depending if your desired is before or after, put 1/1/1951 (the default date in Real Solar System) in Start Date or End Date. Then put the desired date in the opposite date section. For an example, I will use the beginning of 1942 as the replacement date. Click Calculate Duration and look for the large bolded text saying the number of days in between (3,287 days as per the example year). Now it's time for some quick maths. Multiply the number of days by 4 (as Kerbin days are 1/4 of an Earth day) then multiply that number by 6 and multiply again by 3,600 (found that out here). You now have your replacement number. Go back to your persistent.sfs file and delete the number already in UT and type in the new calculated number (of course not with commas). If your wanted date comes before 1/1/1951, then put a dash in front of it to make it a negative number. When done, save the file and close out of it. There you go. But before you go back in the game, there's one more thing you will need to do. What this is going to do will just make the planets and moons correctly aligned accurately according to the new date. Go into the Real Solar System file that you have in GameData and look for "RSSKopernicusSettings.cfg". Within it, scroll down (but not really because it's close to the top) until you see "Epoch". It will also have a set of numbers next to it. Epoch, in astronomical terms, is a fixed date that is relative to planetary/stellar measurements. The number you will see (-31542641.784) is the epoch for midnight, January 1, 1951. You need to replace this epoch with another that is accurate to your new in-game date. Use this website to find the epoch by typing in the date that you had replace the default earlier (just type in 12:00 A.M. for the time and keep it at GMT (Greenwich Mean Time) as that it the time zone RSS uses) and clicking Human Date to Timestamp. Your epoch replacement (-883612800 for the 1942 example) will be next to Epoch Timestamp. Copy the number (if it has a dash to make it a negative number, keep this) and go back to RSSKopernicusSettings.cfg. Select the epoch number and then paste (Ctrl and V at the same time) to replace it while also deleting it at the same time. Save the .cfg file and close out of it. You've now fully completed the new in-game RSS DateTimeFormatter date. Go to your KSP save game that has the changed date and you can see now that the date is, in fact, changed. Head into the Tracking Station and look to see the different planet alignments. Unless you have a clever eye, and you probably won't be able to tell anyway, but the planets really have moved since you changed the epoch.

I had found this screenshot in my folders and was wondering what this object even is, if it even exists. (FYI the installation this screenshot was from is deleted)

Hey, First of all, apologies if I posted it in the wrong section in this forum. So, I was playing the game today after a successful install of RealSolarSystem, Realism Overhaul, and whole plethora of other mods. But when I try to make my own probe, I noticed that the 'stock' solar panels were bugged and were misbehaving? the panels were fully extended the moment I took the panels out from the part selector and won't close unless I pressed extend and retract. At first, i thought this was "Oh, it is just mods being mods." as I had known that some of my mods were Solar Panels or Electricity related mods, like Near Future Solar, etc. So I retracted the panels just in case if it got extended at flight, in which would destroy the panels if it got fully extended mid flight. But guess what? The panels were extended mid flight, soon after I left the VAB for the launchpad regardless of whether I retracted the panels in the VAB or not. Which surely resulted in my solar panel's destruction when I opened the fairing. I tested the panels on a probe and i noticed that it wasn't making any power, despite it was fully opened and the panels instantly closed itself when i pressed 'Extend panel' before the proper extending animation played out and the panels were 'trully' extended. I suspect that the game thinks the panels were fully retracted, but in reality, the panels were opened. I was quite frustrated as my options were limited to non-stock solar panels, which were extremely oversized for my probes. Is there any solutions to this before i resort to reinstalling all the mods? I have made a lot of changes to the RSS configs (I added some custom launch sites and ground stations for Real Antennas mod and that's probably all), and installed tonnes of mods. it would be tedious to re-apply those configs again if i were to reinstall all the mods. I have tried reinstalling Kopernicus and it fixes nothing. What could be the cause of this bug? Here is a brief video proof of the bug happening, feel free to let me know if need more videos of the bug happening : And here is the log of that particular session (The video file above were recorded and saved on 8:51:27 AM [08:51:27 - 24 hour format]) : https://drive.google.com/file/d/1pjUOpwUngeluZI8kb4ma5spKUL0mDoWm/view?usp=sharing My mod (GameData) folder : https://imgur.com/a/P6mMRJR Lastly, thanks for the attention. Apologies if there are grammatical errors in my topic, I'm not a native English speaker whatsoever.

This is another mission done quite a while ago, not so much time after heat shield magic wings were indepedantly discovered by several players. In terms of mission finish time, it was the first craft of its kind to complete a full mission of any sort, as well as the first EC powered ssto. These kind of SSTOs are remarkably efficient in terms of getting into orbit, reaching at least 30% of effective payload fraction launching from Earth with a still acceptable thrust to weight ratio, and without any crazy mass optimisations. They are also ideal for tackling atmospheric bodies with high dv needs and mid to moderately high gravity levels. With this kind of basic setup, stock super-kerbins, super-jools, real scale Earth sized planets lacking oxygen, real scaled superearths and some real scale gas giants(fine for at least the dv requirements of Saturn) and super-scale terrestrial planets, at leasts up to 10xearth, can be orbited single staged, with various level of difficulty.

I recently edited out the clips of a mission done one and a half years ago. While there are claims of fully reusable lunar missions done with stock parts predating this mission way back, they relied on splitting the timeline during stage separation, so in their respective timeline, either the booster crashes, or the payload never reaches orbit. To my knowledge, this was the first stock craft, based on mission finish date, able to finish a fully reusable mission beyond LEO in RSS(there is a interplanetary SSTO launched earlier, but I only managed to finish the mission after this was done due to a mission extension and some complications with the Kraken). It was based off of some earlier sstos, being scaled down to basically just be able to get up to leo with the lunar lander., so payload fraction wasn't high, just below 2%(at least 4.2% can be attained on large, stock part conventional wing sstos in RSS). The three solar panels were clipped into two, solar panels don't occlude each other from sunlight in this scenario. As for the mass, this mission was done before I along with others discovered magic wings, if this was done now, the mass would be way lower, probably around 2t, which I might explore in the future. Magic or conventional, there is a lot of design space and optimisation to explore with stock SSTOs in RSS.

What If #1 Well I thought of this, and decided to try this out in KSP 1.11, to see if this worked, I basically launched to LEO a Buran shuttle but instead of using the four Zenit rockets I used four Falcon 9 boosters on it, so to improve it's reusability, I launched a Almaz station in the Buran shuttle, and had it successfully deployed it a 300 km orbit and the Buran (sort of) made it back to earth, I know this will sound like it kills the point, but the boosters were expended, because I was not sure if I would actually make it or not, (I just needed a short burn from the Buran's OMS engines); so hypothetically I think it should work next time with a recovery. Does anyone have any other ideas to try out in Realism Overhaul, I might try a US shuttle launch next with two falcons strapped on the ET instead of the SRMs The main mods I used were Realism Overhaul with dependencies, RSS, RSSVE, RN Soviet Stations, and Buran-Energia, with Raiz Space's Configs, KK's launchers SpaceX pack Screenshots:

my rss won't load because [LOG 19:21:57.291] Load(Texture): RSS-Textures/ArielBiomes [LOG 19:21:57.691] Load(Texture): RSS-Textures/ArielColor [LOG 19:21:57.747] Load(Texture): RSS-Textures/ArielHeight [LOG 19:21:58.436] Load(Texture): RSS-Textures/Ariel_NRM [LOG 19:21:58.636] Load(Texture): RSS-Textures/CallistoBiomes [LOG 19:21:58.821] Load(Texture): RSS-Textures/CallistoColor [LOG 19:21:59.023] Load(Texture): RSS-Textures/CallistoHeight [WRN 19:21:59.087] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\CallistoHeight.dds' [LOG 19:21:59.090] Load(Texture): RSS-Textures/Callisto_NRM [LOG 19:21:59.273] Load(Texture): RSS-Textures/CeresBiomes [LOG 19:21:59.422] Load(Texture): RSS-Textures/CeresColor [LOG 19:21:59.588] Load(Texture): RSS-Textures/CeresHeight [LOG 19:22:00.283] Load(Texture): RSS-Textures/Ceres_NRM [LOG 19:22:00.531] Load(Texture): RSS-Textures/CharonBiomes [LOG 19:22:00.661] Load(Texture): RSS-Textures/CharonColor [LOG 19:22:01.430] Load(Texture): RSS-Textures/CharonHeight [WRN 19:22:01.694] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\CharonHeight.dds' [LOG 19:22:01.697] Load(Texture): RSS-Textures/Charon_NRM [LOG 19:22:02.351] Load(Texture): RSS-Textures/DeimosBiomes [LOG 19:22:02.465] Load(Texture): RSS-Textures/DeimosColor [LOG 19:22:02.647] Load(Texture): RSS-Textures/DeimosHeight [WRN 19:22:02.667] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\DeimosHeight.dds' [LOG 19:22:02.670] Load(Texture): RSS-Textures/Deimos_NRM [LOG 19:22:02.734] Load(Texture): RSS-Textures/DioneBiomes [LOG 19:22:02.853] Load(Texture): RSS-Textures/DioneColor [LOG 19:22:03.272] Load(Texture): RSS-Textures/EarthBiomes [LOG 19:22:03.662] Load(Texture): RSS-Textures/EarthColor [LOG 19:22:04.443] Load(Texture): RSS-Textures/EarthHeight [WRN 19:22:04.906] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\EarthHeight.dds' [LOG 19:22:04.909] Load(Texture): RSS-Textures/EarthSurface [LOG 19:22:05.721] Load(Texture): RSS-Textures/Earth_NRM [LOG 19:22:06.362] Load(Texture): RSS-Textures/EnceladusBiomes [LOG 19:22:06.455] Load(Texture): RSS-Textures/EnceladusColor [LOG 19:22:06.986] Load(Texture): RSS-Textures/EuropaBiomes [LOG 19:22:07.101] Load(Texture): RSS-Textures/EuropaColor [LOG 19:22:07.913] Load(Texture): RSS-Textures/EuropaHeight [WRN 19:22:08.051] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\EuropaHeight.dds' [LOG 19:22:08.055] Load(Texture): RSS-Textures/Europa_NRM [LOG 19:22:09.065] Load(Texture): RSS-Textures/Flat_NRM [LOG 19:22:09.092] Load(Texture): RSS-Textures/GanymedeBiomes [LOG 19:22:09.202] Load(Texture): RSS-Textures/GanymedeColor [LOG 19:22:09.375] Load(Texture): RSS-Textures/GanymedeHeight [WRN 19:22:09.430] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\GanymedeHeight.dds' [LOG 19:22:09.433] Load(Texture): RSS-Textures/Ganymede_NRM [LOG 19:22:09.636] Load(Texture): RSS-Textures/IapetusBiomes [LOG 19:22:09.956] Load(Texture): RSS-Textures/IapetusColor [LOG 19:22:10.083] Load(Texture): RSS-Textures/IoBiomes [LOG 19:22:10.211] Load(Texture): RSS-Textures/IoColor [LOG 19:22:10.528] Load(Texture): RSS-Textures/IoHeight [WRN 19:22:10.563] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\IoHeight.dds' [LOG 19:22:10.566] Load(Texture): RSS-Textures/Io_NRM [LOG 19:22:11.150] Load(Texture): RSS-Textures/JupiterBiomes [LOG 19:22:11.261] Load(Texture): RSS-Textures/JupiterColor [LOG 19:22:11.779] Load(Texture): RSS-Textures/MarsBiomes [LOG 19:22:11.875] Load(Texture): RSS-Textures/MarsColor [LOG 19:22:12.264] Load(Texture): RSS-Textures/MarsHeight [WRN 19:22:12.499] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\MarsHeight.dds' [LOG 19:22:12.504] Load(Texture): RSS-Textures/Mars_NRM [LOG 19:22:13.106] Load(Texture): RSS-Textures/MercuryBiomes [LOG 19:22:13.239] Load(Texture): RSS-Textures/MercuryColor [LOG 19:22:13.466] Load(Texture): RSS-Textures/MercuryHeight [WRN 19:22:13.500] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\MercuryHeight.dds' [LOG 19:22:13.503] Load(Texture): RSS-Textures/Mercury_NRM [LOG 19:22:13.706] Load(Texture): RSS-Textures/MimasBiomes [LOG 19:22:14.061] Load(Texture): RSS-Textures/MimasColor [LOG 19:22:14.181] Load(Texture): RSS-Textures/MirandaBiomes [LOG 19:22:14.592] Load(Texture): RSS-Textures/MirandaColor [LOG 19:22:14.641] Load(Texture): RSS-Textures/MirandaHeight [LOG 19:22:15.529] Load(Texture): RSS-Textures/Miranda_NRM [LOG 19:22:15.597] Load(Texture): RSS-Textures/MoonBiomes [LOG 19:22:15.748] Load(Texture): RSS-Textures/MoonColor [LOG 19:22:16.380] Load(Texture): RSS-Textures/MoonHeight [WRN 19:22:16.513] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\MoonHeight.dds' [LOG 19:22:16.517] Load(Texture): RSS-Textures/Moon_NRM [LOG 19:22:17.155] Load(Texture): RSS-Textures/NeptuneBiomes [LOG 19:22:17.279] Load(Texture): RSS-Textures/NeptuneColor [LOG 19:22:17.403] Load(Texture): RSS-Textures/OberonBiomes [LOG 19:22:17.562] Load(Texture): RSS-Textures/OberonColor [LOG 19:22:17.622] Load(Texture): RSS-Textures/OberonHeight [LOG 19:22:17.949] Load(Texture): RSS-Textures/Oberon_NRM [LOG 19:22:18.021] Load(Texture): RSS-Textures/PhobosBiomes [LOG 19:22:18.069] Load(Texture): RSS-Textures/PhobosColor [LOG 19:22:18.108] Load(Texture): RSS-Textures/PhobosHeight [WRN 19:22:18.141] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\PhobosHeight.dds' [LOG 19:22:18.142] Load(Texture): RSS-Textures/Phobos_NRM [LOG 19:22:18.196] Load(Texture): RSS-Textures/PlutoBiomes [LOG 19:22:18.237] Load(Texture): RSS-Textures/PlutoColor [LOG 19:22:18.844] Load(Texture): RSS-Textures/PlutoHeight [WRN 19:22:19.112] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\PlutoHeight.dds' [LOG 19:22:19.116] Load(Texture): RSS-Textures/Pluto_NRM [LOG 19:22:19.710] Load(Texture): RSS-Textures/RheaBiomes [LOG 19:22:20.056] Load(Texture): RSS-Textures/RheaColor [LOG 19:22:20.326] Load(Texture): RSS-Textures/SaturnBiomes [LOG 19:22:20.439] Load(Texture): RSS-Textures/SaturnColor [LOG 19:22:21.056] Load(Texture): RSS-Textures/SaturnRing [LOG 19:22:21.133] Load(Texture): RSS-Textures/TethysBiomes [LOG 19:22:21.277] Load(Texture): RSS-Textures/TethysColor [LOG 19:22:21.540] Load(Texture): RSS-Textures/TitanBiomes [LOG 19:22:21.726] Load(Texture): RSS-Textures/TitanColor [LOG 19:22:22.527] Load(Texture): RSS-Textures/TitanHeight [WRN 19:22:23.069] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\TitanHeight.dds' [LOG 19:22:23.075] Load(Texture): RSS-Textures/TitaniaBiomes [LOG 19:22:23.114] Load(Texture): RSS-Textures/TitaniaColor [LOG 19:22:23.139] Load(Texture): RSS-Textures/TitaniaHeight [LOG 19:22:23.343] Load(Texture): RSS-Textures/Titania_NRM [LOG 19:22:23.372] Load(Texture): RSS-Textures/Titan_NRM [LOG 19:22:24.232] Load(Texture): RSS-Textures/TritonBiomes [LOG 19:22:24.328] Load(Texture): RSS-Textures/TritonColor [LOG 19:22:24.440] Load(Texture): RSS-Textures/UmbrielBiomes [LOG 19:22:24.496] Load(Texture): RSS-Textures/UmbrielColor [LOG 19:22:24.510] Load(Texture): RSS-Textures/UmbrielHeight [LOG 19:22:24.601] Load(Texture): RSS-Textures/Umbriel_NRM [LOG 19:22:24.626] Load(Texture): RSS-Textures/UranusBiomes [LOG 19:22:24.718] Load(Texture): RSS-Textures/UranusColor [LOG 19:22:25.165] Load(Texture): RSS-Textures/VenusBiomes [LOG 19:22:25.400] Load(Texture): RSS-Textures/VenusColor [LOG 19:22:25.703] Load(Texture): RSS-Textures/VenusHeight [WRN 19:22:25.803] Texture load error in 'D:\KERBAL BG\Kerbal Space Program Breaking Ground\GameData\RSS-Textures\VenusHeight.dds' [LOG 19:22:25.807] Load(Texture): RSS-Textures/Venus_NRM [LOG 19:22:25.937] Load(Texture): RSS-Textures/VestaBiomes [LOG 19:22:26.293] Load(Texture): RSS-Textures/VestaColor [LOG 19:22:26.340] Load(Texture): RSS-Textures/VestaHeight [LOG 19:22:27.021] Load(Texture): RSS-Textures/Vesta_NRM Well, some of the dds. files work, like Ariel and Oberon, but why won't the others? Well, some of the dds. files work, like Ariel and Oberon, but why won't the others?

I wrote a tutorial for running an Earth-Moon Shamrock Cycler using Kerbal Space. I used the RealSolarSystem package so this really is Earth-Moon, not Kerbin-Mun. Here are links to the Wiki page and video tutorial. I wrote this because when I become a space tourist I want to visit the Moon in the comfort of a big cycler cruise ship. Yes, I'm willing to wait a few years. Tutorial: Earth-Moon Aldrin Cycler - Kerbal Space Program Wiki youtube KSP Earth-Moon Aldrin Cycler tutorial The tutorials are based on the Shamrock cycler from Aldrin's recent paper: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160004674.pdf

Hello everyone, I tried to make a rocket to reach orbit or sub-orbit (at least) in RSS but couldn't. So I just downloaded a Falcon 9 Dragon from somebody (I don't remember) and loaded it up. Liftoff starts well. After 2 and a half minutes (I think so) stage 1 were seperated But then, something went wrong. One of the tanks exploded a little which caused the whole ship to loose control. This forced me to abort the mission. I fired up the draco engines to reduce the speed of the capsule. Again, something went horribly wrong. The draco engines ran out of fuel. And they are no parachutes on the dragon. So there is only one option : doing an EVA ^ Image above shows dragon capsule exploded (right) So I (no, Jeb) prepared for the worst. ^ Jeb was falling down very fast Jeb plummeted to the ground at approx 50 m/s Luckily I reverted the flight to the beginning, and Jeb was safe.

Hello. I would like to ask if there's a calculator or a spreadsheet that can calculate all the things Alexmoon's Calculator does but for the RealSolarSystem. I would like a spreadsheet or an online tool, please. Because the calculators for KSP (e.g. Alexmoon's, Olex, etc) only work for stock KSP. I've tried abrhmsanchez's one but he doesn't have the Moon. Also, I would like to have the real names of the objects. Also, I would like it to have custom values. E.g. radius, gravity, possibility to add new bodies, in short, that you can modify everything in it. If someone could do this for me, I would be eternally thankful to that person or people. Hope you can do this for me. Or direct me to something that does what I'm asking for. Thanks in advance, Nexus24680

Hey guys, Since yesterday I have been having issues with my KSP installation. First of all, I play RealismOverhaul, Real Solar System, Realistic Progression Zero, RemoteTech, and some other mods. (about 43 in total) The problem started yesterday, and was caused by, or at least coincided with, me installing the newest RealismOverhaul-Master from Github. When I use Mechjeb's auto-ascent to launch from Kourou (you know, the equatorial South-American base) into the Moon's plane, MJ rolls the rocket (even though 'Force Roll' is disabled) after launch, and then proceeds to launch polar. Mechjeb's Auto-Ascent window shows the Moon's inclination (28.xxx degrees), and the launch is timed perfectly for the lunar plane, however Mechjeb is about 90 degrees off when it comes to the heading, and proceeds to perform a perfectly normal launch - only into a polar orbit, instead of one with the inclination of the Moon. Mechjeb's ascent is configured like this: Orbit: 99999km Turn Start Velocity: 80m/s Turn End Altitude: 140km Ascent profile: 45% Before launch, I go into map-view, select the Moon as target, then select 'Launch into Target plane' in Mechjeb. The weirdest thing? This works perfectly when launching from KSC. It also works fine from Kourou when I am trying in Sandbox mode. Only when I launch in Career mode from Kourou, does this faulty behavior show. This is in Kubuntu 14.04, x64. i7 4790k, 16 GB RAM, starting the 64-bit version via launch script. Here is the link to my player.log: https://www.dropbox.com/s/3akiwqgudbp2eos/Player.log?dl=1 This is the link to the craft I am using: https://www.dropbox.com/s/hqldj3xn38akuxd/LunSat%20I.craft?dl=1 It is a bit overpowered, because it is supposed to do: a) Lunar Flyby b) Lunar Orbit c) specific Lunar polar orbit d) second specific Lunar orbit and e) impact on the surface. I am sure I am doing something wrong somewhere (PEBKAC), and that it's not some bug. I have completely removed the KSP folder, performed a fresh install, made several copies of the folder to try different methods to troubleshoot this, but frankly, I am at a loss.. Thanks all for any help you can provide! sackfalte EDIT: I was informed that it's better to post in the dedicated Mechjeb support thread, so that's what I am going to do.