Phineas Freak

Simply enough: Your log is full of them. So, remove Physics Range Extender and try again.

@Nightside This should be patched either way since RSS uses KSCSwitcher for selecting launch sites.

What exactly is "(Almost) Real Solar System"? I am very sure that it has nothing to with normal RSS...

The installation instructions clearly document the required versions of the dependencies. In this case the installed Scatterer version should be 0.0320b as every release after it has a bug regarding upscaled solar system bodies.

Nothing. I added it purely for RO in order to make historic replicas easier to recreate, as it was config-side locked and not easily accessible. One could add it as a possible tech upgrade, like the diameter upgrades, making fairings heavier at the start.

Depends on the application. Here, setting up the orbital inclination and axial tilt is easier if you set the ecliptic as the reference point. On the point of the "LAN locking": yes, it should be available since axial tilt is actually defined by both the Right Ascension and Declination angles of the body's north pole.

Fun fact: Principia is still not perfect regarding axial tilt. If you have a spin-stabilized spacecraft (fixed rotational axis) with no means of control (no reaction wheels or RCS) then this axis will be changed upon "SOI" change. This can be just a major annoyance, especially if you absolutely depend upon that spin (e.g. planning a capture using only solid rocket motors). Looks like that this should not be a problem using this plugin!

Once more the KSP modding community proves that nothing is impossible in KSP, it just needs the right "stuff" to make it happen! Kudos to @Dagger!

@Dafni OK, this is a different issue that the one that i had in mind. I jumped into assumptions way too early, sorry for that.

Yes, use 0.0320b.

@ssd21345 PF uses a custom decoupler module for the fairing sides. It is up to the mod creators to check for the existence of such module. GravityTurn has no provisions for it while MJ supports it (if it does not work then i most probably broke the functionality while updating the fairing side code). Very Late Edit: i just did some tests with just MJ and PF. The autostage option correctly discarded the fairing sides as expected.

Since you removed the crew you did change something: the crew count. Apparently you had 10 crew members aboard and their overall mass is not negligible. Yes, it is a stock bug where the mass of a single crew member will add up to the mass of each craft part. Yes, it is a visual-only bug. Yes, it will not appear in the flight scene. No, tampering with any of the configuration files will not fix it.

Steps to mitigate that problem: Temporary remove the crew from your craft. Do everything that you want (check masses, ΔV budget etc). Add the crew back when you are ready to go. Report this KSP 1.2 bug to @SQUAD (maybe they will fix it this time).

This is how both the fairing side model, texture reference and actual texture file are set up: https://github.com/rsparkyc/ProceduralFairings/blob/master/GameData/ProceduralFairings/Parts/fairing_side_A.cfg#L9-L11 But anyway, these small textures are required for the correct operation of the fairing sides and this is how KSP has been referencing textures for a long time. No reason to drag it even further. Edit: and what the actual issue/problem is here?

These small textures are required by KSP in order to be able to reference the main fairing textures that reside in a different directory. And if you take a look at the fairing sides configs you will see that they are referenced. If you need answers for any further question about PF then just ping me.

Yes. At least the A and B classes should work as i did some (limited) testing on them. Maybe? I have not tried that TBH. I answered that on my original post (second point). KSP was not designed to handle asteroids that large and functions, like the CoM targeting, apparently breaks if you scale them up.

Asteroids received an extra patch in the KSP 1.4 version to make them bigger (E class should be at least 800 meters in radius now). The problems with the asteroids are: The colliders are not exactly perfect. The procedural nature of them does not allow a perfect collider to exist (like the usual parts have). This is also a problem in stock KSP. KSP has difficulties keeping up with the increased scale. Basically, KSP uses a fixed radius to check if the AGU can "grab" a part and this does not work for the larger asteroid classes (and that's weird since the AGU should work for parts up to 1250 meter in radius before the physics system unloads itself). TL;DR: i probably broke the larger asteroid classes for a large enough playerbase...

@hargn Why are you linking the KSP 1.2.2 version of TF? It is incompatible with KSP 1.3.1 and that's probably the reason why @BerthNerd's installation is crashing upon loading. You have to get the "dev" version (as indicated also in the spreadsheet) that is compiled against KSP 1.3.1.

Where is the "RSS-Textures" folder?

Do you use Ven's Stock Part Revamp?

Probably because the old RO configs for it do not work with the new and updated parts.

Yes, enable "Advanced Tweakables" under the KSP difficulty settings (the staged decoupler feature is part of stock and PF also uses that for the bases/interstages). There is Procedural Fairings - For Everything but it provides a limited texture set and it is not the same as the Procedural Parts one. At one point i did create a MM patch to allow so though. Of course this only applies for the base PP texture set and does not include other packs like the Ferram Saturn or the MainSailor packs.

And that is what you are looking for. RCS start disabled and they get enabled upon reaching the specified staging level. If you enable them then they will be active at all times. Now, if by "And how disable it?" you mean "how do i remove that feature and the icons completely" then you have two options: you don't... dig inside the RO folder, find the config that adds the functionality and remove it (this of course voids any warranties about RO...)

@XxLedvin25xX Since RSS is currently unofficially compatible with the KSP 1.4 branch, is there any reason for providing a version of it that breaks more things than it fixes? Did you test RSS under KSP 1.4 before uploading your version? You also removed the RSS assembly, required for some basic background tasks. Any reason why did not do a proper recompile?

@Interstate Not all CA parts are compatible with RO yet, notably the IUE ones. The rest are fully RO compatible. If you are having problems then please open a new issue in the RO bug tracker.