devikwolf

OH MY GOSH thank you! I've used this mod for a while and never knew it had this capability.

For several years now I've been trying to eliminate what is without question the absolute worst part of KSP, in my mind: * Birds chirping (extremely loudly) when in the KSC view -- audio matches GameData/Squad/Sounds/sound_ambience_nature.wav (yet making any changes including deleting the file outright does nothing) * Buzzing hum when in VAB/Hangar -- unknown file source These two sound effects are extremely loud and grating. The chirps are shrill and aggressive. The VAB buzz sounds almost identical to a pulsating ground loop hum. This has been present for at least 6 or 7 years. I've been trying to resolve this aggravating issue for that entire time. These are not added by any mods; they appear in bone-stock base KSP. If you have never heard the VAB sound before, drop "Music" to 0% and listen. It's not a hardware issue -- it has happened on 8 different computers I've used, without fail, on any install -- modded or otherwise. The hum ONLY appears in the VAB/Hangar. I can mute them by dropping the Ambient volume slider to 0%, but this also mutes every single other ambient sound, like re-entry effects. I've edited the "sound_ambience_nature.wav" with Audacity to mute the sound effect, but the game continues to blast this chirping noise as soon as I load any save. I've deleted the file outright and it makes no difference. This audio is so loud, grating, obnoxious, and migraine-inducing that I open the Windows volume mixer panel before opening KSP, and I selectively mute KSP whenever I'm at the KSC or any building inside of it -- basically, unless I'm actually flying a rocket at the time, the game is left muted. It's not an exaggeration when I say this is absolutely the worst thing in the game, specifically because I cannot find ANY method to resolve it -- in the UI, with a mod, or by deleting sound files. It seems that only a half dozen other people besides me have ever noticed this and been bothered by it. I can find only a handful of references in forums, and in every single one of them the OP is told it's a hardware issue. Googling the problem nets me only a few results outside of the forums, and all of them are either unresponded or the issue is blamed on hardware failure. PLEASE, PLEASE, PLEASE help me find the source of this so I can finally play this game without getting a headache from these aggressively terrible sound effects.

Great news! Thanks again for all of your continued hard work @Shadowmage

KER doesn't seem to be much help to my current problem, but I definitely wish I had installed this mod a few years ago. Thumbs up for this recommendation! Seems I can't get RCS-BA running properly. The button shows up in the toolbar, but pressing it does nothing. Hm. I'll do some more digging into what's keeping that from working properly. Tried out TCA; it hindered more than helped, ultimately. It made the shuttle extremely controllable at certain parts of the flight, but most of the time it was wobbling around. And I definitely had used this mod in the past, too, at some point. I don't recall exactly what it was for. I spent a while last night playing with the shuttle some more. By locking gimbals on the SSMEs during initial ascent and just relying on aero surfaces and SRB gimbal to maneuver, I eliminated the ascent wobble. Gimbals go back on shortly before SRB sep. Some extreme fine-tuning with the position of my probe core control points have helped a lot, but I still suffer from the fact that SAS doesn't make engines gimbal towards CoM until after the vehicle is already torquing over. It's far more controllable now than it was before, but fine rendezvous is a bit tricky because of that wobble. Selecting the probe cores to be a control point is also somewhat frustrating because of how they're tucked up in the engine cluster, so just getting the cursor to highlight them is a trick. But that's always been the case with my shuttles. Also, and I'm certain this is a limitation of SSTU: I had to mount my shuttle very much lower on the tank than I would like. I believe this is because, unlike the real shuttle which had the heavier oxidizer on the top of the tank, SSTU doesn't know how to do that, so the tank's COM is a lot lower than the real shuttle's would be. I think, anyways. I could probably solve the problem by building the tank in two parts, a separate piece for LH2 and one for LOX.

This looks like a fantastic mod. I love the feedback that DPAI gives, but it takes up a fair amount of screen real-estate. Does this mod also draw an alignment indicator on IVA navballs, too? DPAI's big draw for me is that I can use it in-IVA with RPM screens.

