NotTheRealRMS

In my opinion this series of optional contracts of the X-Planes program should give a much better reward. Over 30k funds had to be spent expanding the maximum wingspan the hangar can build aircrafts with. This design had to use relatively expensive to tool aluminum stringer tanks, but because currently I'm getting far more unlock credits than funds each day I still tooled it, and it is flimsy, any high G turns will break the 0.1 mass-strength multiplier wings and 0.2 control surfaces another risky move to ensure the mass of this very Kerbal aircraft for RO standards doesn't get too high for it to reach that ridiculously high altitude for a mid 1950s jet engine. I'm sure there are more elegant solutions to achieve this within the 40m max width of the starting hangar than to attach an overpowered at sea level jet engine (over 1.7 TWR) and huge wings to a X-1 cockpit, or maybe wait until later, better jet and turbofan engines get unlocked, but in mid 1958 the X-planes deadline will happen so I'm trying to cram as many optional achievements into it while there is time in this career mode. And that is not even the "real" mission. It took over 1 hour of in game time to climb to 30km and return to land, with difficulty, on the runway: you have to keep decreasing climb speed as you get higher, over and over to not lose so much speed you can't level flight at 30km, at the last leg it was limping at only 3m/s climb speed. I can't even believe any real X-planes program did a manned aircraft with a jet engine that beat that altitude record, definitively not in 1956. There were also things that'd make it even more frustrating but were not necessary, such as reducing the wings mass-strength ratio so much that they break at 4x time warp if it was still too heavy to get that high up. This better be the last of these stratospheric subsonic flight missions in RP-1, no way I'm trying another one that wants me to "reach level flight with a jet X-Plane at 35km for 5 minutes" or something like that. PS: It really is tangential to the rest of the program, which is focused on designing ever faster, heat-resistant experimental aircraft to go ever higher up and eventually reach outer space as the final goal, instead of this, which is useless for anything else than its intended optional missions. I suppose you could use it as a basis for one that can somehow climb a bit past 40km to gather science at high altitude, but why?

Version 0.4.0.1: https://drive.google.com/open?id=1mOLcnGyXYqOIdBj3sN9jGznbaPwNcHUS A series of small improvements and fixes. There were a few gaps in making patches for Kerbal Reusability Expansion to work better with RSS and FAR such as the mass and cost of the grid fins and lack of FAR support in their part configs, which I found necessary after losing reusable stages using them as control surfaces when trying to land them all the time. Mostly solved now. The tanks of the lander capsules from SSTU are no longer stuck to a very limited set of fuel types. Just missed that from never having used them a lot before. Now onto Science Fiction-grade tech, probably(whether such process could be adapted with current technology to work in space or not is beyond my knowledge), to complement ISRU capabilities, a Steam Methane Reformer unit was added. Combined with a Fischer-Tropsch reaction, it adds a new method to produce synthetic kerosene, from methane and water. It's also useful for producing hydrogen, though many RealISRU liquefaction arrays will be needed in any base using it to avoid a serious bottleneck in the cooling of hydrogen to liquid hydrogen. In addition to that, all parts from RealISRU that can adsorb gasses from an atmosphere now support hydrogen and methane as well. Something like simultaneous Aerobraking and ISRU in Jupiter still is likely folly unless perhaps it's a manned vessel using the VASIMR which does not require liquid hydrogen or methane so it can just dip in, scoop hydrogen to refuel the tanks, burn prograde to a stable orbit again and proceed with its mission. However, realistic VASIMR is really weak in thrust for a manned mission. Orbital stations that temporarily dip in Jupiter's upper atmosphere to scoop hydrogen, then cool it into liquid hydrogen are possible too, but it wouldn't be easy to pull that. And besides some small fixes, that is all for now.

Did anyone try RSS with this unofficial 1.4.5 recompile for FAR ? Most importantly, is there any real, objective improvement to the base game that justifies updating from 1.3.1 to 1.4.5 for anyone completely uninterested in Making History? Changes like 2-5 FPS more on average for surface ISRU bases, reduced memory leaks or better OpenGL rendering support. Depending on the answer to the latter, for those who consider RSS and FAR indispensable, it might be better to stick to 1.3.1, at least until both are officially updated.

