AHHans

You can use the cheat menu (on Linux: <R-Shift> - <F12>, on Windows <R-Alt> - <F12>) to "cheat" a craft into orbit around any celestial body or onto the surface of a CB. I personally don't call that "save-scumming" but "in-game computer simulation".

Welcome to the Forums. Two tips come to my mind: one is to split up your burn: e.g. when transferring from LKO to another planet first plot a maneuver node for the transfer (so that you get the position on your orbit mostly right), then reduce the burn for that maneuver so that you stay in Kerbins SOI (e.g. up to about the Mun's orbit but without encountering the Mun), do that burn, and then do the transfer burn from that elliptical orbit (the maneuver node should be close to the PE of that orbit). The second tip is that you can activate physics warp while firing your engines: on PC with <right-shift> - <.> (i.e. like "normal" time warp but with <right-shift> pressed). That will reduce the amount of playtime that you need for such a burn. Another comment: my personal rule is to not have a craft with a TWR in LKO less than 0.2 (i.e. a craft with less than 0.2 g acceleration). That is just too painful. (And too long burns become inefficient.)

Oerks! That's pretty extreme. The landing legs have fixed autostruts to the heaviest part, so when you lock the hinges they'll try to get an autostrut to the tanks on the rotating wings. Maybe it will help if you have a "fixed" heaviest part that is not on any moving structure. Maybe it helps if you lock the servos for the wings before locking the hinges for the landing legs. But that's "maybe". I don't really have a good idea how to solve this. Not really. Rotating the wings creates a torque and that torque will rotate you craft somewhat. If you had SAS locked to a fixed position (e.g. a control point that looks up and SAS set to radial out) the SAS would do a better job of keeping your craft steady. (But still probably not a perfect job.) Locking the servos should help. But that will also freeze the position of the wings at the time the lock takes hold, i.e. freeze them mid-wobble, which may not be what you want. One (somewhat cheaty) thing that might help you is to have a set of fixed jet engines for horizontal flight, which are not connected to the wings. That way there is a lot less mechanical load on the wings which should keep them from moving and probably also reduces the wobbling. Maybe just have two sets of fixed engines: one for horizontal flight and one for vertical flight, and then instead of rotating them only switch from one set to the other.

To just enter into a low, equatorial orbit around any planet or moon use the default values except for "Semi-Major Axis" in which you can put a zero. Then when you click "Set Orbit" the first time you get an error message that your orbit was too low and that the value has been adjusted. Clicking on "Set Orbit" a second time will then get you into the lowest orbit that the cheat menu will let you. Another issue is: this thread is already pretty old, it would have been better to start a new thread with your question. [Edit:] I just saw that you did start another thread, so disregard that part. And welcome to the Forums!

Hmmm... I don't know how sturdy the connections of the aircraft parts are without KJR, but in pure stock with MK3 parts it shouldn't fall apart that easily. (I.e. only fall apart if you do a really hard landing or try to pull up at supersonic speeds.) Do the actual connections between the parts fail, or does one central part fail and then everything becomes separate "craft"? Some more ore less random comments: I usually autostrut everything to "grantparent" and this seems to help quite a bit. Don't bother using manual struts between parts that are already directly connected or use more than one strut between two parts. I'm not 100% sure, but I guess that just doesn't give you anything. Rigid attachment makes connections less "wobbly" but (much?) more likely to break. So that won't help you here.

Yupp. That's one thing I like about KSP: there are many different ways to play it!

Some more requests for clarification: What are valid destinations? Only the moons of planets (i.e. Gilly, Mun, Minmus, Ike, Laythe, Vall, Tylo, Bop, and Pol), or also the planets themselves? If planets are also valid destinations, are the following destination points correct? Moho: 50 (distance) + 20 (size) = 70 Eve: 20 (distance) + 40 (size) + 30 (atmosphere) = 90 Duna: 20 (distance) + 20 (size) + 20 (atmosphere) = 60 Dres: 20 (distance) + 10 (size) = 30 Jool: 20 (distance) + 40 (size) + 50 (atmosphere) = 110 Eeloo: 40 (distance) + 10 (size) = 50 If it's only moons, then Laythe is the highest scoring, correct? (With: 20 (distance) + 20 (size) + 20 (atmosphere) = 60.) Well, tied with Tylo. The "Be able to get to moon orbit to moon surface using one stage" requirement is not about the final, high value destination but about one of (or all???) destination(s) before that, correct? That would mean that going to Gilly and then to Eve would be fine? What about if one would visit all biomes on Gilly and Eve? Is is O.K. to play with CommNet disabled? I.e. having full control even if no connection to the KSC exists? (To transmit the science I would need that connection, but then I'm usually not moving through an atmosphere or be in the shadow of a planet.) If I see that correctly then the "Grand Tour" translates for the stock system to: "land on Bop, Pol, and Vall and then on Jool with either the same or a second lander" (Well, yes, you don't have to do it that way, but that seems the easiest way to me.) What about landing in different planetary systems? E.g. on Minmus, Ike, Gilly, and Eve? [Edit:] P.S. Kudos to anyone who can already predict what kind of lander I made just from my questions.

Well, that is also a tried and tested method of Kerbal engineering. (Although it is more traditional to upgrade the power capacity on a craft because you forgot to install them in the first place, not because you didn't have the right parts unlocked. *looksatmyValllander* ) I dealt with the efficiency issue by going big. My Kerbin system refueling setup is a station in a 500 km "gateteway" orbit around Kerbin and a big miner that goes to Minmus for refueling. The miner has the full mining suite (2 drills, one large convert-o-tron, and support equipment) , space for 18.000 units (180 tons) of ore, and enough thrust and fuel capacity to get into Mun orbit with a full load (not that I do it, but it could). So to get from Minmus to docking at the station it has to refine ore on the way, the end result is that it can deliver 10.000 units of ore to the station in one round trip. In other words: more than half of the fuel that was mined on Minmus gets "wasted" on the trip to Kerbin orbit. That doesn't sound very efficient, but on the other hand for each round trip I get 100 tons of useful fuel on my station. Which means that I can fuel up several "reasonably sized" interplanetary craft with one round trip of the miner. And when I fuel up something like a Nauvoo class station then that is moved to Minmus orbit to be refueled there, allowing the full 18.000 units to be transferred each round trip. So there are several ways to tackle this issue.

Hmmm... Are there any destinations in the stock game that are worth 90 points?

Actually the resource transfer rules do not apply to fuel / oxidizer / monoprop that is freshly created with a convert-o-tron. That newly created fuel will also be added to tanks that are only connected via a claw. (I use that "exploit" regularly to refuel some of my craft. My reasoning is that if I have an engineer that can run can complicated ISRC refinery then they can also rig a fuel line to the connected craft.) I haven't tested if this also work for ore - i.e. if freshly mined ore is also filled into tanks on the other side of a claw - but I would guess that it will work. The drills should work. But the fixed radiator panels will only cool their parent part and the parts that are connected to their parent. I.e. in your setup the convert-o-tron will not be cooled! Add some radiator panels to the upper fuel tank or use the (extendable) thermal control units. (The latter cool every part in the craft.) There is way too little electricity generation power on that craft! You'll need at least 2 Gigantor XL arrays to power a Convert-O-Tron 250. More are better! I think I have at least 6 on my craft. The EC consumption of a convert-o-tron depends on the level of the engineer on the craft. Also, if you want to run that during the night, then you need *bleep*loads of battery power. Again: more is better! Four Z-4k batteries are O.K. for my miner on Minmus if I don't use a high-lever engineer. (Whenever I think I finally added enough batteries my engineers gain more experience and the craft run out of ECs again. ) I don't know if an engineer in a passenger cabin is good enough. My guess is yes, but I don't know. Other notes: I usually have my mining rigs in one craft, i.e. drills, ore tanks, convert-o-tron, batteries, and solar panels together. I also have one "rover" with mining rig and a claw on the nose that can grab a stranded craft, deploy its drills, and refuel the craft. (Or use that claw to grab a stranded capsule and lift it into orbit again for Mun / Minmus surface rescue contracts.)

Well, I got really good at orienting my rescue ship so that it's lit hatches were facing towards the Kerbal to be rescued, and to navigate an EVA Kerbal in near complete darkness. ... Until I read somewhere (probably here in the Forums) that Kerbals on EVA have lights... So: Welcome to the club! I guess you wanted to write 500 m/s dV.

Errr, yes, that happens, too. But @bewing is right: fiddling with the spring and damper setting is the way to go. (Although I would guess that you'll need higher spring settings.) At some settings it will be more unstable, but at other settings it should be reasonably stable. Figuring out which settings you need is a black art of KSP rover design.

You don't!? 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.

Ah, yes. Sometimes there is a bug, in which the game doesn't accept any "normal" input. Saving and reloading fixes that, but also opening the cheat menu (<R-Shift> - <F12> on Linux, AFAIK <Alt> - <F12> on Windows) and selecting "clear all input locks" can usually fix this.

I think that's the main issue. In addition it also might be that the thin connection there has too little mechanical strength and "bends" under stress. In that case SAS can actually make things worse.

Is there a pilot on board and in a command pod, or "only" scientists and engineers? Also, if you ran out of electricity then the reaction wheels (e.g. the RWs in the command pod(s)) cannot turn the craft anymore. So the craft won't move when you try to turn it. (Hmmm... but switching SAS state should work with a Kerbal in control.)

Just wanted to add that this is actually documented in the KSPedia, e.g. on page 137 on the pdf version here.(*) You can also see which kind of control you have by looking at the icons in the upper left corner of the flight screen (which are explained on page 136 of the KSPedia document). (*) As of 7. June 2020. IIRC SQUAD does update the document when they update the KSPedia.

You're welcome. (Well, I didn't do anything here to deserve the thanks, but I hope you get what I mean.) My suggestion would be to practice rendezvous and docking a bit in Kerbin orbit. It is one of the more complicated and less intuitive maneuvers in KSP. (And in RL the crew of Gemini 4 failed when they tried this.)

Oh *bleep*! Yes, that could be. Why aren't they on by default? Or at least switch on as soon as you register for a Forum account? P.S. And while you are at it: also switch on the "Extended Burn Indicator".

It is a 'sub-game' as you call it. Maybe it is easier to understand when you have a look at the directory structure in the "save" folder of your KSP install. If you look in '.../Kerbal Space Program/saves/' you'll find sub-directories for all the games / playthroughs that you started from the main menu (plus some for the scenarios and training etc.). If you look into one of these sub-directories (e.g. your '.../Kerbal Space Program/saves/orbit attempt/' then you'll find the sub-directories "Backup", "Ships", and "Subassemblies" (which contain some backups of the autosaves, the *.caft files of the ships you created in this playthrough, and the subassemblies of this playthrough respectively) and you find a number of *.sfs files with their accompanying *.loadmeta files. The *.sfs files are the actual save-files and the *.loadmeta files contain the "thumbnail" and will be (re-)created by KSP automatically if needed. Each *.sfs file is completely self-contained and contains everything that is needed to start the game at the point it was saved. And as @Snark wrote two of the *.sfs files are special: "persistent.sfs" is the file where KSP writes the autosave to and it is the file that is loaded when you start a game from the main-menu, "quicksave.sfs" is the file that KSP writes to when you press <F5> and which KSP loads when you press <F9> for several seconds. When you write a save from the <ESC> menu or via <ALT> - <F5> then it will get the name that you enter there. But all *.sfs files are the same, you can copy and rename them around as you like. You can also copy a career-mode *.sfs file into a sandbox-mode directory and once you load it there it will be a career mode game (or any other way around).

It is still there. To Access it you need to access the Part Action Window (PAW) of the part by right-clicking on the part. In that window there is an option to "Aim Camera" to this part. E.g. here:

Well, one simple answer is that parachutes will only work in air, so they won't do anything on the Mun or Minmus. About how to actually do it, let me just forward you to Scott Manley's video: I personally use the method with the rover hanging below the lander, but then I construct landing legs that extend beyond the rover so that the lander can land normally with the rover attached.

I recommend to have a look at @Snark's Illustrated guide to docking, IMHO it is the best guide to docking around. One important thing is to learn how to read the navball! As someone recently commented: when you activate fine control (<Caps Lock> by default) then the game will adjust the RCS thruster strength to not induce rotation when translating (if possible). So that isn't a big issue. What I do on my craft is to deactivate the rotation controls on the RCS thrusters so that rotation is only done with the reaction wheels and I don't have RCS rotations throw off my translation during approach. Other than that: as @Streetwind wrote: practice, practice, practice.

Yes, that's (one part of) the fun of orbital mechanics: sometimes you can reach your destination sooner by just hanging around and waiting for a while. If you have dV to spare (which you apparently have) and want to go home in a hurry, then you can check for a high-speed transfer a few weeks (or months?) before the actual transfer window. But I recommend to plan the full transfer in that case: it is really annoying to get close to Kerbin just to figure out that you don't have the 2000 m/s dV needed for the plane change because you made an inefficient, high-speed transfer.

O.K. Thanks. I would only have needed the "4.sfs" or "5.sfs" files from that. The *.sfs files of KSP contain everything that is needed. And, yes, I can manage a zero-zero landing (i.e. come down really slow) but the craft does not have enough magic torque (aka reaction wheels) to keep it upright on the slopes of Duna. (As gentle as the slopes may be...)