Yakky

The other possibility would be to reduce each asteroid's polygon count to 1, eliminate textures, use simple 1-bit black and white graphics, and make all asteroids simple 2D outlines with sharp corners so that rendering lots of them wouldn't overly tax the system resources. That's the way they done it back in the good ol' days.

Good point. Either prioritize the controlled vessel, or else have both spacecraft spontaneously explode and destroy the universe. If the destroyUniverseOnAngleSnapMismatch flag was set to FALSE, then the former.

Sumghai - you've clearly thought about this a lot. Has there been any feedback from Squad on your proposed enhancements?

This one is fairly simple: It would be terrific to have an optional rotational angle snap feature available on docking ports in space, similar to angle snap in the VAB/SPH. It would greatly aid in precision on-orbit construction projects like ring space stations or any situation where the constructor wants perfect symmetry or is feeling an?l-retentive. As one example, without angle snap, completing a ring station like this is very challenging because any rotational misalignments cause the ring to deviate into a 3D helical (corkscrew) shape that won't be able to close into a perfect circle.

I've been worried about this. I deploy the big solar panels before docking to give me a larger visual aid on the docking angle. It would be nice if the docking ports had an angle snap capability like the vehicle assembly building.

Just for fun, I started building an orbital ring space station out of all stock parts. I used the rotation gizmo to bevel the docking ports slightly, creating a uniform angle between each segment. I built a launcher that can boost twelve segments into orbit at a time (four groups of three segments each). Note that each section has a little probe core with a torque module and some thrusters to help maneuver the sections into alignment. Aligning the segments is a pain, but manageable. Eventually the probe core assemblers will be removed, revealing a whole ton o' clamp-o-tron docking ports.

Yes! I've had several of these and they are always the most dramatic. My favorite was a post-launch staging accident in hard career mode (i.e. no saves, no reverting) with FAR/DRE on a craft that had no re-entry or landing capability. When I jettisoned the first stage strap-on boosters at about 20km and 800 m/s, they impacted the second stage and destroyed its big Skipper engine. That left the third (interplanetary) stage, which had a puny TWR of maybe 0.25 and was never intended for atmospheric use. How the hell do I save the lives of my intrepid Kerbonauts? The TWR was not high enough to attempt a powered splash-down in the ocean and there were no parachutes. The basic strategy in this kind of situation is pretty obvious, but it was nail-biting executing it. Fire up the engine, jettison every scrap of extra mass you can ditch, aim prograde and a little up, and hope you can gain enough speed to reach orbit before you fall back into the deeper parts of the atmosphere. I dumped two small and perfectly full strap-on fuel tanks that had been intended to help get the craft to Duna, leaving me with an improved TWR but vastly less fuel. I called upon the reaction-control thrusters to augment the craft's total thrust by holding down the "H" key, which gave a tiny bit more acceleration and helped deplete more mass. The craft passed apoapsis somewhere around 65 km and 2000 m/s and then started to fall back to Kerbin. I thought about having the Kerbonauts bail out and use their jetpacks to propel themselves into orbit, but I realized I would at most be able to save one since I could only "fly" one Kerbonaut at a time. Fortunately, we were nearly fast enough by then to reach orbit, so I kept the Kerbals strapped into their seats and kept accelerating like mad (relatively speaking). We bottomed out somewhere near 55 km before finally picking up enough speed to start rising again. At that point I knew I'd made it. Whew! I later mounted a rescue mission to come up and recover the guys. It pressed onward Duna without further incident. - - - Updated - - - Another good one: Re-entering a spaceplane in FAR/DRE that starts off OK but then hits that dicey unstable regime around 15-20km and mach 2-3, and sometimes tumbles out of control. Assuming you don't lose too many wings and controls surfaces to atmospheric forces, it's a fight all the way to the ground to try to recover and land safely. Sometimes the craft becomes flyable again as it goes subsonic, sometimes not. It really makes you feel like a test pilot in those situations, especially if you manage to recover a damaged craft that has lost a few wing panels and/or control surfaces. Even assuming you do recover control, you still have to deal with landing. Usually the big tumble has taken you out of range of the runway, so then you have to deal with finding a flat patch of land to put down. I've had several cases where I'm able to recover but then can't stick the landing because the terrain isn't perfectly flat. This is one reason I don't usually trust myself with SSTO spaceplanes when playing hard mode.

Have you landed a giant mechanical cow on the Mun yet (otherwise known as Operation Hey Diddle Diddle)? That is an important part of any space program, and has only been accomplished once as far as I know. http://forum.kerbalspaceprogram.com/threads/24599-Post-your-Rover-MEGATHREAD?p=1293083&viewfull=1#post1293083

Or if you have RCS, do the fine-tuning with RCS rather than main engines.