Version 0.4: https://drive.google.com/open?id=1DGJ2pludLBIbKQFSInvtr7RILbyPieJL A substantial update again. What began as just some Quality of Life changes taking into account the very important detail that KAS pipes do not generate crossfeed, so ISRU bases built using them can be tricky unless some key gasses for ISRU ignore crossfeed, expanded into a little more than that. Aerozine50/NTO ISRU is possible now, but it is tricky because it needs Nitrogen, which means that only in Titan 100% ISRU production of Hydrazine, UDMH and NTO is possible. Furthermore, because it is required for NTO production, Hydrogen Peroxide(HTP) is in too, and therefore, having one fuel type available just for that? Nah, so, with no modelling skills meaning all that can be done is to re-scale SSTU models and improvise, this update brings in, besides several other fancy, near future(sort of) combustion engines, a Sea Dragon inspired booster burning Kerosene and HTP rather than Liquid Oxygen, for a simple reason: while such combination has worse specific impulse, it allows, in addition to some arguably Hard Science Fiction detail in this same fictional engine(it's placed in the final tech node for combustion rockets, so it's not such a stretch), for the design of a Sea Dragon with only a fraction of the original's diameter thanks to such mixture being much denser than Kerolox, and to an upper stage on Methane/LOx in a small part as well. Besides it there were other additions, but in any case, because bigger is better, here a loose try at a "replica" of the Sea Dragon "small" enough for its launch from a conventional launchpad to be practical: The real deal in these new fictional engines is that all of them were designed for reusable launch vehicles. This example sketch design for 550 tons to LEO is sub-optimal: an optimal Sea Leviathan would be fully reusable and that engine has more than enough power to lift maybe more than 1,000 tons to LEO and still have a reusable first stage, if not all stages. Wish I knew how to do models and textures to really make the concept of rocket engines made of diamonds shine, but I don't. Furthermore, this update includes some small adjustments to make Kerbal Reusability Expansion work better with the Real Solar System, and some beefed resistojet RCS to also help with reusable stages, if the same won't drain all their batteries before touchdown, because reckless use of resistojets powerful enough for RCS causes that, and putting huge nuclear reactors to supply them with enough power at all times is impractical for anything besides interplanetary manned missions with resistojets instead of NTRs(worse thrust due to reactor mass but less radioactive and better Isp), provided they can be lifted off to LEO by something about as big as a Sea Dragon. And of course a Kerosene/HTP setting in SSTU for the same engine, in addition to Nitrogen tanks if for some reason making Hydrazine/etc in the Moon through ISRU and Nitrogen brought from Earth is a space program strategic objective.

Version 0.3.9.1: https://drive.google.com/open?id=1sattXadYjtk3Yla1feovgj2dL2dLGZEt The custom MM patches added for USI engines were done with a few typos and other small but consequential mistakes. Now they should all work properly, and RealPlume fixes again, I'm really inept at getting those plumes done right, heh. To make this tiny update a tad better, the RO patches for Kerbal Attachment System and Inventory system were adapted because the default masses aren't very realistic, in most cases by being too heavy. That's all for the moment. Reasons to not do much more include but are not limited to playing KSP less often in general and this being mod then play rather than done for its own sake. For now I did not have another "I really need to improve this" moment -- the rescale and patches for USI parts were the most recent of such moments in this project's development.