At least, until the final few missions in the program, when they used clever orbital maneuvers to run those puppies almost totally dry. Gotta admire the engineering genius that went towards squeezing every bit of performance out of that outstanding vehicle.

Similar to what Zhetaan said, when you're using the altimetry map, look for sections with as little color in them as possible. Anywhere you see bold green lines in the alt map, this means a sharp variation in terrain slopes at that location. However, even the best ScanSat maps don't have a whole lot of resolution even when you zoom in further on these maps, so the best recommendation is still aim for a 'dark' area on the alt map, and carry enough fuel to seek for an optimal landing site. Other than that, the only good way (in my experience) is to have a small prospector probe that you can swing down into an ultra-low-altitude flight over the desired area, and design your lander to be as stable as possible on an uneven slope -- because you're pretty much guaranteed to be landing on at least a few degrees of slope anywhere but Minmus.

Thanks for the input @FleshJeb! I'll give RCS-BA and KER a try. I've been using MechJeb for ages because of the details it gives during design, but I haven't used Kerbal Engineer in a few years (I liked what MJ did, at the time, better). However, my experience with SAS is that the craft usually starts thrusting with the engines at neutral gimbal, and then once it begins torquing off to one side, it will begin to correct. This occurs in orbit so I'm ruling out any aero influence. However, I MIGHT be mis-attributing the behavior to the fact that my probe's control vector is only aligned with my thrust vector in the crudest of senses. I'm pretty sure I've heard of TCA in the past, but I'll check it out this weekend. If it's the one I'm thinking of, I played with it a lot, a while ago. I might be thinking of a different mod, though -- I was looking for something that could balance engine throttle and gimbals to put a skycrane into an autonomous hover mode while lowering my Curiosity clone to Duna's surface, something I'm still trying to accomplish smoothly.

If you're open to using mods, consider checking out Docking Port Alignment Indicator. It GREATLY clarifies docking, gives you a lot of good details on your docking approach, and I've found it to be FAR more helpful than KSP's stock docking system without taking away any of the fun of docking. When you're on approach, how fast are you moving? I personally recommend never exceeding 2 or 3m/s when you're within ~100 meters of your target, and never exceeding 1m/s when you're within 35 meters. The size of your target and the handling characteristics of your vehicle might suggest a different course though.

I also recommend using the fuel overlay that becomes available with the advanced tweakables. This can be hugely helpful - I spent an hour troubleshooting unbalanced fuel drawing in a plane a while back, and once I looked at the fuel overlay, I had it solved in a few minutes. It's one of the less-known options in KSP.

My personal recommendation is to follow the same model that early NASA planetary missions used: build a simple relay orbiter along with your probe, and package them both together on the same upper stage transfer vehicle. Once you enter Duna's SoI (or you've captured yourself into Duna orbit), you can separate the probe and the relay into discrete vehicles and use them as needed. Here's a couple of pointers I've found helpful: Use a stock fairing with interstage nodes enabled to be able to more easily package both vehicles into an aeroshell (or connect both together inside the payload fairing via a double-sided decoupler) It's usually best to have your relay in a high altitude orbit, and usually on a steep inclination. Both help give the relay a better path with less planetary occlusion -- especially as your commnet grows The "small" fixed relay dish (not the folding one) will have enough range to reach from Kerbin to Duna (or Eve) regardless of where those planets are with respect to one another, once you've upgraded your tracking station. Larger dishes will be needed for exploring deeper into the solar system. Each upgrade to your tracking station increases the max range of each communication device Try building a very compact and inexpensive basic relay that you can bring along with almost any probe mission. You should easily be able to build a dirt cheap and very light relay that can be included in any of your probe missions without a drastic redesign of your launch vehicle Since these parts can be heavy, try to set up your encounters so that you can decouple your relay when you've just entered the planet's SoI, and pack it with just enough fuel to park it into your desired orbit. Then, your non-relay probe can carry much lighter radio gear since it only needs to be able to reach the local relay station If you're into mods, check out DMagic Orbital Science, which adds a pair of gigantic folding relay dishes. The larger of these, when deployed in Joolian orbit, can reach back to Kerbin with near-100% signal strength.

Hi all, I've been lurking for a while without posting or contributing. Veteran KSP player here. I've done a lot of bonkers stuff in this great game, but designing -- and controlling -- anything with off-balance thrust is still harder than absolutely anything else I have done in this game. For the entire time I've played KSP, I've struggled with designing and flying vehicles with off-center thrust vectors, EG an STS-styled space shuttle. I've designed and flown a few of these, but the most manageable versions were all pre-KSP1.0. SSTU offers a beautiful set of building blocks to make a ship, but there's still a ton of limitations from the core mechanics. 1. The display for thrust vectors and CoM during vehicle design seem to not be useful for something like this; I have to eyeball it, by rotating the camera until the thrust vector is aimed right at the camera, and then I have to gauge whether the thrust vector 'ball' is lined up centrally with the Center of Mass. Maybe I'm totally missing something, but this "eyeball it" method seems to be the only option in this case? I can't even find a mod which will draw a ray along the thrust vectors so I can see if it properly intersects CoM. So it seems the only option is to eyeball it, throw it into a test flight, revert, eyeball it again, test again, etc. There's got to be a better way, even if it's through a mod, but I've never found a mod that will allow me to either do this -- or better still, just let me hit a button or a key to rotate the engine to align it to the center of mass. 2. During flight, the space shuttle's main engines would gimbal themselves towards CoM, to account for how the CoM would change as fuel burned off (despite the stack being engineered to keep the CoM change as in line as possible with the center of thrust, it still moves). KSP of course doesn't have anything like this stock, but I also can't find this behavior in any sort of mod. Being able to keep the engines gimbaled to a changing center of mass is a critical ability of the space shuttle. 3. Navigation in KSP is always aligned through the control part's forward vector. I've found some older mods that give better handling options, but I've never been impressed with them. In the past I've usually tucked a probe core between the SSME cluster and angled it along the thrust vector, and use it as a control point, but again, this is just a very eyeball-and-test process. I can't find any mod that offers a "control from thrust vector" I've watched users voice these same frustrations for 3-4 years and I've not seen any good options besides "wrestle it to orbit by manually doing things that the computer would be doing a thousand times a second" which is ultimately more frustrating than fun, to me. I've managed to get perfectly stable and flyable shuttles in the past, but only after spending dozens of hours making tiny, tiny changes to part positions.

Thank you as always for the update! Orbital Science is still one of my "must have" mods.

I use MJ to aid in a few things, such as creating maneuver nodes for interplanetary missions or to achieve very specific orbits, as well as for certain orientation maneuvers like orienting to a node, since I've never found the stock tools to be useful for either of those. Using MJ is a quick and dirty way to give me an idea of a launch window well in advance of a launch date, and gives me useful information when planning for an interplanetary trip. It's invaluable to my shuttle program: it holds stable nose-up orientation during most of re-entry, until it starts doing a dutch roll around 25km and I take over manual piloting the rest of the way. But it prevents several tedious minutes of tapping W and S to try and hold it just at the right angle.

Hey crew, been lurking for a while without contributing. KW's been an 'essential' mod in my pack for years and I've done a lot of custom tweaks and fixes of my own. I had a thought last night while playing: I have not been able to get my favorite part working properly since 1.1: the petal adapter. I think it's due to construction and staging changes that prevent it from working with the hidden inner node, and the craft no longer disengages from that node properly, and when this mod was originally built the fairings were a compromise because procedural didn't exist at the time. What would be involved in removing these petals completely and replacing them with procedural fairings the way the other aeroshell bases have done? This way you can still retain the use of the bay (the bay walls look so much better than putting a lander/payload inside of the other fairing bases), and it would replicate the function of the SLA in later Apollo missions where the panels were jettisoned after the bay opened. I don't know if anyone has the model files and would be able to remove the petals, though.

