HvP

I see two icons in the toolbar for mods which seem to control communications. I don't recognize these icons, and they are not from the stock game. Do you have mods installed that add requirements for communication networks?

I don't think that 60km is high enough, but it varies based on the size of the body you are orbiting. When you right click on the survey scanner and attempt to perform the orbital survey but you aren't high enough it should have a message come up with the height range of the orbit that is required to complete the scan. For Duna, try going for a polar orbit that is at least 100 km.

I think that @The Doodling Astronaut made that arm to imitate the arm which holds the antenna receiver on a large radio telescope style dish. The open fairing half resembles the reflecting parabola half of such a telescope or antenna. He can correct me if I'm wrong. In a newer update to KSP they added the ability to leave fairings open ended during construction. I believe that when you have partially created a fairing in the VAB holding down "left-alt" while left-clicking will leave the fairing open and it will remain that way for launch until staged away. There should be a text message during fairing construction while in the VAB which clarifies this.

This seems like a good jumping off point as an introduction to this topic, but of course the devil is in the details when it comes to 'copters. I feel like there is room for a whole series of tutorials on this topic. For example, I find the transition to and from horizontal to vertical flight to cause all sorts of stability issues with my helicopter designs. For me, they either fly well going forward, or fly well going up and down, but never both. I like your matter-of-fact presentation style, and look forward to browsing your channel.

This seems like a fair assessment to me. The whole point of Starship, of course, is to be able to recover and reuse engines for multiple flights. For this experiment to work the Raptors don't just have to not fail for one flight, they have to perform for multiple flights and not cause a mission failure in those future flights. The Merlin engines have shown that they can be refurbished easily enough to fly reliably and economically. Will they get there with the Raptor?

Sometimes the contract also specifies a range of speed that you must be going at the same time you are at the requested altitude. If the engine has already been staged earlier then it won't work the second time unless you trick the game into thinking this is the first time it has been staged. It's kind of tricky to do this. It's easier to make sure this engine will only be staged for the first time when your ship is at the right speed and altitude for the test. If you absolutely need to have the engine running before the test, then you can try this. When you are in flight and coasting upwards towards the required altitude go into the stage icons on the left side of the screen and click the little plus sign "+" that appears next to the engine stage. This adds an empty stage to your stack. Drag that empty stage to the bottom of the stack. Now grab the icon for the engine you need to stage and drag it out of its box and place it into the new empty one at the bottom. This creates a new staging event for the engine the next time you hit the space bar. I haven't done this recently but I think it still works. If that still doesn't work then you may just need to keep the engine unused until you are at the right place to stage it for the first time.

Pay close attention to text in the contract that states how those parts must be tested. Sometimes it says that they should be testing by staging them. That means that you'll have to activate them with the space bar at the right time when all of the other contract requirements are met. Make sure there is a green check mark next to all of the requirements in the contracts window when you do it. If you need the engine to be already activated then you can just go into the action groups editor in flight to reassign the same engine to the staging group to activate it again later when the time is right. If the contract just says to "test" the engine, but doesn't mention staging it then you'll need to right click the engine at the right time and click a button in the menu that says "Run Test" to complete the contract.

That's my kryptonite too. Oh, I can get a spaceplane into LKO but I either have to strip out anything really useful first, or there's not enough delta-v left to get anywhere.

Hi @Popestar The reason you are having difficulty is because the SEQ containers are parts from the stock inventory system and the IMiC containers are parts from the Kerbal Inventory System "KIS" mod. I don't believe that the IMiC containers from KIS are capable of accepting the stock ground experiments since they rely on the stock container system only. Also, if I remember correctly, the KIS containers require you to click-and-drag parts into their inventory slots.

I use docking mode as an alternate control set for rovers. I often use a PS3 controller, especially when driving rovers. The analog stick makes steering much more responsive and holding forward on the stick is much more comfortable for long journeys than holding down a button. But since I don't want to engage the reaction wheels (which could flip the rover), I switch to docking mode for driving. I have the translation/rotation toggle bound to R3 on the controller so that if I jump a crater in low gravity I can quickly switch to rotation control which activates the reaction wheel and I can line up my landings on slopes. Then when I land I toggle back to "translation" mode which won't roll the reaction wheels and gives me steering control again. Being able to switch between both control schemes using just one analog stick allows me to keep the RCS bindings on the digital pad unaffected. Which means that I can always use the RCS to soften the landing on low gravity worlds regardless of which controls I'm using to steer or rotate at the time.