Version 0.3.9: https://drive.google.com/open?id=1lb2EkT4O8d8y2Nwr8_0VxqgRbtOYjb_X Finally, the entirety of the USI Kolonization suite gained the scale it deserves for the Real Solar System. Every part was rescaled from 64% Stock to 100% Real. While the mostly generic mass adjustments may not be perfect, they are completely functional. In the absence of anything real to compare most of this stuff with, they will have to do. With the exception of the Kontainers, which can be used with SSTU through one of the patches in SSTU-OptionalPatches, almost every USI part that comes together with MKS got the RSS treatment. Some of the more noteworthy changes in this include the Microwave Power Transceivers from MKS having their range extended to hundreds of kilometers and a larger version of them with enough range for planetary power grids connected through relays in stationary orbits. The two rovers from USI(Akita and Karibou Expedition Rover) likewise are rescaled. The Skycrane uses liquid methane, with upgrades allowing a switch to hydrogen or even kerosene nuclear electric resistojets, for the latter, that patch to microwave power transceivers can be put to good use. The previous resistojets using Stock models, as long as the magnitudes increase of the range of those USI Modules for microwave power transmission don't bring unexpected bugs, can be used for Single Stage to Orbit. Also of some interest would be the Methane SABRE engine, which is a smaller, somewhat less efficient but with better TWR(as expected when comparing a methane with a hydrogen engine) counterpart to the real Skylon's SABRE, which also includes an Advanced Jet Engine patch carefully copied then adapted from the one for B9 Aerospace's SABRE-S. The larger inflatable storage module from MKS now uses SSTU modules too. In fact, most Firespitter Fuel Switch modules in MKS parts were replaced with the generally more flexible and easier to edit MM patches for, except for not supporting tank reconfiguration during flight, SSTU alternatives. Besides perhaps doing some custom patches for the GoingUnderground mod once and if it gets done, this mostly wraps up the MM patches for Colonization components. Now, getting a generic convert every LF/Ox to Kerolox with close enough to real fuel ratios patch done was one thing, but ultimately, it would be a waste to have a generic patch that converts everything to use real fuels instead of generic Liquid Fuel if a complementary and optional RealFuels patch isn't added as well to take advantage of it, yet stuff like defining every fuel mixture precisely sounds like the difference between defining anything crafted from wood on abstracted yet sufficiently varied levels of resistance vs. defining the same like Dwarf Fortress to me. It's not the arguably negligible difference between NTO and MON3 as storable oxidizers, but rather the challenging realism on rocket engines that would require too much reinventing of the wheel to be done without RealFuels, like ullage and limited ignitions, the reason I'm considering to eventually try implementing such a patch. Ultimately, in my opinion, there is a certain threshold of realism past which Orbiter Space Simulator, besides the lack of simple ways to craft custom rockets, will always be a better option than any realism mod for this game could ever manage to be. Only realism and maybe some inert modules in part configs from patches that add RemoteTech modules without checking whether it's installed or not. This is most likely playable without RemoteTech, but there are no changes made to stock commnet to accommodate the larger scale of RSS, unless RSS itself has patches for commnet. I never tried commnet so I'm not sure if this would cause issues for unmanned flights.

Version 0.3.8: https://drive.google.com/open?id=1zhbTzqEeUrlaE_ySYNnmB8-lHn_RCUDE A more significant update but perhaps not really big. Just fixed one critical bug involving the Raptor methane engines and Near Future Launch Vehicle model swaps, a few other minor bugfixes, and most importantly, fixes and improvements to existing contracts. More important are the new contracts, both unmanned and manned, for Ceres, Vesta and the five moons of Uranus added in the latest Real Solar System, plus more solar system colonization contracts for the late game, including building a permanent base to extract water and make rocket fuel in the form of liquid hydrogen and oxygen in Ceres(RealISRU is needed for this contract), a permanent manned research base with closed loop life support in Vesta because there would be a point to researching a protoplanet in-loco should technology ever make such a thing feasible, and also contracts for permanent bases in either Triton, Pluto or both that can produce a surplus of life support, rocket and nuclear fuel to resupply future interstellar colony ships. If you're in need of parts for life support, both USI Kolonization and Civilian Population, in addition to the larger SSTU centrifuges which would probably be inconvenient for a surface base anywhere except perhaps for Phobos, Deimos or a random asteroid, feature parts to create artificial biospheres with food production(for water and oxygen any planet or moon with Hydrates or Water is enough, just bring some ice drills) and while the former is focused on USI-LS it nonetheless provides decent enough support for TAC Life Support. PS: I'm biased against Mars and consider the dubious concept of its colonization,at least in the manned sense of the word, overrated techno-utopian blindness. Any contracts that may be added for it will follow the same theme of the existing "0.01% mega billionaire wants to live in a luxurious Martian manor with a closed loop life support system" one. Check your RemoteTech settings. Whatever the cause, this mod probably isn't the reason for such issue, with one exception: soil sample return capsules bypassed RemoteTech restrictions. Not much more to tell with such extremely limited information.

