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.

Version 0.3.3: https://drive.google.com/open?id=19E0zdBBullUf4Gt1SfgIMeWa1z5egFvo Finally devised a method to load the original part config without upgrades in the plugin for each and every module that requires such procedure in a part, so all those workarounds from the previous versions are now obsolete, and most of its shortcomings are gone. Therefore, delete any previous UpgradeEditor folder if you're installing this new version, a recommended acting for updating any KSP mod. Also, there is something new besides finally getting this to support any possible PartModule with upgrades: ignore lists for things like upgrades that increase max diameter for procedural parts and thus would be pointless to disable. A few default settings exist in UpgradesToIgnore.cfg for the only mod with procedural parts making extensive use of the Part Upgrade system I know of, SSTU.

Version 0.3.2: https://drive.google.com/open?id=1zb9EHaZnLqZd6NT7L-PX-3_Bp88DOkr7 There was a mass and resource storage density discrepancy between ProceduralParts and SSTU tanks that lingered for too long already. Fixing it required changes to many patches, disabling SMURFF patches to ProceduralParts and ended becoming a reminder of the greatest realism shortfall in SSTU: the total volume of its tanks has no influence on their dry mass unless RealFuels is installed. Such was a major compromise, likely done for coding convenience, and the only way to work around the fact dry mass is calculated from the contents of a tank rather than its volume is to set up a multitude of different tank types in SSTU, like separate cryogenic tanks for methane that will have significantly less dry mass than the default ones for LH2 to simulate the mass of the extra volume the latter requires, plus a few other cases for mass ratios that differ significantly from RP-1 like a water, a xenon and an argon tank. There could be another way without a big list of tank types in SSTU, but unfortunately something like this: SSTU_ZEROMASSRESOURCE { name = ArgonGas mass = 1.8778947e-8 //This should change the mass ratio on electric propulsion tanks correctly } Which was my first attempt to add mass ratios with better realism for SSTU, doesn't really work. Instead of doing like that and having an unified Electric Propulsion tank for Argon and Xenon, for example, it was necessary to create separate tank categories in SSTU for each, but for the propellants that are featured in this mod, I believe the end result was still OK. Besides that, the other major change in this update are patches for the Stock ion engine and also for NearFuturePropulsion which, most noticeably, convert many NFP engines to use SSTU clusters, which usefulness is questionable given how much electricity they need. Second, after some small time Internet research, I got some specs for many of the engines in NFP and placed them over the Stock-balanced stats, while creating a generic patch for a few ones that didn't get specific configs and for future ones that may be released in future NFP versions. Now there is a catch: magical kN rated thrust is gone for such engines. Real electric propulsion is terribly slow, making PersistentThrust and PersistentRotation essential for using such engines because they allow for thrusting them at high time warp while keeping the heading of the vessel constant at prograde or retrograde or another desirable heading. There is a 6.5 kN magnetoplasmadynamic xenon thruster among those created as a copy of the biggest MPD in NFP, the only one with over 1 kN of thrust. Unfortunately it consumes 60.2 MW of power per second at full thrust. There is also a copy of NFE biggest nuclear reactor to generate enough power for that one, but it weighs 58.3 tons and requires tons of radiators. If you really would rather have a VASIMR performing like a torchship, there is a .bat and its equivalent .sh shell script to disable the nerf of ion and other electric engines. Finally, besides fixing some bugs, Upgrade Editor is now bundled and to reflect this change some duplicates are now available as part upgrades instead, specially for nuclear thermal rockets, which also got new methane variants like the partly pebble bed reactor based Timberwind 45 replacing the regular Bimodal NTR and a Methane - Methane/Ox version for the same. With the dry mass changes for methane tanks in SSTU, which have much better mass ratios than LH2, it is a real option now.