There's a great source of naming lists here: https://namingschemes.com/Main_Page Since you're going to Duna, which is the Mars analog, I would try variations on Martian ideas. Burroughs, Barsoom, Ares, Bradbury, Aelita, Vulthoom, Heinlein, Valentine, Vonnegut, Mariner, Viking, Weir, Watney, Wells...

Yes the contract says "Transmitted 0% of 33%" @dresoccer4 You have to right click on the scanning arm, choose to view the results, and then select the transmit option in the science results window that comes up. Hopefully you have enough electrical power to finish transmission. If not you will need to have your Kerbal collect the science from the scanning arm just like with any other science experiment and store that science in your return capsule or science container for recovery back on Kerbin. That will also complete the contract when you recover it back at the KSC. For future reference, I believe the SPRT Medium Scanning Arm provides 66% of the total science (even from the same surface feature), and the OP-E Large Scanning Arm will collect the full 100% of the total science from those surface features. There is no transmission penalty for using the scanning arms, which is what makes them good for even unmanned rovers. Edit to add: Yep, looks like you found a LARGE Mun crater instead of the regular Mun crater. The regular ones that this contract is asking for are only about the size of your rover and are much harder to see in among the other ground scatter.

I see that the contract orbit is very near to Kerbin's orbit. Has your satellite left Kerbin's sphere-of-influence yet? The contract system doesn't consider your craft in orbit of the Sun if you are still inside the SOI for any other planet, even if you are on an escape trajectory for solar orbit. If that is the case then you just need to time-warp or wait until your craft has completely left Kerbin's sphere-of-influence. That is assuming that all other contract parameters have been met sufficiently. Edit to add: I just noticed your altimeter is reading an altitude large enough to be in orbit around the Sun. So ignore my statement above. It's unlikely that you are orbiting in the wrong direction (which can cause contracts to fail) but I don't think that orbital direction is normally a requirement for asteroid scanning missions. If the orbits appear aligned from above then I would make extra sure that your inclination is correct. But as already mentioned, it's difficult to say without a screenshot of your orbit map view.

The first thing that will probably help you is to go into the main menu settings and look in the General + Gameplay category for "EVAs auto-rotate to camera." Uncheck the mark to turn auto-rotate OFF. Since it's happening only when you tap the UP key it may be that you have overlapping key assignments. The space-bar is the default key to reorient the Kerbal to the direction your camera is facing while on EVA. It's possible you also have this function assigned to the same key you are using for moving up. Those settings are in the main menu settings under Input + Kerbals.

@Popestar Ok, first of all, I'm sorry that your experience here has been so frustrating - both in the game and on the forum. Most people here really really do not want to be unhelpful, but frustration can be a two way street. It's also frustrating for us too sometimes when we don't have all the info about a person's situation to make good suggestions. And others unintentionally assume too much about a new player's understanding of the game. I think that's what's happened here. So let's take a step back and try to start over. I'll start with just a few basics from my perspective: Can you get into a stable orbit around Kerbin first? This is a situation of walking before you can run. It sounds to me like you are trying to launch from the ground, straight up, and hoping your trajectory will pass by the Mun if you fly up long enough. And it is possible to do this, but it isn't very easy to plan or execute. Instead try to put yourself into a circular orbit around the planet Kerbin first. The best way to do that is to start pitching your rocket over gradually in a long arc until you are aiming at the horizon around the time you leave the atmosphere. Then coast to the highest point of that arc (your apoapsis) and start a prograde burn there until you are in a complete orbit. Now that you are in orbit you can find the best time to start a burn to send you to the Mun. The best place to do that is when you can just see the Mun rising over Kerbin's horizon in front of you, and then burn prograde until your new orbit just touches the Mun's orbit. You won't need to wait any more time than one orbit to start your transfer this way. When coming back from the Mun you should be careful that your path entering Kerbin's atmosphere isn't too low or you'll either burn up or crash into the ground too fast. Aim for a periapsis in the atmosphere of about 30km and you should be safe. The air should slow you down, but this is assuming you are only reentering with the capsule and have detached the rest of the ship below it first. Now, maybe I have made some poor assumptions about what you are trying to do. If so, please let us know specifically what is different about which details are different in your approach and we can talk through it. Also here is a basic tutorial for landing on the Mun by the awesome Matt Lowne that might help. However, it does assume upgraded facilities but if your rocket can make it then you should be able to adapt his methods to your own.

@Gavin786 So I conducted an experiment that I think you'll find interesting. At first I tried the normal setup for a plane and found the exact same issue you found. The elevons were hitting the maximum travel with about four clicks left on the roll meter. Changing the sensitivity or dead-zone in the settings didn't help. For clarity, they were fully deploying but they were just doing so in a compressed time and before I had used the whole sweep of my gamepad paddle buttons. So I decided to try something. I placed two pairs of elevons on the wing of a craft, one inner pair and one outer pair. For the outer pair I set them up just like normal, with only the "Roll" actuation on. For the inner pair I disabled the toggles for roll as well as pitch and yaw. But I went into the action groups and in the "Axis Groups" I assigned the "Roll" action group to the inner pair of elevons, making sure to select the "Deploy Angle" function and setting it to "Absolute Control" instead of "Incremental Control." Now the inner pair of elevons should still respond to the roll input on my gamepad but it bypasses the normal roll assignment. If you remove one of those elevons from symmetry and invert the direction then they will function like normal ailerons without having to use the KAL controller. And indeed it did. The inner pair of elevons used the full width of the roll meter to reach the end of their travel, when the normally assigned outer pair would stop before the inner pair did. I don't know exactly what this means, and it's not ideal, but at least there is a way to gain full range of the axis without having to program a KAL controller. Unfortunately, they won't respond to SAS control in this configuration which severely limits its functionality.

@Gavin786 Sorry, I misunderstood your question at first. So, it's not the extent of the travel, but the how well it maps to your joystick controls that is the issue. Now that you bring it up, I'd like to experiment with this myself. I use a PS3 gamepad controller for my game that gives me analog control for flight that I can test with. I know that the mod Advanced Fly-by-Wire claims to do a better job of capturing and mapping analog inputs from joysticks and gamepads. It might be time to try that and see if it makes a difference.

The only adjustments I'm aware of are the tweakables in the right-click-menu for control surfaces that change the limiters for "deployment" and "authority." You may need to have advanced tweakables turned on in the game settings. The deployment slider changes the maximum travel of the control surfaces when they are toggled to "deploy on." The authority slider changes the maximum travel of the control surfaces via pilot or SAS input. I also believe that no matter how high you set the authority it will still be limited by the deployment setting. In other words, set the "deploy" slider to maximum and then whatever you set the "authority" slider to should give you the range of travel you are looking for.

I have a theory, but to confirm it I'll have to make an expedition to the ice walls around the northern latitudes to see if Slartibartfast's signature is carved there anywhere.

You said you've been using KIS and KAS to put these components together. I know that the contract system will usually accept vessel components connected by KAS as legitimate as I've done it many times myself. Did all of your Kerbals launch with these vessels after the contract was accepted? If you transferred the Kerbals over from craft that are older than the contract then it's possible they may be carrying items in their inventory that are also older than the contract. I don't know if Kerbal inventory items count against the contract but it's worth checking. When all else fails, and you are certain that the contract should be successful, then you can force it to complete by going into the Alt+F12 cheat menu, look for the contracts tab and then click the button next to the appropriate contract to mark it complete.

For a base or station to be considered "new" every single part of the whole base has to have been launched after you accepted the contract. It sounds like something connected to your base had already been launched before you accepted the contract. If those older parts are not essential to the contract requirements then you should be able to disconnect them and then the contract will usually complete successfully, but it's not guaranteed.

There are also two decouplers in the structural category. The Small Hardpoint and the Structural Pylon can be very useful for putting a little distance between boosters and separate cleanly.

Ideally, you add up all of the numbers between your starting point and your end point, remembering to add extra for any inclination change corrections you might need (typical inclination change amounts are listed next to the colored bar.) And also add the numbers again if you have to retrace your steps. For example: 3400dv to launch into Kerbin orbit + 950 to reach the edge of the Kerbin system + 980 to get a fly-by of the Jool system + 270 for a mid course inclination change + 160 to capture into high orbit of Jool + 620 to get a fly-by of Vall + 910 to get into orbit around Vall + 860 to land on Vall + another 860 to take off from Vall again + another 910 to escape Vall's orbit + another 620 to reach a high orbit around Jool again. Then work your way back down the Dv tree for each of your other destinations. There is however a LOT of variation possible. You can use gravity assists from other moons to alter your course. You could do aerobraking in Jool's atmosphere or at Laythe to reduce your dv requirements considerably. There's some bad news, however. It's basically impossible to do the mission you're attempting without bringing along mining equipment and ISRU converter to make fuel along the way. Tylo and Laythe each have extremely different landing and take-off requirements that a single ship is going to have difficulty handling efficiently for both. Tylo has no atmosphere and its gravity is about the same as Kerbin's. You basically need a fully fueled ship as big as what you use to launch from the surface of Kerbin for the landing AND fully fueled for the trip back up. Laythe, on the other hand, has an atmosphere nearly as thick as Kerbin's. And while that means that you can descend quite easily with just parachutes, you won't be able to get much thrust out of vacuum optimized engines for the re-ascent. I'm not saying it can't be done. But my choice would be to make a mothership that stays in orbit of these moons and have a couple of different landers optimized for their task.

@Boyster Let's go back to basics and try to understand what the navball is trying to show you. Regular airplanes have a navball like that in order to show the pilot their attitude relative to the ground. Here is a picture of one in a simple plane's cockpit. You can see it in the top row, second from the left. There is a gyroscope that keeps its orientation constant relative to the horizon. The center marker on that ball corresponds to the nose and wings of the aircraft and it's just fixed to the glass of the instrument panel covering the ball. But the ball "floats" inside that instrument panel so that the brown colored ground always stays down and the white lines always stay parallel to the horizon. So when the plane banks left or right, or pitches up or down, it looks to the pilot like the ball is rotating and turning around behind the center marker. But in reality a gyroscope keeps the ball level, and it's the PLANE that turns around the navball. Now, try and imagine you took this plane to space and were sitting in the cockpit. What would you see on your instruments if you couldn't look outside the spacecraft? You can't just poke your head outside and look around. The blue half of the navball is the part above the horizon of the planet. The orange/brown half of the navball is the part below the horizon. In other words, if your center marker (the level-flight-indicator) is below the horizon line (the part that divides the two colors) then your nose is pointing more towards the ground than the sky. If your center marker is in the blue part of the ball then your nose is pointing more towards the sky than the ground. This is no different than being in a plane's cockpit flying through the air. These instruments were designed to give the pilot information about where they are pointing because they COULD NOT see much outside their craft. And it's incredibly useful at doing that. You can accomplish almost any maneuver by looking at just the navball alone, and ignoring the camera view. The only time you can't really do that very well is when docking, and that seems to be what's confusing you. The navball is there to show you your orientation in relation to your direction of travel AS IF you were viewing it from inside the cockpit. Remember, the camera has NOTHING to do with the navball. The camera just lets you look around. It isn't intended to relate to the navball orientation. And there is a simple experiment you can do to prove this. When you are docking normally, to the front of the ship, and you need to use your RCS to move left then you would want to look down the ship towards the front. If the camera is locked in place then when you tap the left key you will see your RCS thrusters fire on the right side to push you left. Ok, great. But, what happens if you need to move the camera around to look backwards along your ship? When you are landing a ship upright on the Mun you will be doing this. In the final stages of your landing your navball will show mostly blue because your nose is pointing up away from the surface. But you will want your camera pointing down towards the ground so that you can see the terrain. Maybe there is even a base on the surface that you are trying to land close to. In this case you want to look backwards, but now when you tap left to go left your camera is turned around. Now the thrusters appear to push the other direction. But they aren't really, your view is looking front-to-back now. You have to mentally separate these two perspectives when you are operating your controls. It's not always easy, but you need both frames of reference in this game.

Sort of. NavHud projects the sphere of the navball into space around your ship. It's like putting your ship into the center of the navball. The camera just lets you look around the inside of that sphere. What's important to understand is that you can move the camera independently of the ship's orientation. Don't think of the navball and camera as connected at all, except in "Locked" camera mode. The game just normally allows you to move the camera around in arbitrary directions because sometimes you need to see whats behind you or underneath you, etc. But ignore the camera for a moment. In the NavHud projection look for that level-flight-indicator . See how it moves around in front of your vessel as you turn as if there's a rod attached to the nose of your ship connecting it to that point out in space? Now look at your navball. That symbol shows you the exact same thing - where your nose is pointing and in what orientation. The only difference is that NavHud allow you to rotate the ship within the lines of the "navball" that it projects into space around you; while the stock navball rotates the ball behind your direction indicator. As @VoidSquid said, I really don't think there is a way of assuming what orientation your camera is to the ship's navball unless you orient it with already known components like a hatch or markings that you took note of in advance. Except of course if you turn on "Locked" camera mode.