Version 0.3.71: https://drive.google.com/open?id=1qTmPpB1cRSrFnFekDOHnopyaCxJLvFtm Is it in sandbox? There is an upgrade near the end of the tech tree called "Pre-Sentient Algorithms" for procedural unmanned command modules that disables the light speed delay in RemoteTech. All upgrades are enabled by default in Sandbox, so, for that purpose, it's necessary to disable such upgrade. This is based upon the pricing for procedural wings in Realistic Progression Zero, pretty much the same, no changes, and AFAIK such pricing wasn't changed in RP-0 recently either. Finally, the upgrades that give the wings enough heat resistance for atmospheric reentry will increase their cost. Disabling such upgrades when flying subsonic or supersonic planes will lower the cost and in the case of subsonic wings, their dry mass. Now, when it comes to updating to a new version, reading the change logs of the latest patches for KSP and knowing a botnet was added then recently removed from it only due to backlash, I don't really expect any patch that will truly improve the game after version 1.3.1. Besides, the latest official version of Ferram Aerospace Research still supports only KSP 1.3.1. So, a minor bugfix update because of a months long hiatus on anything KSP-related, partly due to getting tired of it and partly due to very pessimistic expectations on what T2 would do. RedShell is not as big of a deal as it would be going Steam-exclusive and forcing DRM in a future patch, trying to shove a real money store in a single player game or paid mods on Steam workshop followed by mass C&D of the free modding community, but it is one first small step towards the direction where such changes are made, or perhaps it was just a test to check how much they could get away with, if so, hopefully they got the message and won't keep trying. Time will tell. Again, this is the "I just got back to doing this" kind of update, so don't expect much changes compared to the previous version, except for a very important bugfix for the procedural SRBs with upgrades from SSTU. This might be updated for compatibility with SSTU latest version if necessary once FAR gets an update to the latest KSP version. The bundled Upgrade Editor also got a minor fix to one of its MM patches so max segment upgrades for SSTU procedural SRBs will be ignored by it, but that is not important enough to be worth updating its specific thread about.

Version 0.3.7: https://drive.google.com/open?id=1iY7tFV7z5NaKU5G4z0hzSWiyQ3MqCg4R Yet more bug fixes. I tried to fix all reported bugs mentioned above but some of the plumes may still be glitched and something else could have been missed. As for the Upgrade Editor, unfortunately the way it stands now is probably the best I can do. It's likely I won't do much more than recompiling it whenever a new KSP version is released and most mods this one depends upon are already updated for it. There were some other changes besides trying to get those issues solved. Testing in a late game, finally realized that module upper stages lacked the "Artificial Intelligence" upgrade for RemoteTech which puts an end to light speed lag difficulties and gives a purpose to the otherwise completely empty Artificial Intelligence tech tree node inherited from CTT. Other fixes include scale fixes to some of the very, very large radiators scaled up for nuclear electric propulsion or powerful laser beams for laser propelled spacecraft if there is any mod featuring them. Such a laser would also be useful to melt even the biggest spacecraft because any laser beam powerful enough to propel a photon sail also is an extremely powerful weapon, same on any torchship grade propulsion. There was a very important rebalance for heavier dry density tank types in SSTU to ensure they won't be excessively costly and one more tech tree rearrangement from "Meta-Materials" to what hopefully will become full of custom parts based upon the waterskiing spacecraft concept, but I haven't found many yet and given that such stuff would have to be assembled in orbit or in some cases even constructed in-orbit to work, it probably won't exist. As a proof of concept, a copy of the procedural structure from ProceduralParts was made, which config makes it unable to withstand more than 0.375 atm (Extraplanetary Launchpads are required to use it), but its density is incredibly small, likewise the advanced "balloon" tanks in SSTU are supposed to only be reusable in negligible atmospheric pressures and as tension members, but there is no way to enforce that in-game and it's not really worth coding a plugin for. Without the dangers of radiation poisoning there aren't many applications for such stuff(like a super-lightweight cable keeping an unshielded and very powerful nuclear reactor a very long distance away from the crew), and the only mod that simulates it besides Kerbalism(which I'm not particularly interested at), Radioactivity, seems to be in a hiatus that may be permanent. But whatever, waterskiing spacecraft look unique and cool and there is that. Finally, after redoing some maths the almost and practically closed loop life support systems added for TAC Life Support in the two biggest SSTU centrifuge habitats now are effectively closed loop, for very, very late game interstellar generation ship designs and alike. Some water will have to be converted into O2 once every year/decade though because of the way real human metabolism works. *Edit: On the Nanotechnology-grade diameters, I fixed that issue in the proper way: the minimum got increased to 0.05m for convenience reasons mostly, while still being less than the starting 0.1m minimum so the upgrade that changes it has a reason to exist. 0.05m because the "diameterIncrement" setting on SSTU procedurals cannot be larger than 5x such minimum for it to be reached instead of 0 diameter in the Editor when setting up very small parts and a 0.05 diameter increment(meaning the part would only be increased by 0.1m per click max) would make setting up large diameter parts after applying the nanotech upgrade incredibly annoying. With this it only takes twice more clicks than before, which might still be bothersome so this particular upgrade is not longer set to be ignored by the bundled Upgrade Editor and can be enabled only on parts meant for a nanoprobe or alike. Forgot to include this in the Changelog.

