bv1

I don't understand how it would be difficult to distinguish the two. That's like saying that "b" and "d or "u" and "n" look too similar, so we shouldn't use them.

Here's a small suggestion that would make things just a little nicer. Why not replace the AN and DN symbols for the ascending and descending nodes in the map screen with their actual symbols ☊ and ☋? I for one think that this small change would make the map screen look even cooler.

This is a wonderful idea.

There should be a different track for the surface of each landable body and for each sphere of influence while in space.

To tell you the truth, I've never bothered with using the Mk2 lander can. It's just way too heavy to be useful. It's more than 4 times heavier than the Mk1 can yet has only twice the capacity. I guess this is just one more reason it is a useless part.

Now that the LV-N uses liquid fuel only, I've run into situations when it would have been nice to be able to dump oxidizer.

I like this idea. It would be a relatively easy change for Squad to make, but it would improve the flipping situation for single-stage rockets considerably.

I can't vote because I have 3GB.

Thank you. I think that you should put that chart on page 1 that everyone knows what's up.

Pardon my ignorance, but when and why have the nominal ranges for the three stock antennas been changed? Whereas the whip antenna used to be useful only up to keosynchronous orbit, now it's useful throughout the entire Kerbin system. I thought that the point of the mod was to increase antenna diversity, but now you can just use the whip antenna entirely for Mun and Minmus missions. What's the deal?

There is a small typo in the Source.txt file. It reads: "Source is availalbe [sic] on GitHub at: https://github.com/SirDiazo"

I just wanted to give a big thanks to this mod's developer, because it alone has allowed me to play KSP again. I haven't played KSP that much in the last few months, since beta. With 1.0.4 downloaded, I started up KSP with no mods. I noticed right away that, even with the graphics settings turned down to the minimum, I was getting very poor performance. Mind you, my circa-2008 laptop (Dell XPS-M1530, 3GB RAM) didn't get me great performance even back in 0.24, but it was perfectly playable. Now, though, the lag was horrendous. I guess that the increased scope of the game has increased its RAM footprint since beta. The worst slowdowns happened whenever Kerbin was in view. When looking into the sky and when in the map screen, the framerate jumped dramatically. I couldn't determine my FPS accurately (switching between situations that caused and relieved slowdowns, the debug-menu FPS counter did not respond much), but it was slow enough that I could actually count the frames myself. I estimated that during slowdowns, I was pulling a whopping 8 FPS. Yes, eight--not quite a slideshow, but it made launches take an unacceptably long amount of time. Nonetheless, I wanted to play around with the new aero, parts, and other improvements made since beta, so I persevered despite the lag. Several launches later, when switching to the launchpad screen, the game crashed. I looked at the error log, and saw a familiar report: mono.dll caused an Access Violation (0xc0000005); 95% memory in use. I ran out of RAM. (I used to run into this issue with the Outer Planet Mod installed in beta.) Back in 2008 when I got my laptop, there were real concerns that 64-bit Windows Vista would cause driver issues, so I opted for 32-bit Vista. I've since come to regret this decision, especially when I found out that KSP's Unity has problems with 32-bit Windows and Dual-Core processors, which happens to be just my situation (Core-2 Duo). I happen to have a dual-boot installation of 64-bit Linux Mint, so I tried to run KSP under that OS. In addition to being 64-bit, Linux Mint has a comparatively small memory footprint, so there was more free RAM to go around. KSP launched successfully, and I had much more free RAM available. Unfortunately, it ran even slower than in Windows. Even navigating the title screen menu was painfully slow. I guess this is because, in Linux, Unity runs on a sort of emulation mode, and is thus slower. Another fix for the 32-bit Windows/Dual-Core issue is to make sure that extended ram support was turned on. After some investigation, I found out that it already was turned on. I was about ready to give up on trying to play KSP again; I thought that my laptop just wouldn't cut it anymore with the newest KSP. There was one last hope, though: Active Texture Management. Recent posts in this thread generally say that it doesn't do much for stock KSP, so I didn't think that it would do anything. It was worth a shot, though. ATM installed and a couple minutes later, KSP was up and running. This time, it was smooth as butter! I played for a few hours today, and thus far, there are no more issues. Recent posts say that ATM doesn't do much for stock KSP. I'm here to report that, in my case, this assessment cannot be further from the truth. For me, the difference was night and day. I can play KSP again!

