AHHans

That will only make the target indicator on the navball be the way you expect to be. But if the center-axis of the docking port on the currently controlled vessel is not going through the COM then a target that is moving directly to that docking port is not moving directly to the COM. Thus the target-prograde marker will not be in the center of the navball. You can test that by having several docking ports along the length of a station/ship, all parallel and oriented the same way. If you then switch "control from here" between these ports with a target in close proximity then you'll see that the target direction marker moves around as you would expect, but that the target-prograde marker does not. That's what I'm saying: if you switch to the other vessel (and set it up correctly) then you'll see if you are coming from the right angle or not, and in which direction you need to fly to correct that angle. [Edit:] Or you use one of the mods that were already suggested.

Yes IIRC they did. But please keep in mind that I wrote my comment nearly two months ago... Not if it costs them more that you are willing to pay them.

Learn your navball, love your navball! If you switch to the other craft (let's call that "station" - which doesn't move or rotate - as opposed to "ship" - which can move and rotate), select the target and "control from" the docking port, then that will show you if the ship is aligned correctly with the docking port. If the target marker is in the center of the navball of the station, then the ship is well aligned with the docking port of the station. The next item is that on the navball the target marker will move radially away from the target-mode prograde marker. So if you move the ship so that the the center of the navball, the target marker, and the prograde marker all align on the navball of the station, then you are on the way to get them aligned. As usual this takes lots of fine (and not so fine) tuning, so my method requires a lot of switching between station and ship. A further complication is that the prograde marker will point in the direction of the center of mass of the crafts, so if you want to dock to a docking port that is not aligned with the center of mass then you need to take that into account when you get close.

Righ click on KSP in the "library" -> Properties -> the tab "Betas" -> "Select the beta you would like to opt into:" -> select the version you want.

My $0.05. (Yes, feel free to convert that to rubles. ): a) I suggest to prepare save-files with the situation that you want to show already set up. Trying to "quickly set something up" when you are nervous is prone to go wrong. b) Did you discuss any maneuver already in class? E.g. if you already have talked about a Hohmann transfer or how to get into orbit in class, then I'd show that. c) For extra points with your teacher you can/should do some calculations on the blackboard and then show that in the game. In addition to the already suggested maneuvers (launch into orbit, Hohmann transfer) I have: - Demonstrate the Oberth effect: transfer from an elliptical orbit to a (wider) circular orbit, once starting at the PE and once starting at the AP. - Rendezvous in low Kerbin orbit, and the difficulties with knowing in which direction to thrust in order to get close to the target. P.S. I guess the most important advice is: show what you like to show and enjoy doing yourself. There is little use to e.g. try to demonstrate the Oberth effect if you don't understand it yourself. (Except maybe if you want to present it as "here is something that is a thing, but I don't understand it".) Also be prepared that your teacher may not know about the Oberth effect.

An update on this endeavor: after a version 1.8 induced delay of the currently also ongoing Eve mission(*), I finally caught me a suitable asteroid, and it is definitely one that I want to get into Kerbin orbit for closer study: According to my calculation I have 12km/s dV available if I use up all the mine-able ore in that asteroid, and the maneuver node says that I need about 4 km/s at the PE to eject it from the sun. (The current orbit is between Eve and Kerbin.) So I should have enough ooomph to get the contract done, and then slow down into an intercept with Kerbin. But there is some more tricky maneuvering to be done on and around Eve and another asteroid to catch, before this craft gets to the PE. So it might take a few days before that happens. (*)I believe I already complained enough in other threads... P.S. Yes, that's my first "magic" asteroid. P.P.S. In the meantime I accepted a contract to rescue Asler from a low orbit around the sun. (I guess I never learn...) [Update 16. Nov.:] After the activity on and around Eve had coalesced into one big group-hug on Gilly-Station, I finally got around to maneuver the asteroid. One humongous cloud of slightly radioactive vapor later I had not only fulfilled the contract but also have the asteroid on a course to intercept Kerbin.