I'm so utterly desensitized at this point that I can't really care about the future of KSP, but I hope for a realistic spaceflight simulator with the blessings of the real Richard M. Stallman for being 100% free software happening one day, likely never unfortunately. I've seen this happen when Interplay first tried to dumb down their Fallout franchise with Fallout:Brotherhood of Steel, then failed and sold it to Bethesda which made it into Oblivion with Guns(Fallout 3), when the "masterpiece" action "RPG" Gothic 4: ArcaniA was made by wholly different developers after a mediocre Gothic 3 yet still a genuine RPG and the excellent Gothic 1 and 2 predecessors, when the very developers of those created a cool action RPG called Risen only to continue with poor sequels for it, when the horrible Thi4f came as a sequel to the great Thief 1 and 2 from Looking Glass and 3 from Ion Storm which was not so great but still good, when cynical companies starting deceiving fools through Kickstarters to pay for "authentic spiritual successors" of old games that don't hold a candle to the originals so they can get funds without having to share any profits to those doing the funding, when Bioshock happened as yet another inferior "spiritual successor" to System Shock 1 and 2, then ironically its sequels were accused of being "dumbed down" by some fans of the first Bioshock, just to name a few. I'm very glad there were no attempts to "remake" Arcanum: of Steamworks and Magick Obscura in a new form, accessible for "wider audiences", consoles and/or tablets and at least the legacy of the great Troika(RIP), unlike the legacy of the gone Black Isle Studios from which it originated, was left to rest in peace.

Through a combination of storing the names of all upgrades that should be disabled in a single string separated by commas, processed by the code every time a craft is first loaded through a public override void OnStart(StartState state), it's done, and finally the critical feature of persistence is in: Version 0.32.5: https://drive.google.com/open?id=1NLNZ3O65bHJKk8FkIi2PScZW2ouEYIwQ Creating persistent settings in saved vessels was a much higher priority than improving the code so workarounds won't be needed. Now it's mostly functional for engines and RCS. Tested it with 5 parts including an engine with two modes like the Stock RAPIER where each mode had its own specific upgrade changes and there were no issues, but it may lag a bit when loading crafts with tons of parts featuring upgrades. A version that just reads correctly from the original Part config without upgrades for any module will(or more honestly may) be done later. Same on loading all parts in symmetry at once and applying the changes simultaneously(unless the Stock code already handles upgrades on parts with symmetry like that). I'm not going to re-license as a matter of respect. As for the license choice, every time you release anything under the GNU GPL, you receive a blessing.

TexturesUnlimited works fine with DX9/11. I just had to trim some "fat" from the GameData folder first. I checked the parts in the VAB with PBR and they showed up without any glitches. The crash only happens with OpenGL 4.5 rendering through -force-opengl.

It was already mentioned in the posted logs: a mid-range Radeon R9 380 with 4GB VRAM, it is good for what it is. It had its share of complications which were likely caused by bad drivers rather than hardware defects given similar problems never happened again after some recent driver updates, but at least it never fried. *Edit: and everything works correctly on D3D9 or 11

Because it seems these issues aren't SSTU specific but related to TU, I'm reporting this here. I got a problem with Textures Unlimited, the problem being it only works with D3D for me, after testing it on two identical installs of KSP, one on Linux and the other on Windows 7 (dual-boot). On Linux, although being stuck(hopefully not for too long) with a limited open-source driver that only supports OpenGL 3.0 is probably to blame, all parts using Textures Unlimited in SSTU show up in a texture-less pitch black color. Just to be sure, I also tested it on Windows 7 with force-opengl, and this happened: From textures not showing to just crashing. I wonder if all this info could be helpful, for here on the other hand is what happens on Linux, with the limited open-source amdgpu driver which only supports OpenGL 3.0 : Maybe this only happens with AMD GPUs or very specific ones, maybe not. Finally, when running on Windows with the same mods that available memory could support in previous SSTU versions, the game memory load spiked bordering 15GB even without SSTU-PBR and crashed in Windows with D3D9 rendering so I had to sacrifice several mods, and it likewise crashed due to lack of enough memory with force-d3d11 until I deleted a some mods to reduce the load. Is Textures Unlimited increasing memory load a couple of GBs normal?