If you take a look at the RO TAC Life Support settings: @TACLSGlobalSettings:AFTER[TacLifeSupport] { @FoodConsumptionRate = 6.77E-05 @WaterConsumptionRate = 4.48E-05 @OxygenConsumptionRate = 6.85E-03 @CO2ProductionRate = 5.92E-03 @WasteProductionRate = 6.16E-06 @WasteWaterProductionRate = 5.70E-05 } The mass of CO2ProductionRate(that number times its density as defined in its resource config, which is located in CRP) is smaller than the mass from OxygenConsumptionRate despite CO2 being denser. That means part of that oxygen consumed is not coming out as CO2. On the other hand the mass of waste water coming out is significantly larger than the mass of water being consumed. Those numbers are certainly grounded on real research on human metabolism, and they have interesting consequences. In a hypothetical 100% efficiency closed loop life support system, it means that while more water will be produced from recycling waste water than what is being consumed, part of that water will have to be split into 2 H2 + O2 to keep the ratio between recycled life support resources equal, or eventually there will be a very large surplus of water while oxygen will run out, thus water recyclers generating more water may not be incorrect at all as long as the total mass of life support resources and wastes stays the same after the process(law of conservation of mass). It also means any simulated near or closed loop life support in TAC LS using the RO settings will need a water splitter.

Version 0.3.6 https://drive.google.com/open?id=1RqY_jNVZR29HYsuDi0ac9clrVyVpgBpx Mostly bugfixes and a significant improvement in the way ThrottleControlledShutdown.dll behaves for anyone trying SpaceX styled first stage recovery landings or genuinely suicide burns using engines with limited throttle. It won't wait 1 second before running a check on whether the throttle is at 0 or not when altitude is beneath 25 km. The reason this was missed is simply because I did not try landing using an engine that cannot throttle down enough to give its vessel a TWR below 1 before, and with this it should no longer be impossible. Regardless of this improvement, landing using engines unable to throttle down until TWR is lower than 1 remains very difficult unless you use MechJeb or run your own kOS script for it where only coding the script will be difficult and once it's done it can be reused multiple times. The fixes happened to a few bugs that were missed before, typos in patches, a single part throwing NREs that is not done by this mod directly but by SSTU Expansion + Bluedog DB, one duplicate patch and some small things in most cases, except for the mentioned duplicate patch that had its double removed so it won't multiply entry costs for parts without specific specs in tree.yml to absurdity. Finally, this mod by itself should be fully compatible with ModuleManager 3.0.1 now, but some of the mods it depends on or recommends may still have patches that won't work correctly in it. I'm still using MM 2.8.1 just in case. Also somewhat important, the bundled Upgrade Editor in this version is the first one that works well enough to be considered "stable", besides issues with part symmetry.