Well, time to read the fine print of the contract: does it say anything about the condition in which Sigton needs to be returned on Kerbin? Except "alive"?

Well, I did. E.g. when counteracting the torque of a single engined prop plane, or when trying to push a prop plane to its maximum ceiling on Eve. In these situations SAS just doesn't cut it.

Yah, well, it also took me a few tries. It steered really strange, roll and yaw worked O.K. but pitch didn't, then it did, then it didn't... Then I noticed that the control-input indicators for roll and yaw moved fine but the one for pitch didn't move (when I pitched up). That's when the light-bulb went off. It is mainly useful for airplanes, that's true. (Especially if you only have keyboard+mouse and need fine control.) But in my experience it is mainly used on rovers, e.g. when someone wants to go somewhere fast and - in addition to pressing <W> to drive forward - activates physics warp. (I've had a rover doing somersaults as soon as I deactivated SAS one time.)

Well, ECs and commnet connection are there. (Not a good connection, but good enough, there is a communotron 16s on the rover). But what it also has is full downwards manual pitch trim! You can see this by switching off SAS: the craft will start to rotate. With SAS on this will be countermanded by SAS. But you cannot manually pitch upwards anymore. (Which is the direction you need to go in the situation on that quicksave.) With <R-Shift> - <X> on Linux (afaik <R-ALT> - <X> on Windows) you can reset all manual trim, after that the craft becomes more controllable. Also: we don't need the full save-file directory! The single file "quicksave #4.sfs" is all we need! (In other words the zip file makes it harder for people to help you.) And I'll suggest to the moderators to move this to the Gameplay Questions and Tutorials subforum.

Postscriptum: I just noticed that in my current career I have a similarly impossible sentinel contract on offering. (I haven't accepted it, and I don't think I will. ) So this is indeed a new bug in KSP. I also found that there is a new bug report on the bugtracker: Bug #24282

I didn't want to say it's impossible, but if that's what it takes then I'm not interested at the moment.

Hmmmm... I just re-created that vessel, added a decoupler and a kickback, and kickback-ed it into space. (SCNR) Once outside the atmosphere I decoupled and selected retrograde/surface. It entered the atmosphere at about 2100 m/s and hat no real problems. (A temperature-gauge on the science junior showed up for a few seconds, and at the end it couldn't keep itself fully retrograde anymore, but that's it.)

Safety margin and speed? So that you don't need to re-do everything if you mess up your ascent profile. "Not having to think" is the number one reason why most people do things. There is a huge difference between <T> <Z> <SPACE> and really thinking about the ascent profile.

Nice analysis! I personally use option 2a: Leave the oxidizer in the tanks in case I need the high thrust at sometime during the mission. Well, actually, most of the time it is option 3: refuel with only Lf. (Or 3a: try to refuel with only LF, but forget that there is a convert-o-tron set to LfOx somewhere on my refueling station...)

As already said by @Space boy: don't worry about your English. And, yes, your thanks are understood. Extreeeme Science Farming? Unlocking the tech-tree without leaving the KSC?

I just saw that there is currently an ongoing discussion about the fact that a "transmit science" action is missing from the laboratories:

Hi @NISHIHI. Welcome to the forums! Indeed. I could not find an action that can be put into an action group and that will transmit the science in a mobile processing lab back to the KSC. (Like the "transmit science" option in the right-click window of the mobile processing lab does.) I agree. But I do not see another way but to click on each single laboratory and transmit the science one by one. The English text is not easy for me to understand, and I'm not sure I really understood your question. Please keep asking if your question isn't answered or you have more questions.

