Phineas Freak

Ask and you shall receive.

The mod in question has to be explicitly supported by RP-0 (and RO) anyways. There is no reason to display parts in the tech tree if have not been correctly set up in the first place (placing & pricing). Besides, the RP-0 tech tree is fully customized: adding tech tree nodes for the sake of allowing incompatible parts to show up is not going to help anywhere. If you are talking from a dev standpoint ("how to be sure where the parts should appear?") then you will have to consider: the TRL of the part the similarity with other parts that are already supported the overall gameplay balance With that information, finding out the proper tech tree node is an easy thing to do. Pricing is a completely different thing though, most of the times you have to fudge things...

@FreeThinker What compatibility reasons?

@jrodriguez Logs? Mod list? Clean install? Asking because i have made a ton of changes and just overwriting the files/folders will not work.

OK, this joke is getting out of hand: there is a mod called Module Manager and it is developed by Sarbian (not Squad!). What you are seeing is an easter egg for the aforementioned Cat Day. Apparently you have installed a mod that includes MM... Edit: aaand ninja'ed by almost everyone...

No, but you are using Module Manager.

Wait until the local conputer calendar reads 23/02.

Yep, you got badly hacked by @sarbian and his Japan Cat Day...

@jrodriguez There is a mod version table available in the OP that documents every dependency and the required version. Currently, the KSP 1.3.1 dev branch is what you should use, along with Kopernicus 1.3.1-3 (later versions break RSS) and Scatterer v0.0320b (later versions break the scatter effects in low orbital altitudes). Since you are not providing any useful information, i can only say that you did not install the dependencies and/or RSSVE correctly. The "Support" paragraph in the OP lists what is required in order to get support.

@JadeOfMaar's reply is spot on: find the SRM datasheet that includes the thrust curve graph, install Amazing Curve Editor and try to recreate it. It is going to be a bit messy and might take multiple tries to get it right but i do not see any other way to easily create curves (not at least without using external programs).