So all these rockets in real life really are statically unstable? After some more experimentation, I was able to get to orbit with some rockets with higher CoM than CoL. The most important factor I discovered was that the prograde flight assistant is helpful only if the pod's reaction wheels are disabled. If they are still enabled, then SAS will jitter so much as to flip the rocket around. I think that much of the problem comes down to limitations of KSP itself. Beyond fixing the jittery flight assistants, I would really like to have some small fins just to lower the CoM a little for small rockets. A really big problem is that SRBs in KSP are crappy compared to real life: they don't have any gimbal capability, and the pod's reaction wheels are not enough to reliably keep it from flipping. Also, there is no way to adjust the bore so that the TWR doesn't get ridiculously high at the end of the burn.

I tried out FAR yesterday, and I have a question: why must all my rockets have tail fins? If I don't put them at the bottom, they inevitably flip over. However, in real life, I dare say that most orbital launch systems lack sizeable tail fins. Yet, they seem to fly just fine. What gives? Is this a limitation of FAR or of KSP itself?

Thanks, Claw. I followed your advice and created a new folder in C:\ as C:\Games and then extracted KSP there. I first started the game without the Launcher, thinking that maybe the Patcher it downloads may have been problematic. Both the KSP.exe alone and using the Launcher work now. I always used my User folder; I wonder why it is not working now. Anyway, this thread can now probably be marked as Solved. P.S. The SAS jittering is still there. I know that Squad fixed SAS jitter awhile ago, but I think that they need to re-do it for the vector-based (prograde, antinormal, etc.) SAS options, at least for small ships. The Roll control really seems susceptible to this jitter.

After trying out some new mods, I had a problem with SAS being really jittery, so I decided to start afresh. I re-downloaded the 32-bit Windows version of KSP from Squad and tried to load without any mods at all. Each time I try to load the game, it seems to crash at the same point. I've tried to use the lowest settings possible by using the launcher. Here is a link to output_log.txt: http://pastebin.com/G3Bwmnrv Here is a link to error.log http://pastebin.com/bV602Tnc Here is a link to my configuration file (settings.cfg) http://pastebin.com/aekQLn02 Here is report.ini http://pastebin.com/vgycgQea I've noticed that some other users have been reporting similar crashes recently. I used to be able to run KSP (version 0.90), even with several mods, with little difficulty. Perhaps there is something in a new update which is causing this problem.

I've always wondered this too. It seems ridiculous to have to have every single part texture loaded into memory at all time, when there are parts I never use at all.

This is a simple suggestion which should be implemented.

It seems to me that someone has a gun to Squad's head. I can't think of any other reason that they would have only one beta release before going to the final release.

I play KSP on my oldish laptop which has an Nvidia GeForce 8400M GS GPU with a whopping 128MB of video memory.

This is a great idea. My vessel lists also get very large.

How does one change the default chute deployment altitude from 2300 back to 500? I'm tired of having to manually change each chute setting. If I forget, then I'm stuck waiting forever at full time warp while the craft slowly descends from over a mile high.

There's already a thread here about saturable reaction wheels: http://forum.kerbalspaceprogram.com/threads/78170-Saturable-Reaction-Wheels I think that Squad should get serious with difficulty options. After all, a good selection of options is essential to any good game.

Considering that rocketry (and KSP) is based on Newton's third law, I don't think that the basic conservation of momentum should be a "little known effect". At present, small rockets don't need to have any thrust vectoring, RCS, or control surfaces of any kind. It's not just unrealistic, it's ridiculous. To me, it is as obvious a flaw as is Sonic walking at a leisurely pace around loop-de-loops in many of the 3D Sonic games. IMO, I don't think that it would even be that difficult for beginners. When starting out building their first rockets, they would simply come to the realization that they need to have some Control parts, just like they come to the realization that they need an engine, or a parachute. But at any rate, this is a change that they could easily make toggleable in the difficulty settings.

I'm glad this thread has been bumped. I would love this functionality available in stock KSP, so long as it is as available as a setting for higher difficulties. This is exactly what kind of thing the difficulty options should include.