Phineas Freak

@h0yer speaking about weirdness: Only the basic mods installed RN parts use only part modules provided by stock No errors when loading the craft file(s) WTH is going on? I will drop another suggestion and ask you to remove: AJE v2.8.0.0 CustomBarnKit KerbalJointReinforcement KSCSwitcher RealChute SigmaBinary TextureReplacer Just to make sure that only the really basic (and required mods) are installed, Heck, i would suggest to also test the RN mods in a stock KSP installation to see if you can reproduce it without any mods.

@Friedrich Nietzsche I do not support CKAN installations (it is mentioned on the OP). But yes, every version of EVE from KSP 1.0 and upwards is compatible. I will make a guess and ask you if a folder name "BoulderCo" exists inside you GameData folder. If so, remove it.

IRL they use pressurized nitrogen (since it is inert, nontoxic and not corrosive) but any other inert gas can do the job (like helium for example). @JadeOfMaar Hydrogen Peroxide is called HTP in CRP.

Close, it is 1 EC = 1 kWh. To convert between the two you have to multiply (kWh to EC) or divide (EC to kWh) your value at hand by 3.6. Before KSP 1.3 you could not set the abbreviation of the EC RESOURCE_DEFINITION to read "kWh". Now we can do it, as part of either CRP or RO. If you are seeing a different consumption for the duration of a day check to see if the KSP settings have the time display as "Kerbin" instead of "Earth" time.

@h0yer The provided log is clear and the craft loading/editing phase does not show any kind of NullRefs or stuff like that. Now it is time to start a search: temporary remove any of the mods that are not required by RSS/RO (move them in a folder outside of the GameData) but keep the RN stuff. Check if the problem persists. If not then start adding back the mods one by one until the issue appears again. For the record, i installed the RN Soviet Probes pack, selected the Molniya probe and it did not deploy it's antennas or solar arrays. Seeing that you have a large amount of mods installed i could make a guess (again...might be also wrong) and say that it is an inter-mod compatibility issue.

@Bornholio and @Temeter, are the alternate propellant options for the classic NERVA or the BNTR? Also, do they work with the ModuleHybridEngines option correctly? IIRC this engine module only supports 2 configs in flight but i may be wrong...

@h0yer So, there are some things going wrong here: Critical Stuff: D:\Steam\steamapps\common\Kerbal Space Program\... First rule when you are modding KSP: you never mod a Steam installation. Instead, you copy the KSP folder somewhere outside the SteamApps folder and run KSP from there. If you don't then: [ERR 15:30:00.862] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null [ERR 15:30:00.863] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null [ERR 15:30:00.867] AssemblyLoader: Exception loading 'DeadlyReentry': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 You will end up with deprecated and/or conflicting files/assemblies, much like the KSPUtil.dll above (was merged with other assemblies in KSP 1.2). This will break a ton of stuff. Not So Critical Stuff: Then, we have old and incompatible assemblies: [ERR 15:30:00.867] AssemblyLoader: Exception loading 'DeadlyReentry': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'DeadlyReentry.ModuleAeroReentry' from assembly 'DeadlyReentry, Version=7.4.7.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'DeadlyReentry.DeadlyReentryScenario' from assembly 'DeadlyReentry, Version=7.4.7.0, Culture=neutral, PublicKeyToken=null'. The 7.4.7.0 version of DRE is only compatible with KSP 1.1.3. There is an updated version (7.5.0.0) for KSP 1.2(.2) here: https://github.com/Starwaster/DeadlyReentry/releases The rest of the log is clean. I guess that if you recreate your installation with a clean install of KSP 1.2.2 everything will be fine.

Can you provide us some KSP logs?

@g00bd0g no, DRE changes a lot of the thermal functionality and requires some patching to work as expected. KerbalEVA is a "part" now and so changes are required in order to interoperate with DRE. Read the contents of the post that i linked to get a better idea.

@KAO yes but you need to recompile/update most of the dependencies installed manually: EngineGroupController Real Fuels RealismOverhaul RealSolarSystem SolverEngines Also, you are missing the rest of the dependencies: Advanced Jet Engine Community Resource Pack FAR Real Heat Real Plume SmokeScreen And remove mods that are conflicting with other mods: Modular Fuel Tanks

@NathanKell PF does not use the normal "ModuleDecouple" module but a custom one that does not have provisions for manually setting the staging. This has to be handled by PF and that's why i asked if it is possible to implement such a functionality.

@rsparkyc I did some testing at making the procedural fairing side decouplers toggleable (much like the normal decouplers/separators) but, since my C# skills are almost non-existent, would be possible to consider such an option to be included for the next PF update? It would cut down the amount of required fairing parts in half and also allow some more flexibility for an existing craft file.

@AlimOncul https://docs.google.com/spreadsheets/d/1it8cZ_t8J67m4oPOvjzgBxHZvSXsvhNTPhlDVqEGTFY/edit For both KSP 1.2 and 1.3.

Yes, Thomas kept this feature although, as you said, it is now deprecated: It should work since i tested it as part of the RSS KSP 1.3 PR.

@RocketBlam There have been some changes on how RSS names the planets now but the "Earth" name will continue to be used (else it will break a ton of stuff). If you insert back the "cbNameLater = Earth" parameter to the RSS Earth Kopernicus config then everything will work as before.

Well, i tried: Changing the RSS ring texture to be horizontal Creating a custom (horizontal) ring texture Testing every dev version of Kopernicus and Scatterer (at the time) Testing just the ring shadow feature in "stock" RSS Nothing worked. The closest i ever got was a featureless ring (no texture) that had the shadow.

Not with the current version of Scatterer. Scatterer itself does support this feature now (EVE integration) but it is somewhat broken in the v0.0300 and any previous versions that implement it. The next version of Scatterer will have improved compatibility and will allow me to enable this feature. I also need to work on the ring shadows for Saturn. For some reason it never really worked for RSS.

That is the idea now, to both check for float values before commiting a new PR and when a new tech tree config is created.

@HaydenTheKing From the GitHub releases page.

RSS uses mostly hard-coded values for it's body (calculated via the JPL HORIZONS ephemeris computation service) so it also uses G(M + m) when calculating the ephemeris data. Now, if KSP forces the vessels to use just GM then, as @Stract says, we will be SOL. The easiest thing to do would be to redefine all GM values of RSS but we will lose accuracy for historical events. Or maybe Principia could help with the vessel calculations.

I did some tests via a semi - custom part: it used similar stats as the large radiator array but with the part model of the radial radiators. The tank was 10 m x 15 m and filled with LH2 (comparable to the Copernicus NTR stage). At x1000000 about 4 to 6 of them were enough to zero out the boiloff at LEO. Note that your mileage may vary depending on the environment (LEO or deep space), the propellants (LOX, LH2, LCH4), and the tank size (smaller tanks are worse than larger ones and tanks other than "Cryogenic" and "ServiceModule" are useless). Edit: ninja'ed! I see that you found it out by yourself!

@Bornholio and @Temeter: have you tried the stock radiators with cryogenic tanks? They are OP for keeping cryogenic liquids...liquid.

No, it means that I or someone else can make them and submit them to the KSP-RO repository to be included with RO. But having said that: Any modder can also opt to support RO by their own so if you want to roll them with your stock releases then it is not a problem (as they usually have enough of a workload to not being able to also create the respective configs). Edit: since you have been rolling your own RO configs for some time now it would not make sense to change it now. Just keep up your awesome work!

Besides, the RO configs are a responsibility of the KSP-RO team.