@ebigunso Known issue with RF. There is a PR awaiting review (#140) that supposedly fixes that bug but there has not been much progress on KER lately so...

The NK engine family does not have gimballing capability since, as other users mentioned, the N-1 LV used differential throttle for steering. As @Pappystein also mentions, OATK had to create a custom engine mount for Antares that includes gimbal actuators, moving the entire engine structure. Now, under stock KSP there is absolutely no way to manage either of these things. So, you cannot blame @Alcentar for his decision of adding gimbal transforms to the engine. Hell, even under RO we configure them to have gimballing, even though in reality they did not have such capability! (I could also make a case of the wrong S5.92 engine gimballing. The Fregat US, similarly to Antares, moves the entire engine and does so in the X-Y plane, not by changing the thrust vector angle. Something that is also impossible in stock KSP and difficult to achieve with IR.)

@Ct9ars If you are using the latest version of Scatterer then @Laminator is correct, you need to revert to the previous version. There is a Scatterer bug that affects rescaled planets. Blackrack has been notified and a fix is underway.

The current master branch of RSS is not compatible with the old RSS Textures pack, since it also includes Vesta, Ceres and the major moons of Uranus. You have to download the ScaledRSS-Textures pack by @pap1723 and replace the old texture pack.

@cgwhite4 Rebuild means recompile for KSP 1.3.1 (since the previous assembly was built for KSP 1.2.2). And there has never been a problem with RH. It works as expected under KSP 1.3.1.

Hi blackrack! Thank you very much for the new release! Unfortunately, i have to file a bug report. Relative information follows: I believe @Theysen also came across this issue so i will tag him in order to also provide information if/as required.

@itsaps You could also "MM clone" one of the linear RCS thrusters, lower the Isp values (since valves do not have too good of an Isp, probably around 50 to 70 seconds) and reduce the thrust value to a minimum (so it will act as a non-propulsive vent - or put two of them facing against each other). You can then configure the propellants like it was a normal RCS thruster and have it set to an action group for toggling. Ideally, you could extend that by using custom engine configs to cover all available propellants (current RCS thruster definitions only include a limited range of gases, monopropellants and bipropellants). Edit: IIRC RCS are also "global", so you do not need to worry about cross feed.

Then there is either a graphics compatibility problem (the fix is actually a workaround and not an actual fix) or you did not change the correct line. Either way, as @DrLicor says, i will need the log files, along with your ModuleManager.ConfigCache file.

Follow the steps and you will be able to mitigate the bug.

As noted in the OP: You were unfortunate this time, since this bug happens even when the correct mod versions are installed.

There is an option to "Use RCS for ullage" under the MJ settings. Enabling that will ensure that MJ will check the propellant stability before trying to ignite an engine. So, you can program a maneuver node via RT and MJ (theoretically) will cover everything else.

@Varunz16 Please take a look at the OP. Read the DirectX11/OpenGL section and how to mitigate the "blue sphere" bug. In that note, i am happy to announce though that i may have finally found a solution for that specific bug (that does not seriously affect the overall visual appearance). It also fixes the hard Earth terminator. @gemini4 There is also another thing that you could try: open the textures.cfg file (under the RSSVE/Assets path) and delete the following lines: OBJECT { name = RSSVE/Assets/MainTextures/EarthCloudsLow mipmaps = False isCompressed = True }

@Kobymaru Some parts are supported (IIRC Coatl Aerospace and VSR) but there are still many parts left to be configured. For now it is not possible to fully replace RT with CommNet, since you will be lacking all the useful tracking stations. Ullage with RT: that's...difficult, not without MJ configured to use RCS for ullage. RT does not have an option to explicitly use RCS as engine(s) but i am sure others will have some workarounds for that.

So...let's clean up some of the questions and bug reports, shall we? @Observe and @Heady978: Can you confirm that Kopernicus was the culprit for the "flying tiles" ? @J-2 Lover and @Gousaid67: This may or may not be a bug from my config side. I have seen the dark band happen before but most of the time was difficult to actually see it. But i can confirm that making some minor corrections fixes that so consider it fixed. @flart: Yes there is, check out RSSVE-Lite (it is also linked in the OP). @Grabek: As other users report, RSSVE is not officially compatible with RSS. And a general note: until RSS is considered compatible with KSP 1.3.1 then i will not release a newer version of RSSVE. RSSVE depends on both the RSS binaries (.dlls) and correct body naming configs. The current official release will not work under KSP 1.3.1. Unofficial recompiles and/or patches will not be considered or supported. Having said that, users are free to use Now, your problem seems simple enough: if Scatterer cannot locate the textures defined by the Scatterer configs then you will get the exact same result. Since you are not providing a log file, i cannot comment on anything else. Check your installation and your folder permissions (if you are using Windows). @Damien212: SpaceDock has every Scatterer release under the Changelog tab. Both the 0.0320 and the 0.0320b releases are listed. @mystere9: Unfortunately this is something that is not currently fixable. I was able to "cover it up" in the previous versions but there are some complications regarding the RC4 release: if i use the hack that i was using to "fix" it then the EVE cloud integration feature will break. So, for now, it is better to have these terminators than a completely broken view of the atmosphere as viewed from the surface. I will have to congratulate you though, you are one of the few users that actually followed the instructions and provided logs, along with sample screenshots! @brooklyn666: This is how Scatterer camera setup works (at least up to the 0.0320b version). As for the fix...do not increase the camera FoV! @gemini4: You can play around with the EVE detail distance parameters. Do note that you will face extreme detail texture tiling up close if you decrease the distance too much. Also, for the terrain textures: other users have mentioned performance loss before but i thought that i fixed that (no reports upon the release of RC4). I will make sure to make them toggleable, along with the EVE volumetric clouds, for users that do not like these features. @reloutino: I have not seen that before but i can make a guess: the Sun is perpendicular to the rings (as they cast no shadows) and they may appear unlit (or black). Test if timewarping (i.e. Saturn changing it's position relative to the Sun) "fixes" it. I guess this is a bug (limitation?) of the ring shader? @BlackDragon Korean: Missing Saturn rings means that Kopernicus failed to load the ring shader. Without a log i cannot see if you are using the correct Kopernicus version (the KSP 1.2.2 backports fixed a lot of these ring issues - had the same problems in my dev environment) but that would be the first thing to check out. A bug report that i will have to make is that the TextureReplacerReplaced reflections are currently broken when using Scatterer (horizon flashes when the PQS to SS transition happens). I am sure that other users will have reported it so i am leaving this here as a note for future reference.

Yes, more specifically the TimeWarpFixer.cs class of the RSS assembly. Nothing "broke" or got changed in KSP 1.3. You just have to: Update the RSS compatibility checker for the KSP 1.3 version Recompile the RSS source code against the KSP 1.3 assemblies via your favourite C# IDE (Visual Studio, SharpDevelop, MonoDevelop to name a few). Replace the existing RSS assembly with your new one Profit! If you are willing to use KSP 1.2.2 (probably should until a KSP 1.3 compatible RSS version is released) then none of the above steps are required.