Phineas Freak

For long term, deep space missions using LH2, we really need active refrigeration units. After reading the notes for 1.0.5, the thermal improvements mention that a system like that will be possible, so i guess that we can wait a bit more and find out.

The S-IV did not have APS modules, only the four ullage motors in a quad symmetry. I may be wrong though. Your work on the Saturn I is awesome! Keep it up!

To all people that made the Solar System experience real for KSP! There is no way that i can manage to even try and play stock - sized KSP again... Keep up the good work lads! And something that Rothank over at the RP-0 thread motivated me to post since i have been working on it for a while. It is not perfect by any way and there are many things left for improvement... (Images are a courtesy of Kronal Vessel Viewer)

Astonautix mentions a Vac ISP of 300s but the highest performing Agena engine doesn't exceed 291s. With a quick replica i made (671 Kg empty - 6883 Kg gross) i can get 3m and 55s worth of burn time at an ISP of 291s. So 4m 24s doesn't sound unreasonable with a better ISP value. I found another reference from Astronautix that puts the gross mass at 7160 Kg (meaning 4m 4s of burn time at 291s ISP). Also for the Atlas, you can shorten the "skirt" for the booster engines by splitting the main tank into two and moving the interstage adapter further down the main body. Then you don't need to use a custom fairing texture and the only problem is to make a fairing with "fuelCrossFeed = true" to avoid fuel ducts for the booster engines!

Fuel dumping in fact is a requirement for every upper stage (either with hypergolic or with cryogenic fuel) to vent excess fuel (passivation) to avoid the tanks becoming ticking bombs in space and contributing to the "space junk" problem with thousands of small debris. The link that sumghai provided is a perfect example of a Centaur passivation.

Steam screenshots for KSP are stored under the path: C:\Program Files\Steam\userdata\[USER_ID]\760\remote\220200\screenshots at least for Windows installations, not sure about Mac or Linux). If i remember correctly, you can also use the Steam screenshot manager to find where the screenshots are located (via a "Show on Disk" button).

RSS includes a bugfix for the "crash when reaching orbit" bug. You can grab it from the RSS github repository and use it for any other stock system rescale. The alternative is to create a Module Manager cfg file inside your GameData folder and place the following inside that file: @Contracts { @Survey { @TrivialHomeNearbyRange = 20000 @SignificantHomeNearbyRange = 25000 @ExceptionalHomeNearbyRange = 30000 } }

If you are referring to the delta - v map by Nebuchadnezzar then yes, there is an error with the GSO altitude. You must subtract the Kerbin radius from the current GSO altitude to get the real altitude value.

A quick way to "rescale" a real life engine for the stock KSP is to first multiply the engine mass by 0.262 (equal to 0.64 ^ 3) to get a "rescaled" mass and then use the TWR value of the real engine to find out the thrust for the stock KSP. The last step can be accomplished by using the TWR equation but reversed: EngineThrustRescaled = EngineMassRescaled * (EngineTWRReal / 100) I used this method to create a lot of real life launch vehicles before starting tinkering with RSS. I was impressed to find out that the Atlas V and Delta IV replicas i made had the same payload capability as the real ones (of course on rescaled payload masses). The only problem is that i have not found a way to "rescale" the Isp values yet. Usually i play around with the ASL and VAC values for the best possible balance .

From a first look the development version of the Atlas V works perfectly! I built and launched an Atlas V 401 for a quick trip to the Mun with an FL-R1 RCS tank as a payload. No problems were detected. It flies like a charm! I will try later with different launch configurations to confirm that everything works 100%. Tested on a Stock + SmokeScreen + LaunchersPack (Atlas V Dev) installation.

I recompiled the new source code, replaced the old DLL build and now everything works like a charm! Thank you for the quick fix!

It seems like that the latest changes in RSS broke the "HideGroundStationsBehindBody" option. If this option is enabled in a Stock + RSS + RemoteTech installation and upon entering the Tracking Station scene or launching a vessel, Remote Tech fails to render the ground station points or the radio link lines. The debug log is spammed continuously by the following nullref (until exiting back to the Space Center): NullReferenceException: Object reference not set to an instance of an object at RemoteTech.NetworkRenderer.IsOccluded (Vector3d loc, .CelestialBody body) [0x00000] in <filename unknown>:0 at RemoteTech.NetworkRenderer.OnGUI () [0x00000] in <filename unknown>:0 (Filename: Line: -1) The problem is that Remote Tech will reference "Kerbin" instead of "Earth" when checking for the celestial body name (since RSS changes all planet names), since it is hard coded in the NetworkRenderer.cs OnGUI() function.