AHHans's post in Resource Overlay Not Showing was marked as the answer
You can switch the overlay on and off in that tab. Did you switch it off by chance?
Edit: The switching is done by clicking on the "ore" line in the tab.
AHHans's post in Probe not working was marked as the answer
No, you can't. The Mk2 command pod does not have the capability to control probes. For that you need the Mk1-3 Command Pod, the Mk2 Lander Can, the Munar Excursion Module, or one of the two Remote Guidance units on the piloted vessel.
Have a look at the table on the wiki page that @antipro mentioned. If you use only a command pod you will need two pilots to control probes from the craft.
Your piloted craft has the RC-001S Remote Guidance Unit on board, so it works with only one pilot. Without that you would need two pilots in the Mk1-3 Command Pod.
AHHans's post in How to launch my station's arms was marked as the answer
Another solution is to launch the arms as they are in a way that you can decouple them in orbit - where they would just drift uncontrollably without any external help. And then have a small tug that can dock to the shielded docking port and maneuver each arm to their destination.
AHHans's post in Is it safe to leave a mining drill and ISRU operating unattended? was marked as the answer
Once they are outside the physics range, then the worst thing that the ISRU and drills do is to not mine enough ore / generate enough fuel. The problem you had was because you were time-warping while having the mining rig in focus. For some reason the heating and cooling calculations during time-warp are messed up, so some parts get really hot while time-warping at one speed while being fine when time-warping at another speed and/or at normal speed.
AHHans's post in My Clumsy Docking Intercepts: Help me clear up the confusion? was marked as the answer
For all practical purposes: yes. If you are close to each other and have the very little relative velocity then you are on near identical orbits. (It is only my nitpicky part, that insists that unless you are exactly at the same location with zero relative velocity then you are technically not on identical orbits.)
(Seriously: I thought about other smart things to say, but they all boiled down to saying "no" with more words.)
Double click on the ship (or docking port) you want to target in ship view. Or right-click and select "target this" in the PAW.
I use essentially the method described in @Snark's Illustrated guide to docking. Some of my space stations are quite large and with "wiggly" bits sticking out (e.g. a big-ish ship docked with a standard size clamp-o-tron). So when docking I usually don't move the "station" at all(!). (I do switch between ship and station often, to check the alignment of the docking ports, so that I don't need a docking port alignment mod. But when controlling the station I only look at the navball and take care not to give any movement input.) When the ship and the station are close enough to each other, then the orbits are also close enough that I can take my time to maneuver the ship into the correct position for docking. Typical relative velocities when doing that are < 5 m/s. (And for actual docking I usually slow down to 0.1 m/s, so that the prograde marker just vanishes.)
The one thing I do in the VAB is to set up RCS and the reaction wheels so that I control the attitude (yaw/pitch/roll) with only the reaction wheels and use RCS only for translation.
AHHans's post in Gravity Turn ascent trouble. was marked as the answer
As I wrote in my other answer: the problem is not that the rocket has a problem keeping the orientation that the autopilot wants it to have, it is that in order to keep the time to apoapsis from falling to autopilot steers the rocket further up.
Have a look at the thrust setting at the navball and the yaw indicator in the bottom left: while stage 6 is running the autopilot throttles down in order to not increase the time to apoapsis above 50s while still pointing prograde. After staging it first increases the throttle to max, and when that still isn't enough it yaws to the left to raise the nose and increase the time to apoapsis again.
AHHans's post in Gravity Turn ascent trouble. was marked as the answer
Your time to apoapsis (AP time) is dropping below the 50s that you told the mod to keep. So the mod points the rocket more to upward to increase the AP time. The first two stages had enough TWR to to the AP time at 50s even with this flat trajectory, but the third stage has lower TWR so it struggles to keep the AP time up.
The yaw control input isn't maxed out, so it isn't a problem with aerodynamic instability.
AHHans's post in Probably Stupid Deployable Science Question was marked as the answer
I guess this is a FAQ now...
Have a look at what I wrote in this thread: Go-ob ED lost connection with control station after collecting all science
AHHans's post in How do i stabilize unbalanced ship? was marked as the answer
The video looks to me as if the craft is as stable in the air as I expect it to be. You do need more thrust to get into the air though: your craft only "hopped", the engines didn't have enough thrust to get it into the air on their own, but a small impulse from the landing legs hitting the ground got it to bounce quite a bit into the air.
Hovering on engine thrust is notoriously unstable, the one reasonably "easy" way to do this is to control it from a control point that looks up (e.g. a probe core that looks up) and then use SAS in surface "radial out" mode, that will tell SAS to (try to) keep your craft stable.
Yupp. What else is the tail rotor supposed to do?
Seriously: rotors in KSP have relatively high torque, so they'll try to rotate your craft around the rotation axis of the rotor. In addition the direction of thrust of the tail rotor doesn't make sense to me. What do you want it to do that isn't better done by the reaction wheels?
Try setting all the hinges to "locked" before you have the landing legs touch the ground, only move the hinges when you are in the air and make sure that they are all locked again before you touch the ground. (Sometimes setting locked doesn't hold on the first try and you need a few tries.) There are two reasons for that: one is the inherent weakness of the robotic parts and the other that with landing legs directly attached to non-locked hinges means that the mandatory autostruts of the legs more or less go to themselves, which is kraken-bait.
AHHans's post in Rendezvous two vessels not completing was marked as the answer
Indeed! For the rendezvous, dock, or crew transfer the two vessels must have been launched in two different launches. But it is O.K. to dock them in LKO, have them travel together to the destination and undock there.
AHHans's post in How Many PB-NUK generators do I need for a RA-100 Relay in a 50Gm orbit over Kerbol? was marked as the answer
CommNet relays don't consume electricity. So you only need enough generation capacity to get it into position (and then have some ECs to spare). I personally would add enough generation capacity to keep the probe core powered and to recharge the batteries over time. So one RTG is plenty and there is no need to spam batteries.
AHHans's post in Duna base explodes when I go back to it was marked as the answer
Well, my approach in a similar situation (it was a landed plane, not a base) was to <R-Shift> - <F12> (yes, I use Linux) and to activate essentially all the cheats before switching to that plane. Then when it was done jumping around and was again standing on the ground I deactivated all the cheats.
AHHans's post in Question about Comms - since that's new to me as well... was marked as the answer
I guess the most important things have already been said, but some additional information.
Electricity on the relay is (nearly?) never the issue. Relaying radio signals does not consume electricity! (Yes, yes, that's strange and not how it is in RL, but in KSP it is.) So as long as the relay had some ECs in it's batteries when you last visited it it will be able to relay signals.
It is also possible that your lander doesn't have LOS to the relay, but I guess you already checked that. More importantly: you can activate a display of the commnet connectivity in the map view, or the tracking station. That can show you between which craft you do have a working commnet link.
There is a rather comprehensive wiki page about how the CommNet works. You can also increase the effective antenna power of a vessel by putting more antennas on the vessel (except for the Communotron 16S which doesn't play together with any other antenna), but this quickly runs into diminishing returns (see the explanation on the wiki page). I usually put up to eight HG-5 antennas on my early game relays, not because they have much more range than relays with four of them but because the HG-5 are cheap and weight next to nothing so it just doesn't matter.
AHHans's post in Fuel economy: Poodle vs Reliant (traveling to moons) was marked as the answer
Yes, there is a significant difference which is that - for maneuvers in vacuum - the poodle gets significantly better fuel economy. But that has nothing to do with the amount of thrust that the engines generate, but with the specific impulse - the Isp values - of the two engines. Higher Isp means that the engine uses the fuel more efficiently. But the Isp value of an engine depends on the pressure of surrounding atmosphere. The Poodle as a high vacuum Isp (350s, one of the highest in the game) but its Isp at sea-level on Kerbin is a lousy 90s. So the Poodle is good for maneuvers in vacuum but really bad for lifting anything from Kerbin. The Reliant has a decent Isp of 265s at sea-level on Kerbin but only a mediocre vacuum Isp, making it a good booster engine to lift stuff from Kerbin, but not the first choice for vacuum maneuvers.
Yes, with a Terrier you have less thrust and thus a longer burn time. But once you are in orbit it doesn't matter much how long a burn takes (and if it takes too long then you can usually split the maneuver into two burns(*)). What does matter is how high your Delta-V (the rocket-man's equivalent of how far your fuel will take you) is, and this depends on Isp.
You are probably confusing this with the situation of launching something from Kerbin - or any other planetoid - into orbit. There the TWR does matter! (Which becomes obvious when you think about what happens if the TWR is smaller than 1.)
P.S. (*) Yes, there is a limit when a low TWR leads to efficiency losses also of orbital maneuvers. But in KSP the practical limit is usually the patience of the player when burns become just way too long.
AHHans's post in Aerodynamic Forces Pink/Green? was marked as the answer
Blue = Lift from wings
Well, you got that. With "direction of lift" == perpendicular to the plane of the lifting part.
Red = Drag
That's also an easy one. Here is "direction of drag" == in the direction of the apparent wind.
Yellow = Lift from control surfaces
Like blue, but can change direction when the control surface moves
Cyan = Body lift from non-wing parts
If you move a non-wing part at an angle through the air then it will generate not only drag but also some lift. Think e.g. about a structural panel that's angled like a wing. (But I'm not 100% sure about that, so feel free to correct me.)
Green = Indication of rotation direction and angular speed
See KSP 1.9.0 / BG 1.4.0 changelog: "* Blade rotation axis shown as green arrow in aero debug display. Length is logarithmically proportional to rotation velocity (vessel relative)."
Pink = "Cheated extra thrust/lift of propeller and helicopter fan blades"
The game engine can only handle a rather small rotational velocity (it is approximating the rotational motions with linear motions), that would result in rather small lift from any kind of realistically sized propeller or helicopter blades. (Real propellers rotate much faster.) So SQUAD "cheated" some extra lift onto the propeller and helicopter blade parts to give the propellers/rotors some reasonable thrust.
AHHans's post in rendezvous 2 vessels in orbit of jool was marked as the answer
It's not included in your short clip, but that part is in my experience the important part: those two vessels launched from Kerbin in two different launches!
At that distance the other craft gets unloaded from the game, i.e. the physics for this craft is not calculated anymore and it is put "on rails". And apparently the game partially forgets that you have that selected as a target.
This distance is also important for the "rendezvous around <planetoid>" contracts: you have to be at least that far apart and then get closer (again?) and match velocities to get these contracts done.
AHHans's post in jool hardworking contract was marked as the answer
How about launching two vessels, docking them together in Kerbin orbit, transfer to Jool, undock them again, transfer crew, transfer crew out of one of the vessels, and then dump the "empty" vessel into Jool's atmosphere and and return with the other.
AHHans's post in Sentinel orbit above Kerbin was marked as the answer
It's a bug, see my answer in here:
how to complete asteroid tracking mission
AHHans's post in Data size (MITS) for deployed science reports was marked as the answer
It needs the ECs when you use it as the transmitting antenna on the craft where you are transmitting from, in contrast to relaying data that is being transmitted from another craft.
From your screenshot I can also see that the Go-ob has shut down after finishing the experiment but without transmitting all the science. Have a look at my explanation here: Go-ob ED lost connection
And, yes, with a relay network like that you should have round the clock connectivity to the KSC. I don't know why you got the "no connection" messages. I've seen that you have two experiment stations on Minmus. That's not needed the experiments are only planetoid specific not biome specific. And maybe (maybe!) this message is what KSP generates when you try to transmit deployed science that has already been transmitted from another station. You can check in the archives in the science lab if you got all the science from the experiments.
AHHans's post in one of the stages needs double spacebar push was marked as the answer
Because the staging setup got re-arranged automatically by KSP when you activated the previous stage.
Your staging setup has as stage 0 four parachutes. But these four parachutes are detached when you activate stage 6, so the old stage 0 doesn't make any sense anymore. So KSP re-arranges the staging setup and either to warn you that it did something or because there is now one stage less you need to stage twice to stage the next stage.
AHHans's post in return to kerbin from the surface of eve was marked as the answer
Yes, in a way. Any command module (a probe core, a cockpit, a command capsule, etc.) has an internal "flight recorder" that records where it has been (in orbit around Kerbin, landed on the Mun, whatever). To fulfill the "land on Eve and return" contract you need to recover a command module that has "landed on Eve" in it's "flight recorder".
So, no, you don't need to return the root part of your rocket, but the command module that you used on your lander. (Or one of them if you e.g. had a crew capsule and a probe core.)
You don't need to redo the full mission if the lander still exists, you can also retrieve the lander from Eve orbit. (Or you can use the cheat menu, that's always a possibility.)
AHHans's post in Docking Issues was marked as the answer
Hmmm... looks fine.
Are you coming in at an angle? If you select "control from here" on the docking port on the controlled vessel and "set as target" on the port of the other vessel, then the target marker on the navball with be in the center when the target port is straight ahead of the local port. If you do that on both vessels (switch between them with "[" or "]") then you can see if they are aligned correctly.
There is also an IMHO useful guide here:
(This guide uses a mod to check display the alignment on the target vessel, I flip between the vessels to do the same thing.)
P.S. One thing about the vessel(s): you don't need to attach the RCS thrusters to the monopro tanks, you can attach them anywhere on the vessel. And if you space them out more evenly around the center of mass of the vessel then your vessel will not rotate (as much) when you want to translate or translate when you want to rotate.
AHHans's post in sudden instability 100m from Tylo landing was marked as the answer
Hi @Quasispecies, welcome to the forums.
Are you using SAS retrograde hold while landing? In that case it could be that it tries to keep up with the retorgrade direction that starts to wildly change when you slow down to a near stop. SAS is supposed to switch off retrograde hold when your speed goes below 1 m/s, but if the speed changes too fast then it can get confused and keep retrograde hold when it shouldn't.
Or are you using another SAS mode? If so, which one?
AHHans's post in Is it possible to get back from eve's orbit to kerbin with only 464 m/s of delta v? was marked as the answer
My first though was: "No from that low an orbit you don't." Then it occurred to me that 48 km is within the atmosphere of Eve. But your screenshot says that you are in an 48 thousand km by 13 thousand km orbit, just next to Gilly. From there it can be done in theory: from your apoapsis you need about 200 m/s to drop your periapsis down to just above Eve's atmosphere, to say 100 km - 150 km. If you then burn at the periapsis of this highly elliptical orbit you need less than 250 m/s to leave Eve's SOI with enough speed for a Hohmann transfer to Kerbin, where I hope you can aerobrake. (If you can't aerobrake, then you won't be able to capture at Kerbin with that amount of fuel!) The problem with this is, that you have to get lucky for everything to line up: the ejection angle from Eve's SOI is essentially fixed by the need to do the two burns at (or at least close to) the apoapsis of your current orbit and the periapsis of the resulting, elliptical orbit. And this direction needs to line up with Eve's orbit to get you on a Hohmann transfer and a transfer window from Eve to Kerbin. My approach would be to get onto that elliptical orbit, set up a maneuver node at the periapsis with 230 m/s or so, and then use the "next orbit" button until I get a solution that is close enough that I can fine-tune it to an encounter with Kerbin.
(Well, actually I would just get back to Gilly's SOI, and send a rescue mission. But that wasn't your question.)
Another version would be to use gravity assists to get you back. But I suck at those...
P.S. Please don't change the default font size of your text. For me the large font is just annoying.
AHHans's post in Skip-glide entry with capsule? was marked as the answer
Well, I understand that article in the way that "boost-glide" means "extend range of suborbital flight by using aerodynamic lift". And, yes, you can do that in KSP: get a capsule onto a reentry trajectory and then either just point retrograde (with the bottom perpendicular to the direction it is flying), or angle the capsule a bit upward of retrograde. In the latter case you'll land a bit farther along your orbit.
As you mentioned this is not very useful with capsules in stock KSP. Not in the least because they don't have enough lift to really steer you to a certain landing spot. But when landing a spaceplane that's in my "toolbox" for getting the spaceplane back to the KSC. In particular when I do a reentry from the Mun (or Minmus) and need to aerobrake over multiple orbits (like I did in the trip that I did for the K-Prize).