I don't really recall what I used to fulfill that, but it wasn't much. On the Mun, Minmus, and Ike I just dumped spent upper stages that I used in the transfer to these bodies or stuff that I had flying around in orbit and wanted to get rid of anyhow, without seriously aiming for the seismic detector site. (On Minmus I didn't even crash the crappy lander that I used on my first visit there, it doesn't have a probe core and by the time I got a Kerbal to it I had already maxed out the seismic science.) Duna on the other hand was a different story. The atmosphere is pretty thin, but still thick enough that I had to build a dedicated (and streamlined) impactor craft and aimed it for the detector site to get the contract fulfilled. (After that I decided to not accept a deployed seismic science contract for Eve!) My standard probes use a FL-T400 and a terrier for propulsion (and then probe cores, solar panels, antennas etc. to match the job at hand). I think one of those might already be enough if impacting at high speed close-ish to the detector. Two of them should be plenty, four overkill.

Well, I think I would prefer actions "Set play position to start" and "Set play position to end" that can be added to an action group. (And are executed before the "Play sequence" action.)

I suggest that you upgrade to 1.7.3 (or 1.8.1) plus the corresponding version of BG. 1.7.3 fixed quite a few bugs in BG. Then the two usual suspects for stuck robotic parts are mods and autostruts. Don't set any autostruts on the robotic parts themselves. I haven't really tested 1.8.1 (yet?), but with 1.7.3 they tended to get the part to get stuck under many (though not all) circumstances.

Well, yes, that orbit won't work for Duna! (And also not for Dres because the inclination is wrong.) You could try to see if an orbit that is just inside Duna's orbit will be accepted as being close enough to the contract orbit. But, to be honest, that doesn't look likely to me it's just too far out. (Or did you try that already?) In such a case I would use the cheat menu (on Linux <Right-Shift> - <F12>, on Windows <Alt> - -<F12> or so) to mark the contract as completed. In my books this is working around a bug and not cheating. Are you using any mods that could mess with the contract generation system? Or is this a bug in the stock game?

First: solar powered electric planes are not only possible with Breaking Ground but also fun. With the blade pitch you have more or less direct control over the airspeed, which makes landing sooo much easier! And the essentially direct throttle response allows for fun aerobatics (or a quick go-around if needed). Second: for a (somewhat) speed optimized design 167.0m/s airspeed is easily achievable. So it should be possible to do what you are thinking about. But one major drawback of the BG propellers is that they are very physics-warp unfriendly! If you switch on physics-warp while the rotors are turning then the blades on your propellers will develop a mind of their own without any regard of what the rest of the "propeller" might do or want. At least with 1.8.1 the propeller isn't immediately screwed up as it was with 1.7.

LOL! Yes, been there... (Although I don't think I ever killed a Kerbal because of that specific issue. But plenty of "OMG where the *bleep* am I going?" moments.)

Well, then it won't be able to find any asteroids. This message means that your orbit is too high around the sun to be able to map asteroids around Duna, and not aligned well enough with Dres to map asteroids around Dres. To be able to map asteroids the sentinel must be in an orbit around the sun inside the orbit of the target planet (I take it as: the probe's PE and AE must both be larger than the AP of the next inner planet and smaller than the PE of the target planet), and the inclination, eccentricity, and longitude of ascending node also need to be close to matching the target planet. It is less important to exactly match the orbit that the contract specifies, and more important to be on an orbit that allows the sentinel to function in the first place. Although obviously you need both, but as I already wrote: it is very generous when deciding that you are on the prescribed orbit. On the other hand, the status on the sentinel needs to say "Mapping Duna" (or whatever target planet) or it just won't work! The inclination that the contract text mentions is the inclination of the orbit of the asteroids, not the inclination of your spacecraft! The latter needs to match the inclination of the target planet. As I said: you only get the green check mark while you are controlling the craft that is actually doing the mapping. That the green check mark goes away when you switch to the KSC or to another craft is normal and doesn't keep you from finishing the contract. What is a problem is that you are not in a correct orbit to map anything. To have that you need to be in an orbit where the status on the sentinel says "Mapping Duna".