I cannot quite tell from the video if this is applicable to your plane or not, but: Remember that if you have fuel tanks connected in series, the fuel will drain from the farthest tanks first. In many configurations, and it looks like maybe in yours, the farthest tank is in front and will thus drain mass out of the nose first. This means when you re-enter with a small amount of fuel left over, that fuel is usually toward the back of the spaceplane where it may be pulling your center of mass farther aft than you want. Sometimes you can solve this problem by simply transferring the leftover fuel toward the front-most tank before re-entering the atmosphere. BTW you can also use this trick deliberately, by reserving some fuel to use as ballast during re-entry and pumping it around to wherever balances out the spacecraft. I will sometimes deliberately put a small fuel tank at the very front of the craft so I can pump whatever leftover fuel I have as far forward as possible to help manage my center of gravity.

If it doesn't, you can circularize a highly eccentric orbit (one that extends out nearly to the edge of the planet's SOI) for not too much delta-v. That will then allow you to then adjust the inclination without too much delta-v spend. The key is always to be going as slowly as possible when you change your inclination. You do that by orbiting far away from the planetary body, either in a highly eccentric orbit or if necessary in a great big circular orbit.

I also lost fourteen Kerbals within five minutes to a pair of tragic stage separation mishaps. It was a mission to fulfill a 7-kerbal Munar base contract. Due to launchpad weight constraints, the craft had no Kerbin re-entry provisions like parachutes. The game plan had been to get the base on the Mun, sit for 10 seconds to get the contract points, then get back to Munar orbit or maybe all the way back to LKO if fuel allowed, and then come get the guys with a subsequent launch. My very carefully designed craft lost its second stage when some separating 1st stage boosters collided into it and blew up its big orange fuel tank. The third stage, unfortunately, had neither the thrust to weight ratio to limp into orbit nor perform a powered landing back on Kerbin, and all seven little guys perished when their craft hit the ocean at high speed. And it's Hard Mode so they are really dead. OK, let's try that again, this time with a couple Separatrons to ease the spent boosters away. Hire seven more crew. Launch. No collision at stage separation. Only this time, the Separatrons, whcih have their nozzles pointed right at the orange tank, cause enough heat damage to that same orange tank to blow it up again... (I am still learning how the DRE mod affects things.) Fourteen dead Kerbals and if it were Real Space Program, I undoubtedly would have been fired.

Hah... I lost my Jeb in exactly the same way! It was a picture-perfect science mission to the Mun, a nice amount of science from a fairly cheap, sub 18-ton, sub 30-part early-stage mission in Hard Mode (plus FAR/DRE). Going great. Jeb of course nailed the multiple Mun landings at different biome sites. Kerbin return and re-entry... No problem. Parachutes out, looking terrific. Then the spacecraft touches down on the side of a nearly vertical wall and tumbles to its destruction. Bye Jeb, bye lots of science, bye funds! No patched conics available to optimize the return, so I had just rolled the dice...

The answer is that you want to enter the Mun's SOI with as little speed as possible relative to the Mun. It's easiest to think about it in energy terms. Any object entering the Mun's SOI and going to the surface is going to pick up the same, unavoidable, amount of potential energy as it falls through the Mun's gravity well. If you just free fall, all of that potential energy gets converted into kinetic energy (i.e. speed), which needs to be dissipated if you don't want to crash. Any speed with which you enter the Mun's SOI is just additive to your total energy that will ultimately need to be dissipated. If you enter with non-zero velocity, now you have the same amount of potential energy as before, but you also have extra kinetic energy. All of the potential energy, plus all the kinetic energy, is going to be converted to kinetic energy (speed) by the time you reach the surface, which means you will just be going faster once you get there. There is no way for your initial SOI entry speed to give you negative kinetic energy-- it will always be positive-- so you can't design a lower-energy Munar approach than one that enters the SOI as close to zero-speed (relative to the Mun) as possible. No clever entry trajectories can get around this fact, although flybys that subsequently exit the Mun's SOI can sometimes help set up a better (slower) final encounter later. In practice the means you want your pre-entry orbit around Kerbin to be very similar to the Mun's orbit, so that you just sort of barely drift into the Mun's SOI. Hope this helps.

FWIW: I am currently playing KSP on Hard Mode with FAR/DRE and have been able to get over the early-stage funds hump without doing any Kerbin visual surveys. Instead, I focused on putting a bunch of commercial satellites into orbit, which tended to pay more and cost less per launch and seemed easier/less "grindy" to me. It was a bit tricky to launch the satellites with the non-SAS Stayputnik core and no patched conics mapping, but certainly not impossible with practice (although I admit to occasionally losing satellites during launch due to loss of control followed by rapid disassembly). I have now reached a point where most of my buildings are upgraded to Level 2, I have better probe cores and patched conic mapping, and I have about a million funds to spend. Anyway, just wanted to offer that up as a different approach to grinding away at mapping for anyone who's interested. No flame intended. Hope it is helpful to someone.

Update: Disabled antialiasing and still got the same problem.

I tried disabling SM3 shaders (fallback shaders were already disabled). Still ran into same problem. I am loathe to reduce antialiasing but in the name of debugging, I will give it a go next. :-) BTW thanks for looking into this. I love playing KSP and hope to be able to start enjoying 0.90 the way it was meant to be played soon.

Looks like the old one may have been cut off for some reason. Try this one. It appears to contain the missing text.

So far, after disabling PPFX edge highlighting, I cannot reproduce this bug yet. I will keep looking -- I think I encountered it earlier with PPFX disabled but I can't be sure -- and will post an update if it comes back. Thanks for the help! BTW, in case it's useful: Anti-aliasing is set at 4x. Here are the other graphics settings (after disabling PPFX edge highlighting):

I just tried disabling the PPFX highlighting and was still able to reproduce the bug. But on the positive side, I got a really cool psychedelic image of the startup screen: FWIW here are my graphics settings:

I get severe graphics glitches when I hover over the stage sequencing icons in either VAB or in flight. I have two different Macs with two different graphics cards and it happens on both of them. Stock installs on both. This never happened on 0.25. There are no prerequisite steps to reproduce this although the specific graphics glitches evolve depending on what you've been doing recently in or out of the game. Generally this does not result in a crash and it goes away when you stop hovering over the icons. But it is disruptive because it prevents you from seeing which staging icons correspond to which parts on your spacecraft. Here are some sample screenshots (taken while hovering or clicking on the staging icons): (Note wacky presence of nav ball and altimeter in this VAB screenshot) (Note double presence of altimeter) System specs: 1. MacBook Pro Retina (Late 2013), 2.8 GHz Intel i7, 16GB RAM, NVidia GeForce GT750m with 2GB VRAM, OSX Yosemite 10.10.1, running at 1920x1200 resolution. Log file here. 2. iMac 5k Retina Display, 4.0 GHz Intel i7, 32GB RAM, AMD Radeon R9 M295X with 4GB VRAM, OSX Yosemite 10.10.1, running at 3200x1800 resolution. Log file here.

I have had similar graphics issues on a totally stock install. Symptoms are psychedelic colors, often flashing, and dramatically reduced framerate. I first ran into it on a lightly modded install (posted here) but was subsequently able to reproduce it with no mods. Pics: Hardware: iMac 5k Retina Display, 4.0 GHz Intel i7, 32GB RAM, AMD Radeon R9 M295X with 4GB VRAM, OSX Yosemite 10.10.1, running at 3200x1800 resolution Console log file here. I have run into other graphics bugs on a different Mac, also fully stock, but the symptoms are slightly different so I will first research and then make a separate post as appropriate.

Another Update: I have now been able to reproduce the problem with no mods at all on my iMac. I will search for a related thread in the unmodded support forum and post accordingly. Edit: Added a post to "Disco Mun" thread, which seems related. Log file here. So far I have only been able to get the psychedelic colors in a full stock install on my iMac Retina, not my MacBook Pro Retina. However, I get more subtle graphics glitches on the MacBook Pro Retina as well when hovering over the staging icons in VAB or in flight -- I will post about them separately.

Update: I have been able to reproduce this bug while running *only* the ModuleManager mod.

Here are two snippets of console output that I think are associated with the error above. I'm not a developer, so please forgive me if these aren't the right snippets: *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) (Hundreds of repeats of the output above...) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Flight State Captured (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Saving Achievements Tree... (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Saving Achievements Tree... (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Game State Saved to saves/sandbox/persistent (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [HighLogic]: =========================== Scene Change : From SPACECENTER to MAINMENU (Async) ===================== (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug KSP(538,0xb06a9000) malloc: *** mach_vm_map(size=23040000) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug FAR: save AG actionGroupSpoiler as Brakes (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) FAR: save AG actionGroupIncreaseFlapDeflection as None (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) FAR: save AG actionGroupDecreaseFlapDeflection as None (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) UnloadTime: 9.117169 ms Unloading 1 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0) Unloading 2092 unused Assets to reduce memory usage. Loaded Objects now: 117952. Total: 131.408630 ms (FindLiveObjects: 7.359310 ms CreateObjectMapping: 3.607088 ms MarkObjects: 113.782417 ms DeleteObjects: 6.290303 ms) Unloading 0 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0) Unloading 0 unused Assets to reduce memory usage. Loaded Objects now: 117930. Total: 123.211449 ms (FindLiveObjects: 8.005803 ms CreateObjectMapping: 4.140714 ms MarkObjects: 110.818977 ms DeleteObjects: 0.229254 ms) UnloadTime: 5.680039 ms Unloading 2 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0) Unloading 9 unused Assets to reduce memory usage. Loaded Objects now: 119829. Total: 126.088234 ms (FindLiveObjects: 7.723091 ms CreateObjectMapping: 4.727626 ms MarkObjects: 113.293663 ms DeleteObjects: 0.280653 ms)