This was originally meant to become UpgradesGUI Continued, but for several reasons starting "from scratch" proved more practical, and this Add-On inherited only a little from the former by @Gotmachine. For now it remains more limited than UpgradesGUI in certain ways. This plugin works in the VAB or SPH and adds a button to the right-click menu on any parts with upgrades to expand their applications and allow for implementing upgrades as alternatives which can be chosen at any time, regardless of newer ones being unlocked in the Tech Tree. DISCLAIMER: A lot needs to be improved before it gets even close to completed. This plugin was tested on Engines and RCS where, with the aid of the MM patches, it worked both in Editor and Flight, but there are almost certainly bugs. Download Upgrade Editor 0.3.4 (includes source code): https://drive.google.com/open?id=1Cm5WA73G3IEONZ-JjEXQC0ULmpUA3Og1 Older versions: https://drive.google.com/open?id=1Zlj9p-RIceb1yP-43V-8SjG_30FIP_fk DEPENDENCIES: ModuleManager (bundled version may become temporarily outdated in the future) License: GNU General Public License(GPL) 3.0 except for: RDColoredUpgradeIcon.cs from UpgradesGUI continues with its Unlicense. Upgrade Editor Upgrade Editor was created to make the part/module upgrades feature introduced in 1.2 about as flexible as RealFuels engine and RCS upgrades: configurable per part. Note that the plugin doesn't add any upgrades. If you want to have them in your game you need to download other mods that implement the upgrade feature. It also highlights part upgrades in the the nodes part list with a pale green background to better differentiate them from parts. How to Use: If you really want to browse every upgrade, even max diameter changes for procedural parts, delete UpgradesToIgnore.cfg While designing a vessel in the VAB/SPH, add a part for it which has unlocked upgrades. After placing the part in the editor, click on "Upgrade Editor" in the Part's right-click menu. "Toggle All" will either disable or enable all upgrades at once. "Always Enable" ignores custom settings. When you're finished with a part, just close the Upgrade Editor by clicking on "Close". Check its "Show Upgraded Stats". After that, any part featuring the same upgrades that is added to the craft will inherit such settings as well. To reset settings, use the reset & close button in the menu, which will enable again all upgrades before closing the UI. Suggested mods with upgrades: Sufficiently Realistic Progression Zero - this was created to support it and is bundled together with it(not necessarily the latest version). SSTULabs - upgrades that come with SSTU aren't of the type that would be significantly improved by the features of the Upgrade Editor(yet), but I'm recommending it anyway. Bluedog Design Bureau - might not really have two upgrades that can be considered tradeoffs, giving this editor a purpose for its parts, but it does have many upgrades. If you're interested in implementing part upgrades for yours, another mod's or Stock engines or RCS as alternatives where the capabilities of this Add-On would be very useful, PM me and I'll include your mod in the list. If you want to bundle this plugin with your mod because it would be useful for it, you don't need to ask for permission. Just keep its license and readme in your bundle, and if you want to remove its source code from it, add a link to this thread or to its download link with source included in its readme should it not have either one yet by then. A few examples of potential uses: An engine or RCS that can be switched between MonoPropellant and LF/Ox. Could be added to any Stock part through ModuleManager. Several upgrades for engines or RCS placed in the same tech tree's node with different tradeoffs between thrust, specific impulse and cost. Known Issues and Limitations: This plugin was not tested for every imaginable situation where it could be of use. Bugs may exist. There is no in-game interface to edit the ignore list of upgrades yet. Terrible support for part symmetry. First this won't apply automatically to all symmetrical counterparts of the selected part yet. Then there are bugs: if you open the Upgrade Editor Menu in a part, change its upgrade settings then alter its symmetry, argument out of range exception spam will happen and the Upgrade Editor button may disappear in all affected parts. Doesn't happen when picking a new part for symmetry from the left part menu, which inherits upgrade settings from latest edited similar with Upgrade Editor, and can also be avoided by saving and reloading the vessel after using the Upgrade Editor Menu to only then apply symmetry. Changelog: Version 0.3.4 Fixed crippling bug with RCS part upgrades by disabling the OnAwake() command for ModuleRCS and RCSFX. Now works correctly instead of having no RCS thrust at all. Fixed major bug where the first part with modified upgrade settings in a vessel loaded in VAB/SPH didn't have its upgrades properly applied. Fixed lack of reset to original Part Stats modified by PartStatsUpgradeModule upon disabling relevant upgrades. Fixed occasional bug where an Engine or RCS with upgrades that did not change propellant type would not have such reverted back during the load of a craft file if upgrades that changed such settings were disabled, depending on the quantity and position of the involved parts in a saved craft. Toggle All Upgrades now is set to false by default, which makes any part picked from the left menu in the Editor inherit the same settings last applied to a similar part through the Upgrade Editor. Version 0.3.3 Added capability of loading original part configs without upgrades and removed no longer necessary ModuleManager workaround patches. Added an Ignore List so upgrades that are utterly pointless to disable like diameter increases for procedural parts won't show up. Version 0.3.2.5 Added full persistence for upgrade settings. Saved crafts now store which upgrades should not be enabled for every part in them. Version 0.3.2 First test release, inheriting only the R&D tech tree highlight from UpgradesGUI and relying on wholly new code for everything else. Special Thanks: To @Gotmachine for doing UpgradesGUI, which inspired this project and served as reference for it. To @Shadowmage for unintentionally giving me a hint on how to achieve this when I was about to give up on this and mostly because I really like SSTU. To everyone who shared and/or created examples of PopupDialog uses , references without which I'd never succeed in creating this.