Love the mod, as always. I found what I believe to be a bug in the latest release. Running 1.2.3 on KSP 1.1.0.1230 Win x64, when I reset a Goo or Mat bay, the bay closes, but the experiment does not reset and can't be run again.

As I always say on these nullref exceptions: "well, did you try to set the object reference? You should set it to the instance of an object."

Ahh, I have the camera mods and I can view the camera feeds from IVA. But, I would like a way to be able to view those cameras during ship design as well as when flying the ship while not inside of IVA. I thought it was part of the RPM base package, but I guess it's part of the Hullcam mod instead! I've been installing RPM + a couple of other mod packs combined together for a while, so I forgot they're provided separately.

RPM remains one of my "required" mods for KSP, absolutely love the depth it adds to the game! One thing I've been looking for, lately, is an external window which can display an RPM camera feed without needing to be in IVA. I can't seem to find anything that accomplishes this right now. Anyone have any suggestions?

I am, yeah. Positioning the probe core in the middle of the SSMEs hides it from being an ugly protrusion at the back of the craft. It's close enough to the OMS center of thrust that it's "good enough" to get me to where I want to be within an acceptable margin of error.

Thanks selfish_meme! I wanted to avoid putting any other fins on the craft if possible, but I hadn't considered offsetting them into the body to hide them. Now, if only I could get the navball orient to the direction of thrust instead of dead-forward from the cockpit, I'd be perfectly happy. My less-than-optimal solution has been to add a probe core at the same orientation as the SSMEs and use it as the "control from here" part whenever making a burn to reflect the actual direction the ship will fly.

First of all let me say I absolutely LOVE this ship. I've spent countless hours trying to make a shuttle in KSP that handles properly and could never get anywhere close to getting it right. This took me a couple nights to figure out how to fly it properly and I've pretty much figured it out. I've got a ton of time flying traditional rockets in KSP but I'm sort of a noob with spaceplanes. I have two problems that I hope maybe you can give some advice on. First, because the thrust is offset from the cockpit axis, I'm finding it hard to accurately burn at maneuver nodes. I pitch the nose up approximately 10 degrees above the node when I burn which gets me in a fair approximation of where it should be, but I still wind up having to make a bunch of corrective burns afterwards. Trying to get a precision orbit (much less rendezvous) is real tricky. Any advice on how I can better aim the ship when I'm flying in orbit? Second, when I'm landing, I usually lose control and start to tumble around 25km or so. The ship rolls left to right, getting more aggressive with each roll until it rolls 90 degrees to one side, and starts to tumble end over end for a full minute or two before I can regain control and land. Any advice on how to keep it stable? I usually come in at a fairly shallow re-entry, starting around the burn 100km altitude and ending with a periapsis targeted around 15km or so.

Been working perfectly for me in 1.0.4. I get a nag message on startup, that's all.

The Petal Adapter is somewhat buggy. It only works well with the KW 2.5m engines. You will also need to edit your "PetalAdapter3m.cfg" file in order to make the top decouple node work properly. Here is the config change I made, and now it works as expected: Change this line (line 88): explosiveNodeID = top To: explosiveNodeID = topFDown EDIT: Alternatively, you can remove the following node, which should allow you to connect it to the bottom of any 2.5m part node_stack_topFDown = 0.0, 2.10, 0.0, 0.0, -1.0, 0.0, 2 In this mode, though, you will not be able to use the 'hidden' attachment node within the KW 2.5m motors, and will only be able to attach it to the bottoms. This means you'll be left with an ugly engine shroud that will "float" in the air after you open the petals and decouple your upper payload. If you're looking for a more pure Apollo-style system, you'll want to use the first method I described. I'm going to fiddle with the config some more this weekend to see if I can make the part operate properly with either mode.

It is -- the cfg file references an invalid science tree entry. I edited mine so that it is unlocked by the same tech as the 2.5m SAS. You can specify any tech you want, I just did the same as 2.5m SAS because it's easier. Below is the change I made: KWRocketry\Parts\Control\KWRadialSAS\part3m.cfg Change the line: TechRequired = largeControl To: TechRequired = specializedControl