Version 0.3.4: https://drive.google.com/open?id=1Cm5WA73G3IEONZ-JjEXQC0ULmpUA3Og1 This version should have been the first one for public release, because besides not having yet a decent setup to support part symmetry(there are ways to deal with limitations in the support for part symmetry though, see the Readme for details), all major issues that could be identified and reproduced were fixed now. Letting the issue with ModuleRCS and RCSFX slide was a big mistake, but it's solved now. Apparently using OnAwake() on some modules will cause trouble. Perhaps it would be best to not use such command at all, because apparently its lack is not hindering the load of original part configs for RCS parts with upgrades in any form, but unless other Modules also end having problems because of it, it will remain being applied on modules other than RCS for now. No matter how many bugs are fixed, it won't change the fact the entire code base of this plugin is sort of like duct tape and epoxy plastered over an unfinished framework in an attempt to improve it, but it mostly works now, besides lacking perfect, flawless support for parts with symmetrical counterparts.

The thrusters are located above its center of mass, therefore it is a puller, but it got scrapped because there is a better way of designing nuclear electric propulsion with manned 40+ km/s delta-v and total burn times lasting a few weeks at most instead of months or years: never using more reactor power than what is strictly needed. To that end, it was necessary to add a config for yet one more rescaled Near Future Electrical nuclear reactor: an even bigger, 1 GW reactor with 12m diameter that weighs less than the two reactors from that 1 GW thruster test design, plus a radiator large enough to dissipate its heat if placed in 2x symmetry. As seen here: Version 0.3.5 https://drive.google.com/open?id=1SrCO1IDak5K3kYy-xi0wNWTDzq-P7fF5 Speaking of big nuclear things, a specific config to rescale USI Orion to the real 10m diameter USAF Orion and change its specs accordingly is in. Recommended payload mass for it is 50 tons, and the changes, supposing the specific impulse specs in its ModuleEnginesFX have influence in the way it actually works, make both the Orion and the Medusa drives vastly more powerful in atmosphere than in vacuum as they should be in reality. By the way, in case you didn't already know, Extraplanetary Launchpad recipes for building nukes for the Orion from USI do exist, so there is a way to build nukes in outer space, which would have very big consequences if this game was a Cold War simulator as well, still interesting anyway. Now the engines from Near Future Launch Vehicles also are supported. The rescaled Merlin-1D and Merlin-1DV models that otherwise would get in as placeholders for the Raptor are replaced to its models for the Raptor and Raptor Vacuum, its BE-4 and RD-0234 Methane engines got SSTU clusters, real specs and rescales, but the rest of this mod, except maybe for docking port and RCS parts, is mostly redundant with procedurals. By the way, this mod will still use the 2016 Raptor concept for the ITS rather than the less powerful, newer prototype currently under development for the BFR. It's been a while without checking the layout of the tech tree. After seeing how it was looking like, which was the initial drive for this update, it was critical to rearrange it into something that looks better. Furthermore, the later plasma propulsion tech nodes were too expensive and offered too little for their research costs, for even at 1 GW power levels their thrust still is kind of weak and almost as high Isp gas core NTRs were previously cheaper to research. Thus their R&D costs were slashed significantly. Fusion rockets also have more research requirements than their default ones in Community Tech Tree, which previously made them ridiculously cheap to research for the kind of performance they deliver. Those are the only new things in this version besides the patch that converts Liquid Fuel/Oxidizer to real Kerosene and Liquid Oxygen being active by default now. There were bugfixes too. A typo in the Aerozine50 upgrade alternative for resistojet RCS parts was corrected, same on mistakenly using "techRequired" instead of "TechRequired" because Part Upgrades for some unknown reason use the former instead of standardized field names for everything and I got them mixed up in the patches of the really big radiators for the nuclear reactors so they wouldn't be placed in the correct tech nodes before. Fixed a minor detail involving the Open Cycle Gas Core NTR from Kerbal Atomics having 2 ModuleEnginesFX and previously only one of them was updated to use methane instead of hydrogen if the upgrade that did so was chosen. And finally another batch of improvements to the SSTU cluster patches, which is sort of technical, involving "CONSTRAINLOOKFX" and their correct assignment to the SSTU counterpart module which may not have any major, noticeable in-game effects.