Version 0.3.1 for KSP 1.3.1: https://drive.google.com/open?id=1ws0JbYmgiTwULIsaO_6LkLfOnb0Zhwl8 Switching over at last, but I'm not entirely sure if a regular user can install the mods used. Some of the mods this was designed to coordinate with can only be made available for 1.3.1 with either self-made recompiles or checking the git repositories of their respective projects for downloading unofficial recompiled files from Pull Requests. Links in the OP will be updated to reflect this. To help a little anyone who might be interested in this and the suggested "modpack" in the OP, thanks to the generosity of @Crzyrndm letting his work become free for redistribution and modification, a version of DynamicDeflection compiled for 1.3.1 is bundled. Originally the plan was to also bundle another mod, an Upgrade Editor that would make it possible to set upgrades separatedly for each part in a craft design, the same functionality as RealFuels engine and RCS upgrades . Unfortunately that proved to be way above my coding skills, if it is even possible. Should creating such a mod prove impossible(which is unlikely), there will be support for RealFuels eventually which is a lot more flexible when setting up engines and RCS than the Stock PartUpgrades, and the modest plugins in this mod are ready for it. ThrottleControlledShutdown.dll will self-deactivate if it detects the RF plugin so it won't be strictly necessary to delete it in that case, while ProceduralAvionics can supports SSTU modular upper stages with or without RealFuels installed. Only a lot of changes to ModuleManager configs to add conditional patches that only apply should RF be installed are required, plus the major universal RealFuels engine setup and SMURFF replacement patch. Now onto the changes. First, having engines which were left activated in a space station or vessel suddenly accelerating on their own once another vessel controlled by the player rendezvous and reaches the physical bubble where the former is located was one of the limitations of ThrottleControlledShutdown, and the solution was so simple: rather than only track activated engines in the active vessel and anything undocking/decoupling from it, it now tracks all parts in the physics bubble, but will shutdown engines from other vessels because it's a simpler and more efficient procedure than tracking all engines from everything and storing individual throttle limits while overriding them all the time. The forked RP-0 plugin also got some changes regarding how much percent from the total volume of a SSTU procedural upper stage it will define as available to calculate procedural avionics from. Rather than a fixed number, it uses a bell curve formula, ranging from 11.8% to a minimum of 0.0016% of the total volume . This is important to prevent very large upper stages from having a huge power demand when their avionics are active and a better solution than unbalanced settings for them. The other major change was rescaling the TKS VA from SSTU to its real dimensions, giving it real stats, and doing the same to other new SSTU parts. There was a new rescale for the SSTU space stations to match the TKS VA with the real TKS service module, the space stations had their names and descriptions changed to more "immersive" ones, together with several fixes involving such parts and all the needed changes to support the latest version of SSTU. As a bonus, patches that make the Skylab from SSTU Expansion Pack and a decent amount of its features work with the latest SSTU are included as well. The extra Apollo service modules from Bluedog Design Bureau however weren't covered by this patch, which is temporary presuming SSTU-Expansion will be officially updated for the latest SSTU and KSP 1.3.1 eventually. Sort of big yet small change: previously life support in TAC was consumed at only 25% of what would be realistic for humans. It was pure lack of attention to not have included the settings from RO for TAC Life Support back when this mod was just starting. There was a need to remove some parts. Non-procedural SRBs using SSTU assets were just a thoughtless conversion of RO configs for ModulesEnginesFX. With SSTU having full support for procedural SRBs, both surface and vacuum optimized, they are kind of redundant anyway so it was easier to just ditch them instead of updating their part configs to work again. And finally as a small detail, with the switch to 1.3.1, if you have Karbonite+ installed, Karborundum will be renamed to Ultra Dense Deuterium by this mod. Now to find a better name for Karbonite, which is... a methane source.

*Edit: Found the answers for the long question previously posted here on my own. Although the implementation can be further improved, it's done: https://forum.kerbalspaceprogram.com/index.php?/topic/167548-* Leaving the original question down here for reference: