paploo

I had thought of that, but since the navball and locked view reference the command module by default, it would mean I'd be flying crooked compared to my usual visual references without doing some trickery. I could also try re-adjusting my designs to be more in-line with my "can" based landers, though I did find myself working harder to keep my ladder zone free with those. While not a huge deal, it is one of those little quality of life things that I'd rather not have to start fighting for no apparent reason.

The one I'm really missing right now is the old Mk 1-2 Pod that is now replaced by the (unfinished) Mk 1-3 Pod in 1.4.0. Oddly, I'm not so concerned about the looks, but more concerned about the new ladder placement, which totally changes how it's used in designs that double as landers. In any case, I really would like to have parts available starting in 1.0—especially ones that are functionally different in any way—be available into the future. I don't mind having more stock parts available to me, and some of those old ones do solve problems that newer ones can't!

The new Mk 1-3 Pod is very pretty, and I do look forward to seeing it completed; however I do really miss a particular feature of the Mk 1-2 pod that completely changes it functionally: You see, the Mk 1-3 pod's ladder is centered, such that if it stands at the top of a lander, I can't put anything on the cardinal symmetry line under it—but the original Mk 1-2 pod offset its ladder to the side specifically to allow for this logistical problem. for example, I commonly use 2-fold radial symmetry, placing solar panels perpendicular on one set of cardinal direction sides, and monpropellent/batteries on the other, such that in the "Lock" view, my panels stick out beside me like wings, and monoprop tanks and batteries are up/down, perpendicular to the solar panels. With the new Mk 1-3 pod, I can't do this if I ever plan on using it as a lander, because I can't get the ladder to the ground without running into my tanks. Now, I'm not asking that the Mk 1-3 Pod be removed from the game, but it would be nice if the Mk 1-2 pod continued to be available and supported into the foreseeable future. This would allow people like me to continue easily building the designs that utilize it as a dual lander and re-entry capsule.

Hey SignalCorps, I have had parachutes deploy if I put them on the same staging event as the decouplersâ€â€granted it wasn't my intent to do that, but I didn't double check my staging events before launch and made an oops. I am interested in the overall trajectory of your launches thoughâ€â€at what altitude are you expending your first stage to the point that you are releasing it? Especially in 1.0, you should be angling over a few degrees right after launch, and this has been enough to arc the spent first stage tanks away from the pad, regardless of whether I'm launching a little local mission or a large interplanetary space station.

I have done some research into this issue, and the analysis of vmmap dumps on affected systems indicates that both the application itself, and the graphics driver, are allocating space for texturesâ€â€which must compete to fit in the same 32-bit address space. The result is that between the app itself, the graphics drivers, and various system frameworks, using full resolution textures can leave you right on the edge of memory exhaustion at the main menu! The short term workaround is to lower your texture settings as low as possible, in order to leave as much overhead as possible. The long term fix is to either find a way to greatly manage texture memory more efficiently on OS X, or to move to a 64-bit build. Both of these are non-trivial for KSP from what I gather. Unfortunately, if this is true, I imagine that a fix for 1.0 couldn't be fit into a schedule already made tight by developing so many new features, even if they wanted to fix the problem.. Note that the motivation for this theory (in summary) is that by using mmap, I could see both the application's own MALLOC region, and the the IOKit region, scale by the same amount as I increased texture resolution. Other memory regions remained relatively unchanged, and varying other parameters left all memory regions relatively unchanged. I combined this with some Apple documentation on its OpenGL pipeline that describes how the OpenGL drivers can keep their own copy of the texturesâ€â€outside of application the application's heapâ€â€to load to VRAM as is necessary, and that your application has no direct control of this memory management.

The competition was loads of fun! My launches were very Kerbal, but in the end I somehow managed to get third. I also got to chat up C7 while my launches were failing, which probably didn't help me any.