Phineas Freak

@NSEP Although i do not recommend downloading and installing RSSVE at the moment, you can still access it from the GitHub repository.

Not before: Making every RO dependency available via CKAN. The release of KSP 1.3.

@Stongduke This is a known bug with RSSVE that i am currently trying to fix. Out of curiosity, what OS are you using? If you are using Windows, do you enforce DX11?

Since RP-0 testing is now a thing, i will be providing a tech tree at regular intervals, as well as updating this post. Note: the tree is required for all the KSP 1.2.2 RO changes. Latest build: 02/06/2017 - 05:58:14 UTC (Click the "Raw" button and right-click to save the page, it will prompt you to save it as "Tree.cfg"). Edit: link removed (RP-0 is now compatible with KSP 1.2.2 and has a proper release. Head to the official RP-0 GitHub repository to download the latest version).

@msnbcorp What @maculator means is that you need to have mods installed that actually provide toolbar buttons. Toolbar is designed as to not appear in a scene (Space Center, Tracking Station, Flight/Map View) if there are no mods providing said buttons. A nice anti-cluttering feature.

@EpicSpaceTroll139 Use a text editor that can undestand UNIX line endings, like Notepad++. The Windows Notepad sucks *%($.

I am aware of that (the body radius was just an example) but It seems that using realistic ratios breaks some things under DX11/OGL. Example: dropping the Earth Rt/Rg ratio from ~1.0219 to ~1.0141 somehow fixes the "blue sphere syndrome" (the Rl/Rt ratio does not seem to affect anything though). What i am more worried/confused about is why the older gas giant configs and textures are not working under the 0.0300 version of Scatterer vs the 0.0255 one. Bodies with smaller radiuses work just fine (and most of the user complains were about them) but even if i fix those, the rest will be broken. Edit 1: i am mostly sure that i have been doing something really stupid all this time... Edit 2: most of the RSSVE Rt/Rg ratios are in the range of ~1.022, with very small variations. The stock ones are extremely close to ~1.014. Which gives?

OK, so i finally found some time to sit down and try to pinpoint the cause of the featureless spheres. And i did not like what i found. After discarding the current configs and creating some new ones for testing, one minor problem with Scatterer was found: it does not like the real life values, not without some tinkering. It is possible to divide by 2 most of the critical values and set the "experimentalAtmoScale" to be 2 (so that the result will be visually the same - something similar was done in the RC2 release). This fixed the smaller bodies (and most notably Earth and Mars). Now, onward to the gas giants. Here is were everything starts to break down: the radius values are at least 10 times more than the Scatterer Config Tool can handle (you get a "black planet" bug in the preview window). The solution for the Scatterer Config Tool is an easy one: to divide everything by 10. And now you finally load the config and the textures in KSP itself and...you are greeted with the same problem. What can we do to check if it is us who are making the things worse? Time to test the previous working configs from the RC2 release. They should be working, right? Wrong! Even the previous ones fail to work. Until you fall back to Direct X 9, then everything works as expected. Is this a Scatterer v0.0300 bug? I do not know. But what i know is that every user operating under either Direct X 11 or OpenGL will not be able to use RSSVE. But, there is a reason why @blackrack says: Judging from the fact that the mod fails to achieve what it is written in the box, i will remove temporarily any download links to it and most probably also lock this thread. Until a solution is found it is pointless to continue distributing it.

@Carraux, @GenryRar, @Theysen I have made some general fixes for this engine, mainly porting it to the global engine config system and tweaking it's size (although for the latter i will have to get some feedback), including the plume fixes. You can grab the changes (PR) from the main RO repository. Edit: @RiggerLee Your DropBox link is private so i cannot view the log.

Interplanetary is relatively easy compared to Lunar direct ascents. They usually have a launch window spanning several days (instead of just minutes), since you don't need to be well aligned with the plane of the Moon and larger phase angles. Minor corrections done early can also fix some of the launch trajectory anomalies. The most difficult thing would be to have an Altair or STAR motor as an escape stage. Now...you have to trim the trajectory and the payload mass to be just right. Not too little and not too much.

@ether_plumber If you read earlier responses in this thread you will find that many other users have also encountered this bug/problem. Unfortunately, i cannot do something about it as it is not possible to reproduce it.] One question though: do you use Windows? And if so, do you enforce alternate renderers like OpenGL or DirectX11?

Umm...no: Source: Spaceflight101 And another one, "more official" (page 30): http://www.boulder.swri.edu/pkb/ssr/ssr-mission-design.pdf Generally, direct ascent profiles are so limiting that were done only because there was no other way. Limited ignitions, not reliable engines, tight mass limits were some of the factors of the early Pioneer, Luna, Surveyor, Mariner, Ranger (and even more) missions. IIRC the last mission to use something like that was back in the '60s.

@Arrowstar No problem, i understand the limitations. Still, even if you only implement circular parking orbits, it will be far better that my current approach for windows like that.

A log file is always created, even if KSP crashes after 1 second. It will be placed under your KSP installation folder (e.g. "KSP.log" or "Player.log"). For more information about how to submit the required files:

Oh god, this will make direct ascent profiles so much easier...thank you very much for adding that feature!

Well...that's your problem. You cannot delete a planet pack and expect any crafts that are orbiting/landed/splashed down on any of the mod bodies to continue to do so without the bodies themselves. KSP removes all craft files that are missing parts or are placed under the influence of a non existent body. If you don't have a backup of your save then you can safely assume that they are gone for good.

@RiggerLee This is a "not-a-bug" MM warning (that it has been fixed for KSP 1.2.2) but even under KSP 1.1.3 it did not cause a freeze or crash. Can you post some .log files so that we can take a look?

@PmThay Nowadays the required PlanetShine configs are a part of the RealSolarSystem mod (under "RealSolarSystem/Compatibility/PlanetShineColors.cfg"). It was originally part of the PlanetShine distribution (as @Galileo pointed out) but it was then ported to RSS itself.

@TauPhraim This means that you have more than one CC assemblies under your GameData folder (from another update or from a bad copy & paste operation). Check to see if there is another CC assembly and if so then remove it.

Not without an update, no. Considering that it is the pre-release (meant to be played without any mods for testing) you won't find such an update either. And, please, do not start bugging @sarbian about it.

The stock solution would be a ModuleGenerator with a negative EC output: MODULE { name = ModuleGenerator isAlwaysActive = True OUTPUT_RESOURCE { name = ElectricCharge rate = -1.0 } } You can also set it to be toggleable by the user if required. Change the "rate" parameter to change the power consumption.

Since the "radius" value controls the "offset" of the VertexHeightOffset and VertexHeightOblate mods then start by altering the radius multiplier.

@AWESOMEPIEMAN No, replacing any part of the KSP files is neither required nor supported. This was done in the early days of KSP to add custom sun flares, something that it is done nowadays by both Kopernicus and Scatterer. You are probably suffering from the same bug that other users have. Unfortunately, i do not have the slightest clue on why this affects certain users and not others. Considering that you are using OSX (OpenGL) there is a very high chance that you are also affected by it.

Pitching in to leave my info, along @liquidhype and @rasta013: Polyus was bulit with the FGB as the main propulsion and control system. The FGB used a pair of KRD-442 engines. This is a hypergolic engine with the following stats: Propellants: UDMH/NTO Thrust (VAC): 4.38 kN or 0.17 kN O/F Ratio: 1.76 (high thrust), 1.58 (low thrust) Inert Mass: 52 Kg The same engine is used on the Zarya module. Source: Exponenta Educational Mathematical Site - Aeroengines (page 85)

No, they are scaled down to work for stock KSP.