Phineas Freak

RSS and some of it's less known dependencies are not officially updated yet for KSP 1.3 Scatterer is not updated yet for KSP 1.3 Doing some work ironing out many big and small bugs & issues found since the RC3 pre-release Many other things that may or may not be tackled until the next (pre?) release

That is correct. Apollo used the a fiberglass Boost Protective Cover over the CM to protect it during the atmospheric phase of the flight and the jettison motor plume. It was part of the overall LES structure and was jettisoned with the rest of the LES hardware (abort motor, jettison motor, mounting structure, canard structure etc). There is a nice document on NTRS that describes it in detail. Also, the LAS on the Orion is pretty much the same thing.

@hargn Thank you for your debugging time! That's weird though, that is the correct (and latest) version of EVE and, as i see, @KAO has the same one installed.

Well...you should have mentioned it earlier. Anyway, in that case: I explicitly set that parameter to be enabled. You can modify that by opening the RSSVE_Scatterer_Global_Config file and setting the useOceanShaders parameter from "True" to "False". You are not supposed to use RSSVE with KSP 1.3 as not all of it's dependencies (Scatterer) are compatible with KSP 1.3 yet. Offtopic: did the compatibility checker message appear on the KSP startup?

@RocketBlam Do you have any visual mods installed? It is possible that they modify the basic Scatterer parameters and force the ocean shaders to be always enabled.