Version 0.3.4 https://drive.google.com/open?id=1A4wGlFbXHKjwu3vQ_0efPIEnEQtpYlx3 Further bringing the "Near-Future" part of this mod to where it should go, with the Atomic Rockets site being very useful as inspiration. The most noticeable addition is right above. Scaling up NearFutureElectrical reactors and its NFP electric propulsion to the extreme. There is no solid real source to draw from because fission reactors that large may never happen and by the time technology evolves to the point such things could be built fusion power capable of generating 1 GW with only a fraction of the size and mass could already exist, same on 1 GW magnetoplasmadynamic thrusters. I wish I was good at 3d modelling but already been there, tried and gave up. Stretched NearFutureElectrical reactor models will have to do for these extremely powerful reactors, at least for now. Besides the stretched trefoil symbol, it's mostly serviceable. Maybe even cool in the same dank way MLG videos and Sanic "original characters" are. Not as much of a showoff but perhaps far more important is the improvement to RealKerolox. Just a plain conversion of LF to Kerosene and Oxidizer to Liquid Oxygen won't give engines fuel ratios close to real Kerolox engines, but an unrealistically fuel-rich burn that would be terribly inefficient in reality due to most of the fuel not going into combustion because of the lack of enough oxygen. It may be argued converting LF/Ox to Aerozine50/NTO would make more sense, but then there would be no RP-1 rockets at all without specific configs. Now it also changes the fractions to more realistic, oxidizer-rich ones in the engines, SSTU tanks, non-procedural tanks using RESOURCE and ProceduralParts tanks. In fact maybe it should be activated by default regardless of RealISRU now, but there are a few details that could still be improved. Support to NearFuturePropulsion now includes its RCS parts. Making electric RCS with enough thrust to be useful without cheating the laws of physics was tricky. Suffice to say, there is no way to run the RCS parts from NFP with this mod for more than a few seconds without a nuclear reactor now, because they ended becoming versions of real electric propulsion with the electrical power they require scaled up by orders of magnitude, for their real counterparts are way too puny in thrust for RCS purposes without high time warp, and RCS with timewarp is impossible. They also received ModuleEngines* through the patch so they can be used as main propulsion and, most importantly, work with PersistentThrust acceleration under high time warps. I also removed an unreal design choice from these parts and now all electric propulsion have roughly the same diameter because the real way to make an ion thruster more powerful doesn't involve doubling its diameter at all. Besides some magnitudes power leveling of NearFuturePropulsion engines, resistojet RCS and engines that require no additional mods to be created are included. However, mods that add nuclear reactors are strongly recommended for them. These are much simpler electrical engines that heat a mono-propellant through a resistor coil(AKA heating element) to generate thrust, sort like NTRs but replacing the heat of the reactor with heat from electricity passing through a resistor. There are not many freely available sources about them in the Internet and some sites mix them up with arcjets which are not the same thing at all. The real ones operate with a few hundreds of watts at most. These are either Near-Future or Hard Science Fiction tech and also scaled up to megawatts of electrical power, very high chamber pressures and temperatures only carbides with extremely high melting points could withstand. They are not necessarily better than ion engines or NTRs, it all depends on the mission profile. But for use as RCS, these are way better than any plasma or ion thruster. The choice of RP-1 as fuel for such resistojets might be dubious though, but at the temperatures involved it probably won't leave unburnt residues. All these things generate a lot of waste heat, and the Stock radiators aren't really designed for this level of power. As seen in the images above, scaled up radiators, in some cases truly gigantic, are also included in this update. There is something about radiators KSP doesn't simulate: the hotter the coolant flowing through them, the more heat a radiator can dissipate, which means a reactor designed to withstand high temperatures and send hotter coolant to radiators would, paradoxically, require less radiators than lower operating temperatures ones. This fact is abstracted in the new patches for nuclear reactors and in these scaled up Stock radiators, which should also have a darker color to match the higher melting point materials they are made of, but until SSTU features radiators with recolors it would be tricky to do this. The Tech Tree got more changes. Among other things, Ion Propulsion was made more attractive, requiring Nanolathing and Specialized Electrics instead of its previous tech requirements to be researched, which in my opinion makes more sense than the way it is set in Stock and Community Tech Tree. The radiator tech nodes were preserved only to serve as a convenient separated listing of large radiators for the new 100+ MW reactors and now have drastically smaller research point costs because there is not much of a need to "research" radiators at all in the first place if the materials science to build them already exists. And as finishing notes, a few more SSTU clusters, this time for the unique engines from Cryogenic Engines SSTU doesn't already feature: the RD-0120, the LE-7 and the Vulcain. The long neglected LVT-30 which was utterly useless compared to real engines at its tech level finally was converted in something which could be handy in early game, plus a batch of bugfixes that removed every error involving modified engines from either Stock or other mods, or at least almost all of them, both with and without SSTU clusters.

