SAI Peregrinus

S.A.V.E does work in 1.0.4. I like to use SAVE with Jebretary, setting SAVE to only store the last two backups, while git keeps the rest of the changes.

KSP on Windows is 32-bit by default, and cannot ever use more than 4GiB (~=3.8GB). There is a hacky workaround that allows the 64-bit Unity Player to run KSP on Windows, but it's unstable for many people. Linux is a better alternative, since it's stable and 64-bit KSP actually works. The coming upgrade to Unity 5 in KSP 1.1 will hopefully bring a stable 64-bit client.

And I have a link to the Realism Overhaul thread.

That's wrong. Light from any point more distant than the Hubble length will never reach us, even provided infinite time. Also, it's not known (or even widely accepted by cosmologists) that the universe started in the same point. It's a much more common view that the observable universe started as a region of a much larger (possibly infinite) universe which expanded in the big bang/inflationary period. This page explains it well. And if the expansion of the universe is expanding (there's some evidence that it is, but it's non-conclusive) then some points which were within our past light cone at one time will move out as the space between us and the point expands. So even if you had a singularity to start you'd still get a universe larger than the observable universe, and light from some previously observable points would eventually become non-observable.

You ran out of system memory. Yes, the developers at Microsoft who made .net don't know how to spell happened. How much system memory do you have? Are you running a 32-bit or 64-bit OS? Modded KSP pretty much needs a 64-bit OS with more than 4GB of RAM. KSP will try to take 4GB of RAM on its own (more on the 64-bit Linux version), if all you have is 4GB then you won't be able to run the OS and the game at the same time. Background programs are right out, especially massive memory hogs like web browsers.