@hargn Is there any possibility that you installed the newer version of DOE? PlanetShine does not count since it a) works for both KSP 1.2 and 1.3 and b) the mod does not have been recompiled for KSP 1.3. Another test would be to remove the RSSVE DOE config (it never really worked as expected due to the way DOE loads it's configs) and test again.

Can you check without them? They should not be the problem but it does not do any harm if you try it anyway.

@DrLicor The forum link is correct, i just tested it. Were does it send you if you click it?

There are three "layers" of naming: currently the patch only modifies the "first" (GUI name) one. The cbNameLater will modify the "second" (semi - internal name ID) one so that everything will work as before. I can confirm that the cbNameLater is both working and required by RSS to operate as expected.

@Galileo The changes that you did for Callisto and Deimos are pretty much still required. I will link you to the RSS KSP 1.3 discussion for more info: https://github.com/KSP-RO/RealSolarSystem/pull/108 TL;DR: compatibility will be broken between the KSP 1.2 and 1.3 releases of RSS.

When you say "Community Tech Tree" you mean this one? Because without also installing RP-0 there is absolutely no way for you to play career mode with RO. Do note that RP-0 is not compatible with KSP 1.2 yet. Edit: also, can you place the contents of that file that you posted inside a spoiler tag?

@undercoveryankee No. The link to the KSP 1.1.3 assembly has always been available via my forum OP change log. I had forgotten to also add it to the GitHub change log notes until you noted it. Edit: @Julien Kerman Sorry, i missed your question! That feature was disabled because the Kopernicus/Scatterer ring integration was not working 100% correctly. This has been fixed with the latest (backported) version of Kopernicus but you will have to do some work in order to enable it. PM me if you want more info. For the record, this feature will be (most probably) enabled for the next release.

Assumming that you mean "Mm": that is the range of the antenna itself. Using the Earth DSN stations it is good up to ~170 Gm, as the part description says. The "Communotron DTS-M1" part resides under the "GameData/Squad/Parts/Utility/commsAntennaDTS-M1" path. It is a stock part. If you are missing it then you may have some problems with your installation.

@undercoveryankee I actually forgot to convert that line into a hyperlink to link this KSP 1.1.3 assembly...it is fixed now.

@Drew Kerman From the devnotes it seems that the texture switching feature is part of the DLC and not the mainline KSP. But more power to us if it is included with the next versions of KSP.

@Tyko The orientation of the attachment node is incorrect: For nodes facing downwards you need to make sure that they have negative pointing vector.

One more feature request (apart from the fairing side decoupler switch): the ability to switch the fairing textures without requiring Firespitter. Maybe the code from PP parts can be adapted to also work for them?

That's definitely something new: [Scatterer] Couldn't remove stock ocean for Titan . . . [EVE CloudsManager]: Unable to parse config node: OBJECT { detailSpeed = 0,25,0 speed = 0,25,0 altitude = 25000 body = Titan name = TitanCloudsLow settings { _DistFade = 0.000075 _DetailScale = 10 _UVNoiseScale = 0.075 _UVNoiseStrength = 0.005 _UVNoiseAnimation = 0.125,0.125 _Color = 110,65,0,255 _DetailDist = 0.000001 _DistFadeVert = 0.000075 _MainTex { value = RSSVE/Assets/MainTextures/Atmosphere } _DetailTex { value = RSSVE/Assets/DetailTextures/DetailCumulus } _UVNoiseTex { value = RSSVE/Assets/DetailTextures/DetailUVNoise } } layer2D { macroCloudMaterial { _InvFade = 0.005 _RimDistSub = 1 _RimDist = 0.0001 _FalloffScale = 5 } shadowMaterial { _ShadowFactor = 0.275 } } layerVolume { maxTranslation = 150,3000,150 visibleRange = 25000 area = 20000,4 size = 4000,3 noiseScale = 64,64,64 rotationSpeed = 0.001 particleMaterial { _InvFade = 0.001 _MinScatter = 5.0 _Opacity = 1.0 _Tex { value = RSSVE/Assets/DetailTextures/DetailCloudParticle } } } } (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) EVEManager: Issue loading CloudsManager! Error: UnityEngine.UnityException: Unable to apply node! ---> System.NullReferenceException: Object reference not set to an instance of an object at Atmosphere.CloudsManager.ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 Maybe there are corrupted files? Can you try redownloading the package? Edit: there are more things to check out: [Kopernicus] texture does not exist! C:/Users/Ben/Desktop/KSP_win64/KSP_x64_Data/../GameData/RSS-Textures/PluginData/CallistoHeight.dds Probably most of the RSS Textures are unreadable for some reason. Please verify that your installation is not corrupted and/or blocked by some Windows permissions.

@g00bd0g The command module must specify the hasHibernation parameter. And most old crewed command modules never had the ability to (easily) shut down their systems. Do also note that standby consumption can generally be high: the CST-100 CM for example will require at least 1000 W while docked (that is not accounting any future changes - this value comes from current docs) and you cannot say that it will use the same tech as the 1960s technology that RO provides.

For the record, here are the Ap and Pe values of Sputnik 1 to 3: Sputnik 1: 215 km x 939 km Sputnik 2: 211 x 1659 km Sputnik 3: 217 km x 1864 km I'd say that you are doing a pretty good job with the tech from that era! Precision orbital insertions were not achieved until the Thor-Ablestar (Transit-1B) and Vostok (Korabl-Sputnik 2) launchers were brought into service. Both of them had either low thrust upper stages (Blok-E) and/or the ability to restart (Ablestar). Edit: ninja'ed by @pap1723 (should have read the whole thread...)

@TheKorbinger RSS and RO (along their dependencies) have been updated and are compatible with KSP 1.2. The updates for KSP 1.3 will take some time.

@DStaal RC integrates it's own custom category, called "Parachutes", and moves all RC - compatible parts under it. You should have a category button like this at the end of the stock category list.

@Waz I decided to test again the Terrain feature of EVE, in the hope that this time i would be able to add some detail textures to the surface of the Earth. Let's begin. Basic config setup: EVE_TERRAIN { OBJECT { body = Earth terrainMaterial { _DetailScale = 10 _OceanDepthFactor = 0.002 _SpecularPower = 50.0 _SpecularColor = 127,127,127,255 _MinLight = 0.5 _DetailVertScale = 250 _DetailVertTex = _DetailTex = RSSVE/Assets/RSSTextures/EarthSurface _Color = 255,255,255,255 _MainTex { value = RSSVE/Assets/RSSTextures/EarthSurface } } } } A very basic Terrain config file, just the detail texture is set as a custom field (the rest are automatically created by the Terrain Manager itself). Loading KSP proceeds as expected (no EVE hiccups or related NullRefs). But upon entering the flight/map/tracking station scene the texture is not applied. Opening the EVE interface and opting to reapply the config, i am greeted with the following error message: [LOG 00:07:02.243] [EVE TerrainManager]: Unable to parse config node: OBJECT { body = Earth terrainMaterial { _DetailScale = 10 _OceanDepthFactor = 0.002 _SpecularPower = 50.0 _SpecularColor = 127,127,127,255 _MinLight = 0.5 _DetailVertScale = 250 _DetailVertTex = _DetailTex = RSSVE/Assets/RSSTextures/EarthSurface _Color = 255,255,255,255 _MainTex { value = RSSVE/Assets/RSSTextures/EarthSurface } } } [LOG 00:07:02.246] EVEManager: Issue loading TerrainManager! Error: UnityEngine.UnityException: Unable to apply node! ---> System.InvalidCastException: Cannot cast from source type to destination type. at Utils.MaterialManager+<>c.<SaveTextures>b__12_0 (System.Object x) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable+<CreateSelectIterator>c__Iterator10`2[System.Object,System.String].MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[System.String].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[System.String]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.ToList[String] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 at Utils.MaterialManager.SaveTextures (UnityEngine.Material material) [0x00000] in <filename unknown>:0 at Terrain.TerrainPQS.Apply (System.String body, Terrain.TerrainMaterial terrainMaterial, Terrain.OceanMaterial oceanMaterial) [0x00000] in <filename unknown>:0 at Terrain.TerrainObject.Apply () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 From the trace-back the error seems to happen inside the MaterialManager class and, more specifically, within the SaveTextures() function. I will provide the relative KSP log files upon request. Hope that you will take a look at it (possibly for the next version?). This feature is too good to leave it broken, at least for our small RSS/RO/RP-0 community...

Close. KSP uses a different reference frame that uses a X, Z and Y setup instead of the normal cartesian setup (this is valid for anything that accepts 3D coordinates, from CoM and CoL to MODEL position and scale). To save you from some frustration down the road...

@Bornholio A fair note about the radiators: not all of them are equal. Currently, there are two different categories, the "ambient" and the "cryogenic" ones. The "ambient" can only cool down to approximately 290K and the "cryogenic" ones to 20K. Ambient radiators: EATCS Radiator Panel (Fin) EATCS Radiator Panel (Short) EATCS Radiator Panel (Long) Thermal control system (large). Cryogenic radiators: Thermal control system (small) Thermal control system (medium) Note that they are "misconfigured": the retractable radiator panels are modeled after the ISS radiators, so they should be set as "ambient" ones. A better solution would be to create "cryogenic" copies of the radially - attached panels. @Gordon Dry this "expansion" is not meant to be a mod (and that is why it does have a "release"). It is just a collection of global MM patches, PP textures and custom parts that are/were missing from my RSS/RO/RP-0 installations. The RP-0 tech tree was a first try to finally set up a non - broken one but, as i have never really played KSP since version 0.90, i did not have the motivation to finish it. TL;DR: it is not a mod, no support is provided for it, use it if you want at your own risk.