Ruedii

I was thinking to see if there is a way to do this with module manager. Do you think it's possible?

I'm not sure if I already suggested this, but I'd really like to see an option to allow the toolbar to be a drawer in the stock toolbar. Obviously, players should be allowed to configure their toolbar(s) how they like, and they shouldn't be forced to use this option, but it would be a nice option to have.

Generally using OpenGL, it's best to set your Anti-Aliasing using the overrides your graphics card control panel.

You might want to look into setting this it up to use "MPD" media controls instead. You should be able to find an existing mono binding module for MPD, and it since it's only interacting with the GUI, and no Unity events, there is no need for it to be Unity specific. MPD generally allows you to have music player controls and a now playing listing. It also has more advanced controls but they are harder to program for, most people don't want to bother with them, and they are less widely supported anyway.

OK, Canards on the nose of a rocket can add a LOT of torque. Just make sure their lift is countered by fins in the back. Also, remember, the further the RCS ports are from the center of gravity the more effective they are. Finally, reaction wheels are useless without electricity to power them, remember, boosters don't generate electricity, so if you don't have enough electricity, you can't control a rocket with reaction wheels. Likewise, if you use a probe core, you run into a worse problem, all controls freeze once you are out of battery.

Just remember one thing, though: The more patched conics you have, the worse the "conics lines are twitchy" and "conics predictions are innacurate" bugs you encounter. However, I think this is a good trade-off. Additionally, increasing patched conics to insane levels will result in performance loss, but I don't think anyone will set their conics that high.

As a note, more speed equals more lift from less surface. This results in less drag overall. Remember, your space plane will be landing with it's dry weight. It's landing speed will usually be half it's takeoff speed. Your wheels can handle quite a high decent landing speed, especially if you double up the main landing wheels. Generally you should be able to safely land at 120m/s when you are on a nice low glide slope and use proper flaring. The big concern is that your rate of decent doesn't get to high. As of making sure you can take-off. The wheels can safely handle takeoff roll speeds that are incredibly high. Your main limiting factor is the runway, and the solution for that (short of Modding KSP to have a longer runway, or rolling your SSTO out to the feild by the runway) is to add more thrust. If you really want to add some umph you can even attach some seperatrons to use as jtags, or even use some small boosters for launch. It's not really an SSTO if you drop them. You can keep them on if you want to get the SSTO bragging rights. seperatron-based jtags will be recoverable if you add a parachute, but the small booster will place your seperation point too high. Another option is to do an angled takeoff with a launch-clamp. I still haven't been able to design a rocket-powered catapult sled, but I've considered it, so I'll throw the idea out there.

Tosha, there are actually several options that I like on SSTOs for rapiers. I like to use it engine for my center engine, to save the weight of an added rocket engine.

Initially having air intakes turned off isn't necessary, but it certainly will save noticable fuel. Turning off side engines once there isn't enough air is absolutely necessary. So long as your SSTO is designed to allow the centermost engine(s) to burn-out on their own without going into a flatspin, you can let them burn-out at minimal throttle. You can get a much lower minimum throttle by using the thrust-limiter tweakable first. You can squeeze out a tiny bit more power once they burn out on minimum throttle, by turning off the throttle completely and reactivating them. The main thing is to do a proper gravity turn to get a good airbreather powered suborbital arch. This can save you a dramatic amount of fuel. For larger SSTOs that require power for landing, you may want to save some jet fuel for landing after reentry. The jet fuel usage thing is mostly a design issue. You should only fill the liquid fuel only tanks with the liquid fuel you need for the operation. Generally SSTOs going beyond standard Kerbin Orbit should be refueled in orbit unless their functional purpose is being a fuel tanker. This allows them to reuse their tanks that were used to circularize when refueling.

This might be a feature to add to tweakscale. (scaling landing gear strength with size)

Has anyone found a workaround for the keyboard input issues that are causing the numeric keypad not to work?

Another thing to check is a list of your active background programs. There are quite a few, such as older versions of StarForce DRM, that can really kill hard drive access time.