I had the same issue as Padrone. I found that TextureReplacer's default setting was to enable setting textures to not readable, unless ATM is installed. So having BAE and TextureReplacer would cause the failure, while BAE + ATM + TextureReplacer wouldn't since ATM overrides TextureReplacer and excludes */Agencies/*. Fixes that worked: Adding ATM, adding a regex to exclude Agencies from TextureReplacer's texture unloading, converting the BAE .dds flag to .png. So it certainly seems to be the problem Nightingale described.

Using this craft which has an extremely draggy but light payload, I can confidently say that fairings do NOT shield their contents after deployment. Picture of craft: Without the fairing, it flips and fails to reach orbit. With the fairing, it reaches orbit with ~1200m/s delta-V remaining. With the fairing deployed on the launchpad, it flips and fails to reach orbit. And just to be clear, it will reach orbit with no payload. Your payloads were simply so low-drag that the fairing's mass & drag was greater than that of the payload. If your craft with nothing has the highest delta-V remaining, then you shouldn't be using a fairing for that craft/payload. Stock fairings are for monstrosities with boatloads of struts holding them together, non nice aerodynamic payloads like exposed 2.5m tanks. Procedural Fairings are better, and FAR changes things so that shape matters instead of just adding up the drag of the parts, but this is about stock.

You have surface attachment enabled. Hold alt (mod on Linux) to disable it, or install Editor Extensions and use that to disable it.

Yes, I said that. The distance your craft gets to is irrelevant. The altitude of perihelion is what matters. That has to intersect the "surface" of the sun's atmosphere, which is at 600km. This works for any other body: the periapsis of the orbit must intersect the surface of the atmosphere to be considered a suborbital trajectory, or the surface of the body if it has no atmosphere. Clearer?

They're perfectly possible. Not particularly safe, mind, but possible. Gasoline + gaseous oxygen is an "easy" combination. It needs an ignitor, as the fuels aren't hypergolic. http://majdalani.eng.auburn.edu/courses/09_propulsion_1/ref_roc3_How_To_Design__Build_And_Test_Small_Liquid-Fuel_Rocket_Engines.pdf That's old, so its safety procedures are OK but out of date. For anything involving high-powered rockets these days I'd set up the launch control remotely using radio control, with a camera to watch the launch. And a mechanical "pull this string and all the fuel/oxidizer cuts off" shutoff.

The book "How to Design, Build, and Test Small Liquid-Fuel Rocket Engines" (Out of print, PDF here) has a good test stand design. Note the use of a mirror to see the test, so that you can be behind strong blast shielding.

Unlikely. Expendable rockets don't have to have nearly as strong a structure, and they also don't have to have nearly as much fuel overall. The only really expensive bits of the lower stages are the engines, something like SpaceX's plan to re-use the first stage is likely to be far cheaper than any SSTO for a given payload to orbit. An SSTO has to get its payload + its ENTIRE rocket to orbit, while a staged rocket only has to get the payload and uppermost stage to orbit.

Distance is irrelevant. The trajectory just has to intercept the sun's surface. Retrograde ejection from Kerbin is correct. Delta-V looks about right. For low TWR rockets and long burns, I like to chain a few short burns. So make a node, get it to the point where it will be a short enough burn (< 1 minute), then make another node a bit further on the new orbit, etc. If you do it right you'll get a reasonable projection of where the single long burn will send you.

If/when I have kids, I'll use parental control software. If they can't bypass it I'll be very disappointed in them.

Learning to use FAR's stability analysis window is pretty much necessary for this. If you're using stock aero you should just get used to trial and error testing, and getting a feel for what works with your piloting style. With the FAR tools you can actually see if something will work with your expected flight profile.

FAR + RealChute. You get different chute materials, usable for different purposes.

It's very fast (for calculations that fit within the size of the abacus, of course). Comparable to an electronic calculator once you're used to it. And it makes mental arithmetic easier once you can visualize the operations.

Graphic Memory Monitor + SAVE is my preferred solution. (Actually I also use Jebretary for actual backups, and just use SAVE to autosave every 5 minutes. That saves storage space and also backs up .craft files.)

Geschosskopf is largely correct, but it's worth remembering that Remote Tech can be configured, so signal delay can be removed and probe control can be enabled when a link isn't present. So it can work effectively like Antenna Range with different antenna parts. AR is still simpler for career mode though.

It's not quite free, since you have added recovery costs, and need to choose to land somewhere other than the KSC. But if your goal on landing from orbit isn't to touch down on the helipad atop the VAB you're clearly not aiming properly. In all seriousness it's good advice. And you can get grasslands, shores, and ocean science easily without any significant recovery cost loss. And the recovery costs are pretty minor for the smaller early-game landers when the miniscule amounts of science you get from Kerbin matter.

KkK kK kKkk KKK Kk k kk kkk k Kk KKK kkK KKk kkkk kKK kk K kkkk KkKk kK kKKk kk K kK kKkk kk KKkk kK K kk KKK Kk kK Kk Kkk kK kKKk kKKk kKk KKK kKKk kKk kk kK K k KkKk KKK Kkk kk Kk KKk kKkKkK But I suppose Morse code composed of "k" and "K" instead of "." and "-" might be taking it a bit too far.

Yep, searching through all installed /flags folders and converting the textures from DDS to PNG allows contracts to reappear. Removing Texture Replacer or adding ATM Basic (but not aggressive) also worked for me (before I did the conversion).

The way I do it (interplanetary missions) is launch to LKO, then to low Minmus orbit where I dock with my fuel station and fill up the rocket, then go interplanetary from there. It makes the initial launch lighter and the fuel comes from the Minmus mining outpost, which also saves Spesos in career.

The way I do it is to have a small rover/biome hopper that lands carrying a narrow band scanner and a surface scanner. I drive it around until it's at a high concentration of ore, and then I swap to the miner, target the rover, and land nearby. I supplement this with the SCANSat mod, so I can get very nice detailed maps instead of just biome maps and a temporary popup window.

http://www.orbitsimulator.com Free n-body gravitational system simulator.