The game doesn't fail when an user cheats an orbit through HyperEdit. I see such cases under the same light and given there is no official multiplayer, there is little point to completely cut off exploits. The reasonably realistic tankages were made available for those who care and also to give a point for the existence of liquid methane engines given this mod makes methane cryogenic as well(the way it is in reality), but why bother trying to stop those who don't care about how unrealistically lightweight the dry mass of a huge volume balloon tank filled with LH2 would be despite its size? And here is another update, with even more custom engine clusters, this time for KerbalAtomics: Version 0.3.3 https://drive.google.com/open?id=11E5tD_-xn6JmKuheioIWUiOzv-nSo-l2 Did you know that making gasses into cryogenic liquid propellants is absolutely useless for electric propulsion? After realizing that two more fuel types were added, Hydrogen and Methane stored as gasses for the VASIMR from NearFuturePropulsion. There were also two duplicate parts converted into switchable upgrades for their parents from the Apollo LMAE and LMDE. After checking the amount of fuel options, at this point there is no way to hide this is a kind of "RealFuels Lite", and with the patch that converts LF/Ox to Kerosene and Liquid Oxygen, some historical rockets available through parts from Taerobee, FASA and Bluedog Design Bureau were not being given fair treatment. Being the first American rocket to launch an artificial satellite in orbit is relevant enough, plus the significant performance differences between Ethanol, Hydyne and Kerosene justify having the first two specified, even if they only apply to a few very early game rocket engines. Then X-15 is a big deal too and RealISRU support already drove the optional inclusion of Liquid Ammonia, so why not have it as well? The difference to RealFuels? Pretty simple: unified propellant ratios and omitting details like the presence of HTP in some of such mixtures, still "abstracting" together hypergolics, solids and monopropellants. But this is as far as it's practical to go without the features of RealFuels. By the way, very early rockets like the Juno I had much more dry mass(from the specs in that link it's almost Stockalike) than modern ones, to the point matching the Explorer 1 launch required switching its first stage SSTU tank to a "Service Module" tank type. All of that done to improve the early game. Besides that, now the probes from Bluedog Design Bureau are almost 100% converted to their real counterparts, including Sputnik-3 and others. Sputnik-3 was made into a gold mine of early science, the changes to its original config gave it 7 different experiments, so there is a point to launch an over 1.3 tons satellite without integrated avionics guidance in it. Now there is only the OSO-1 left. And then I'll just use procedural probe cores every time and wonder why I bothered doing this besides the Sputnik-3 as a 7 experiments in 1 part package. But the really major deal of this update is adding SSTU engine clusters to nearly all parts in KerbalAtomics and changing some of them to what should be more realistic specs. It's hard to extrapolate on technologies like gas core NTRs which only exist in theory, but normally the theoretical tends to veer on the optimistic, and the TWRs for some of those in KerbalAtomics were incredibly overpowered compared to their theoretical specs. One peculiar thing is that instead of implementing more and more mostly identical performance parts, model swaps are done in some cases, like for example this patch replacing the Stock NTR model used by the same part if KerbalAtomics isn't installed: And animations for engines which have collapsible nozzles in KerbalAtomics can be easily converted to SSTU modules, so all parts that weren't redundant(no need to have 1.25m, 2.5m and 3.75m variants of the same engine with SSTU, and those sizes don't even apply here) were improved.