The issue is with the handler of the terrain shader, last I checked. It happens on all platforms. It is worse on the Linux open source drivers. It was so bad on the nVidia open source drivers I had to switch to the proprietary drivers. For now, if you are using something newer than the AMD HD5xxx series you should probably be using the proprietary drivers. The HD6xxx series is almost as fast on Open Source drivers with a handful of games running faster, but the HD7xxx and later all currently perform rather poorly. I think this bug has do with latencies in drawing the terrain, and I don't really think there is much you can do about it short of reducing the terrain detail.

Still not the right log. I would need the one with the timestamps. Additionally, this is just a shot in the dark, but have you recently defragmented your hard drive, and have you run a recent malware check?

That is quite common. It's due to delays between the response of the physics and the actions taken by the (A)SAS. You can reduce it by moving your SAS units to the center and turning off gimbling. You can toggle your SAS units so that only those at the center are on.

If someone wants to make one I have figured out the most accurate way to do so without any collider animiation, or other physics-demanding things. Technically the most accurate "repulsor" is best created using an invisible, indestructible curved collider acting as a zero-friction "slider" on the ground to represent the "Field" The spheroid should be able to slide on this to the point that it recesses into the collider. Turning "on" the "repulsor" would activate the spring in the slider side facing the ground to push the "field." Adjusting the repulsor "strength" adjusts the force of this virtual spring. These repulsors, of course, have zero movement, and just hover. Of course, we all know would be more accurate to scale a concave collider out from the repulser, in the actual shape of the desired field. However, this would also use massive physics energy. Simply using a spheroidal collider slider on a spring-rod works fine, and is much simpler physics. I would personally recommend using a toroid (donut shape) for the repulser field. The inside of the toroid can be greatly simplified, but might be desirable to create an accurate "hole" in the field.

Not that I know of, but it could probably be made. You would simply need to create a form editor with a descriptor language for known fields and the ability to add unknown ones and save them to the secondary "user" descriptor file. The form editor should probably be tree-based. It shouldn't be two hard to create a program to generate cfg files. They are a simple C-like format, that appears close to Javascript. It might be a limited dialect of Unity Script, but I'm not sure. Still there are a number of syntax highlighting editors that should be able to edit these by hand: Notepad 2, Cream, Kate, Kwrite, MousePad and Gwrite work if you set it to JavaScript, ActionScript, jScript or ECMA Script (all three the same filter.)

It seems your Ubuntu version is really out of date. You probably should update to the latest version of Ubuntu LTS. This might solve your issue. The AMD Proprietary drivers do not play well with older X11 versions, such as those that ship with Ubuntu 12.04, even using the LTS driver update packages.

Can you use CTRL-ALT-F1 to switch to console when this happens? Also, if you activate the CTRL-ALT-Backspace key (read the Ubuntu Wiki if you don't know how) does it work. Alt-Tab should also still work, because KSP does not capture that.

You are missing the blit extension. What Linux distro are you running? Also, could you check the version your Mesa, X11 Driver, X11 and libLLVM versions? SandyBridge should be capable of running the shaders in the Aerodynamic FX and Screenshots using the Blit extension if your drivers, X11 and Mesa versions are up to date.

The launcher log isn't much use. Could you post the game log?

There has been some work between Intersteller and Near Future to get the two mods playing nice. I am not sure of that status but there are still balance issues between the two mods on how they implement the advanced technologies. I haven't heard anything at all on impossible innovations.

Have you tried removing all mods. This should be your first test. This determines if it's a bug in a mod in a mod or the game. It seems you are getting some null reference exceptions from DebRefund so it might be that.

I personally like getting on the boat, and driving it as fast as you can until it rips itself apart.

As a note, that map estimates on the high side for good reason. You want to play it safe. Of course the best way to do repetitive landings on any Moon or small planet is to put a station in orbit with a 100% reusable lander. You can look at the chart on how much delta-V that saves. (Just send up tanks of fuel to fuel the lander.)