Phineas Freak

@JustZach and @Bosun: you are going to break a lot of things regarding the aero and thermal behavour of the pods upon reentry if you just scale them down. Besides, it is not a straightforward thing, as you also need to move/scale any integrated RCS thrusters that the parts may include. TL;DR not an easy thing to do, new "RO-like" MM configs will be needed and someone has to create them.

It is probably Procedural Parts. What version do you have installed?

Super-sonic parachutes and propulsive landing. Use the parachutes to decelerate you enough so that you can discard any reentry protection equipment and then the engines to soft land. Another solution would be to use airbags for the final landing instead of landing struts. Uses less fuel too. TL;DR: follow real life procedures (or derivatives of them) and you will succeed the first time.

That's certainly not my own mod. But i was going to tweak the brightness a bit for the next version anyway. Thanks for reminding me about it! BTW, i also experience the "washed-out" surfaces but not every time.

No need for that, you were right and i was wrong. I have opened an issue to the RP-0 repository.

Take a look at the BNTR global engine config. Hint: you will need to use the "ModuleHybridEngine" module to make them switchable in flight.

Not necessarily, no. I have seen various mods (mis)using floats for the cost fields and RP-0 itself has been using floats since...ever. For the KW parts specifically, these where added almost exactly one year ago: https://github.com/KSP-RO/RP-0/commit/fc2d43997e11349c5f87229ff8cd4054d53fa055 And we had 2 official releases since then. Nobody ever complained about the costs breaking their game. Also, the RP-0 tech tree is created by an automated process, so no human hands ever modify it. The KW fairing costs are correct: https://github.com/KSP-RO/RP-0/blob/8b2907413eb54c49f11ec0bc01813e39b73c6dc3/tree.yml#L583-L603 BTW, did you test it without TweakScale installed? Be aware that TweakScale is not officially supported by RO or RP-0 and any older TweakScale patches will be removed from them due time.

Yea...the "engineResponseSpeed" parameter does not play well (if at all) with MJ. The difference in the throttle-up times is probably because of the propellants used: The early KIWI series used gaseous hydrogen while the XE series used liquid hydrogen. I imagine that you do not want to dump supercold LH2 into a reactor chamber that has a core temperature of over 2500 K! As i see from later (LH2) variants of the KIWI series they have comparable spool-up times. Some of that is also caused by the reactor control system and the actual power test profiles. Additionaly, the turbopumps. The XE test articles used flight-like hardware (IIRC they used the turbopump from an RL10A-3 engine) and these have defined spool-up and down times.

With TweakScale: [ERR 21:58:54.754] [TweakScale] Exception on writeDryCost: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.WriteDryCost () [0x00000] in <filename unknown>:0 And for the cost and entryCost fields: [LOG 21:58:54.756] [TweakScale] part=antenna.cone.toggle (non RP-0 - CA-A02 Conic Antenna) [ERR 21:58:54.757] [TweakScale] Exception on writeDryCost: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.WriteDryCost () [0x00000] in <filename unknown>:0 From the Module Manager cache: PART { name = antenna_cone_toggle module = PartTapIn author = Akron rescaleFactor = 1.0 node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, -1.0 attachRules = 0,1,0,0,0 TechRequired = engineering101 entryCost = 240 cost = 320 . . . } So the fields are integers. I would suggest to remove TweakScale and try again to see if it persists. Edit: BTW, the Coatl Aerospace parts are not supported by RP-0 so it is not possible for RP-0 to modify these two fields.

@Bornholio It seems that you have already made all the necessary changes. The global engine config that you posted is correct. The additional engine configs will need TF support but that can be left out for a future update.

@Eklykti You can improve compatibility with RO by adding some MM checks to the part config patches: @PART[mk1pod]:FOR[DescentMode]:NEEDS[!RealismOverhaul] { MODULE { name = CoMShifter DescentModeCoM = 0.0, 0.0, 0.1 } } So that the patches won't be applied if RO is installed. An extra layer of security would also be to rename the module to "ModuleCoMShifter" but that is not something required (something for a future overhaul/new features).

No but i had some awesome times trying out the new pre-state features! Now if only i could find a way to map exactly the resulting ascent sub-orbital profile to a launch vehicle...it probably requires the use of a PEG simulation program.

There are some guides to help you install the full RSS/RO/RP-0 suite of mods: The "spreadsheet" way: use the golden spreadsheet in order to download and install the required and recommended mods. The "video guide" way: use the "how-to" video guides by @tylerraiz in order to download and install the required and recommended mods.

KSP 1.2.2 is explicitly required by Kopernicus to work (and in turn by RSS) so you need to install that specific version.

@Irenicus Well... I do not think that any of these mods are going to work with a pre-release of KSP.

@Arrowstar Judging from the tests that @Stract did, wouldn't a toggle in the KSPTOT Options window be enough for KSPTOT to be compatible with both velocity calculations? Might be completely wrong here. If so then excuse me...

@Irenicus I will make a guess and assume that you are missing ModularFlightIntegrator (Kopernicus dependency). If not then we will need a mod list and log files.

That is why i wanted the log and the cache file but, as i see, everything is OK now. I'll add another small note for that since some browsers do not behave correctly when saving select pages.

@msnbcorp As @Galileo said, changing the detail texture level ("DetailScale") will improve the "local" detail but will make the "global" detail suffer from extreme tiling (something that you really don't want to see from orbit). But, you can make the detail texture appear from larger distances by playing with the "DetailDist" and "DistFadeVert" parameters until you can see the details from the ground level.

@linuxgurugamer The worst thing about this bug it is that it has been there...forever. I am sure that it has been reported before but why it was never fixed is something that i do not understand. Small fix as i wrote the wrong thing: MM cannot replace FX and/or sounds that are not in the same folder as the part config.

@linuxgurugamer There are two problems with the sounds: KSP has a bug that does not allow any sound files outside of the part folder to be used. Because of the above bug, it is not possible to replace neither the FX or the sounds of parts that use the "old" conventions via MM (i.e. "@sound_decoupler_fire = my_activation_sound).

@HiThere!2 Since i do not have access to an OSX or Linux machine (OpenGL), i want you to send me: A screenshot of your RSSVE folder contents A copy of the "ModuleManager.ConfigCache" file There is the possibility that i may have missed something or that my patch doesn't work...

So, a small update on the graphical bugs. I have implemented a small config patch to take care of most of "featureless sphere" syndrome. You won't get a visually accurate atmosphere (Mars and Jupiter are the planets affected the most) but the rest is there and they work as they should be. Download it (right - click the page and save it, it will prompt you to save it as a .cfg file) and place it under your GameData/RSSVE installation path. Note that this config is an interim and not a proper bug fix. A proper bug fix will probably be part of the next Release Candidate (supporting KSP 1.3).

The original RVE. There was a PQS Terrain Manager shipped with the pre-KSP 1.0 versions of EVE that allowed the addition of detail texture(s) to the main PQS texture. Unfortunately, this feature is now broken. Kopernicus allows the addition of PQS detail textures but: They are overlaid over the main PQS texture in "additive" and not "overwrite" mode (meaning that the main PQS texture is still very visible). They do not work in Scaled Space. Granted, SS is completely different than PQS but EVE allowed the PQS textures to be seen from orbit. <rant>Someone has to bug Waz to check if he can fix/revive it in EVE. It is a really nice feature and has not been implemented by any other similar mods. The detail that it adds to the Earth surface is unmatched.</rant>

@Mandella No, it works fine under DX9. It does not if you enforce DX11 and i am not sure for OpenGL.