Phineas Freak

I am not the original author of that mod, i was just maintaining it for my own uses (and until LGG took over it). Unfortunately I have absolutely no idea how KSP nodes work internally and the Procedural Parts code for them is beyond my comprehension.

As far as i can remember this issue existed since KSP 1.1 (1.1.3 to be exact) and happened in every KSP version afterwards (rarely though). KSP 1.6 broke it even further and, as it seems, KSP 1.7.1 was the last straw.

And you are assuming that this was an assured fix for that bug. Note how i said "try and see" instead of "add this and it will fix it". You are not alone. I had the exact same problem and i ended up just remaking every Scatterer config + texture from scratch, although some things are still incorrect (and i still do not know what the actual fix was). Stick with 0.053 for now.

NodeHelper (10 char)

Kerbal Joint Reinforcement is recommended for these parts. They were made in 1:1 scale with IRL masses, meaning that they cannot easily be handled by KSP. Or, as @Wirelex says, just auto-strut everything with everything.

That is actually something that i forgot to implement back in the KSP 1.4 days. I was envisioning a similar system to Procedural Parts (named predefined shapes) but: being able to tweak the fairing shape in-game (as it is currently done) being able to have custom pre-defined shapes in a list (something that Procedural Parts is missing) Would require some rework of PF (and extra config files that are user-friendly) but i think it can be done.

There is a specific PF decoupler module that a mod must look for in order to implement that: ProceduralFairingDecoupler. MJ has implemented the proper code to check for that module but GT is missing that.

Yes it is. Do mind that MFI will not be bundled in any future releases, since Kopernicus is the only mod that has the right to directly distribute it. Current releases do bundle MFI but with a catch: the MFI assembly resides under the RealHeat/Plugins directory and not on a separate "MFI" folder. Meaning that: you will get two MFI assemblies out-of-the-box (one from the "MFI" redistribution itself and one from RealHeat) when MFI gets updated you end up with two different MFI versions, possibly conflicting. I can only assume the end result...

Well, there's your problem: RO does not support any KSP 1.4+ versions.

Let me guess: you are using a Scatterer version that is newer than v0.0320b. If so then you are affected by a very known bug about rescales (now fixed).

KSPAPIExtensions has been deprecated for a long time now (most of its features were implemented by KSP itself between the KSP 1.0 and 1.2 (1.3?) releases). Why KJR ended up with that dependency? BTW, the root KSP folders (like "PluginData") are leftover artifacts. Mods should not assume that these folder are valid (or even exist).

Feel free to do so. The end user (as with all mods for every moddable game out there) is free to do whatever he/she wants in his/her own installation. But in the context of an official RO release such things are not valid. There is also a Procedural Engines mod that allows you to create whatever engines you want.

Engine TweakScaling is not and will probably never be supported for a very simple reason: this is Realism Overhaul. The RO engines have the exact stats, including dimensions, as the IRL counterparts. I do not think that TweakScaling an F-1 engine to have the size of an LR91 would be a very...realistic thing to do. For generic/structural parts then sure. In fact, it would help immensely since RO creates multiple part clones to cover these gaps, creating a mess in the part lists.

Of course. The fact that the KSP-RO team maintains the mod does not mean that RO is required by any means. The RealPlume-StockConfigs repository is also part of the KSP-RO organization but of course has nothing to do with RO or the rest of the realism mods. Probably because it was just officially released. Speaking of which, @pap1723 could you create a new thread for KJR? This one has run its course and the OP cannot be updated anymore.

The classes in the module cannot be loaded --> Windows 10 #@%&*! up again (as usual) and set very restrictive access rules for every file under your KSP installation directory. Also apparent on MiniAVC: [LOG 12:25:48.226] MiniAVC -> System.IO.IOException: Sharing violation on path C:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\000_ClickThroughBlocker\MiniAVC.xml Make sure that the KSP folder has the correct access rights.

I also noticed them but no matter what value i used (up to 7500000 meters) would fix it. Weirdly enough, less than 2000000 meters are required for RSS (a larger body that even 10.6x scaled Kerbin) so i assume that something else is causing that (see final note). Saw the same thing with just the default Scatterer distribution and a 10.6x rescale (see final note). I...guess so? Give me some time and I'll whip something up. Note: I would guess that both of these are caused by the fact that the default Scatterer configs/textures are not meant to be used "as-is" for rescales. Edit: new version is up, now allows the user to define a custom clip value (located under "FarCameraFix/Configs/FarCameraFix_Settings.cfg"). Pinging @evileye.x for further testing.

I fail to see how the effects are not rendering, i can clearly see the atmospheric fade and the surface post process effects. But, in any case, my post was not a reply to @iGGnitE's issue. Edit 1: and a quick bug fix plugin for testing (unzip it and copy/move and merge the "GameData" folder with your KSP "GameData" folder). (license, readme and source code files included) Edit 2: if you downloaded the file previously then re-download it, as i have fixed a very minor but stupid error.

So, let's convince everyone that this is a far camera plane clipping issue. Testing in KSP 1.6.1 with: RealSolarSystem v14.0 Scatterer v0.0540 RSSVE v1.4.5-1 Exhibit A (far camera clip value 1875000 meters - default RSSVE value): Exhibit B (far camera clip value 675000 meters - randomly selected value): Note the horizon appearance. For the record, the default far camera value for KSP is 750000 meters. One solution for this issue could come from Scatterer: just have a configuration option (like the "nearClipPlane" parameter - let's call it "farClipPlane") that can be set by the visual mods themselves. Or, internally set this value by default to be larger than ~1000000 meters (it's not like it affects anything for "stock" CB scales).

No. RP-0/1 depends upon RO.

Your installation is missing some RSS CB textures: Are you sure that you have installed the correct RSS Textures pack?

@mcfunk0017 Try and add the following two parameters to the RSSVE RSS patch and see if they fix it: %cam00FarClip = 1251.0 %cam01NearClip = 1249.0 And yes, you guessed correctly about the far clip plane.

A full list with the available RF propellants would look like this:

It is a general issue when celestial bodies are rescaled (usually upwards). The stock KSP camera values are good enough for stock but not for custom planetary systems. Camera clip values must be set via a plugin. Not sure about Sigma Dimensions but RSS (~10X rescale compared to stock) has provisions for setting these camera values for that reason.

Scatterer does...scattering effects. You are looking for either TextureReplacer (mainly for visor reflections) or TexturesUnlimited (mainly part reflections). If you mean the missing sphere edge then it has absolutely nothing to do with Scatterer (hint: the "camera01" far clip value must be increased).

You should take a look at the RSS thread . Hint: it is called KSCSwitcher and it is a hard dependency of RSS.