Kesa

It is a stock thing. Only Pilot level influences it, but it's not a small influence then. For the small difference, that might be just a different unrelated trait of kerbals.

From the input you gave, it sounds like what you want to do is build a fully fonctionnal craft and soft crash it somewhere. For the crashing means : You can edit sve manually or through hyperedit to put your craft in orbit of the desired land body, to save some hassle quicksave to make several crash attempts Crash by making your vessel a bit short on fuel short on power (TWR) by starting a suicide burn too late For the crashing speed : 6 m/s is landing speed, even for part not designed to be landed on. Shipwreck would be something not designed to be landed whose only problem will for example be that it tipped over and can't safely or usefully use engines 6-14m/s is landing speed with usual landing legs. 14m/s can be a bit rough and some belly part may break accidentally. Minor damages on a craft supposed to land at 6 m/s, but enough to make it unusable. 14-50m/s is "safe" crashing speed, in that crewed part should mostly survive, although explosion may increase their impact velocity past their tolerance. A normal ship is teared in pieces. A dedicated lithobreaker may survive and even be still functional, but likely, though most of its part will be intact, especially crewed ones, some joints may be severed. 50-100m/s unsafe crashing speed, same as above but with less part surviving (sometimes none) and crew likely dying. It is possible to make dedicated lithobreaker with specific parts reliably surviving well past 100m/s, but not of the size of a starship. 50m/s is the standard tolerance for sturdy non structural parts, 70-80m/s for structural parts. Past that, some parts will necessarilly explode (on solid ground). There are some parts with higher resistance, but they don't provide as much cushion for the rest of the craft than an exploding part. 200-300m/s you have to be lucky for even a part to survive. Dedicated lithobreakers might still have a good amount of useless structural parts surviving. Don't know what it is, but there's a speed past which your entire ship goes from above the ground to below the ground in one frame. Nothing survives then. So for a dramatic landing of a starship, I would go for a speed a bit above 50 m/s, with some armor to make crew survive. Usual non lethal Kerbal crash, low speed low resistance, tend to generate a lot of different debris. Going for a high resitance high speed crash should result in something less like debris field and more like shipwreck. which bring the topic of what parts to use : (space) plane parts (mk2 and mk3) are very resistant structural panel are super resistant, can be used to make several protective plates around the vessel, or a single hull and put stuff inside. I would go for the hull option. It should greatly help holding the ship together big landing gears should make the vessel more believable and cushion some of the energy, in a random way. TL;DR : make a ship and crash it. If it looks too much like debris field and too little like shipwreck, armor the ship with structural panels and make it crash at higher speed (50 m/s)

Bear in mind that torque is proportional to the distance from the center to the place a thrust is applied. In other words, the core of your station is the worst possible place to put RCS thrusters. It is however, the best place to put reaction wheel, to limit the structural stress put on the station.

When you decouple/undock a port, its magnet goes off and so does its ability to dock, so that you can actually separate the vessels without instantly redocking. For whatevever reason, it seems to be the state one of your docking port was stuck in. Glad to see backing up and trying again did work (as it should). If it did not, switchwing out of physic range and back in should also reset magnets (backing up before doing so is not necessary but prevents vessel going through each other while physics' off). Turning SAS ON on the bigger ship (and OFF on the smallest) should make that dance quite short. Dance requires energy and may last long when SAS is off on both ships because magnets forces are conservative, so collision and friction are the only way to dissipate energy. Collision works great if you approach perfectly aligned, other wise you have to rely on the very low friction of the rims. By turning SAS on on one craft, you let it act as a pseudo ground with additional solid friction (turning SAS ON on both craft prevent them to align, as you might have guessed).

I'm curious as to how he died. Kerbonauts now have personal chute past some level. Was he too inexperience to have his chute? Was the plane too low for using one, or did he crash into an engine or burned to high speed or something? For a not so dramatic accident saving both pilot should be doable.

Career mode is very easy on any default difficulty setting (at least the difficulty does not come from the career aspect), as long as you allow flight reverting. As Lugge pointed out, it is a great way to be slowly introduced in the various part of the game. It can feel grindy however. Here are some advice if you ever decide to make a career run : You start without patched conics or manoeuver nodes. It leads to interesting challenges, but if you're not up for them, it can quickely turns into "grind until I unlock them", in which case, you should rather inrcease your starting funds (unless you like grinding), or decrease fund penality to reduce the grinding associated to facility upgrade as a whole. Difficulty settings can be adjusted in an ongoing game, including reward and penality if I am not mistaken. (unless you like grinding) Don't accept contracts just because they are proposed to you, or offer a big reward. Even on hard difficulty, game is generous enough so that you can do what you want to do and only choose the contracts that align with your plans (though contracts may give you interesting missions ideas). Most importantly, you can transform your career save into a sandbox save. I've not done it myself, but saves are easily readable and editable text files. It means you can switch to sandbox whenever you no longer enjoy career without losing progression (eg station assembled over several hours). You can duplicate saves as well. As for as community content, as other said every thing is welcome. The closest thing there exists to restrictions is if you want to participate to challenges. Restrictions are here for obvious reasons and different for each challenge, but in most cases, they are about building, navigating and piloting skills, and thus have no game mode restrictions (and are better participated in sandbox). In short, sandbox mode is pretty much the default mode used by the community, because it allows to do anythin (appart from being restricted).

I think neither the docking port nor the hacth work on a deflated air lock.

This guide is indeed misleading at some points when it speaks of Bob at missioin 1 and of not using SAS on mission 3. Only mission 4 and 6 really need a scientist, otherwise always use a pilot or a part with SAS ability. By default, the game assign a pilot (Jeb) to any manned craft, so that you got SAS, so I guess it's fair enough if he mentions special crew requirements only for mission 4 and 6. You cannot store two of the same experiment in the same part (here, 2 crew reports in the pod). That's why between two crew reports, you have to take out the experiment data out of the ship and back in, to transform the crew report into generic experiment data. Even as an experiment data you can't have two of the same crew report in the same pod. Once you understand that, you don't need to be told click for click what to do. In any case, you never lose from overwriting science you only need one of, such as crew reports. 6 should be enough. launchpad, flying over shore, high, orbit, flying over X, landed at X. I think he does the hotmeter at launchpad in mission 3 anyway.

Any part that can hold a kerbal and that hasn't a flag telling "no hatch" can be used for rescue mission. I think parts that you have unlocked or are about to unlock are more likely. If you are not asked to bring back the ship, the easiest way to rescue the kerbal is to have him exit the command pod and enter the rescue vessel. The only way I can see using the grabbing claw efficiently is to save hauling an extra pod on your way in, if you know the grabbed pod will be light (~1t). Since there's no way to tell the Pod will be light (unless you're not far advanced in the tech tree, but then, you may not even have unlocked the claw), I'd say it's a bad idea. If you are asked to recover the craft, I think 7t is an extremely safe upper bound to the mass of the vessel you'll have to prepare a rescue for in the stock game : The MK3 crew cabin weights 6.5t. the MK3 command pod and the processing lab are 3.5t, most other crewed part are under 2.5t. I would personally assume the craft is 3.5t and adjust if I encounter the normally usually rare Mk3 cabin. If the pod has no hatch, it's a bug from the mod the pod comes from, and you can save the crew with a claw, but you are not supposed to be forced to. It comes from modders not putting hatch on their part and not using the "no hatch" flag. As inelegant as I find it, there's a fix for it : And save editing for existing missions.

Indeed, but I did not use infinitesimal to establish (2), not explicitely at least. I used infinitesimal as the fastest and clearest way to explain how to get there, but I initially got there with reasoning like I also have to push M1 but half of M1 disappears midburn, then taking the area under a triangle, rather than using calculus to solve a differential equation. But when looking very carefully, one can't just assume that "the thrust is constant" after writting (4) and assuming the TWR hence the acceleration is constant. So M2 is actually a parabola rather than an affine function. And so on, M3 is a third order polynomial, and the area summed correspond exactly to the coefficient of an exponential. Yeah, it's more like why it cannot work, than why it does not work, and the approximation built is more of the kind (A0 + A1z)/(1 + B1z) A second order approximation of exponential is already really good though, if done somewhere useful rather than around 0 (eg at e, which I think is a typical ratio between stages), and gives an upper bound where a simple developpemet (1+z+z^2/2) gives a lower bound and vice versa. It is also possible to make it require as little computation (4 operations), if put in the form A + B/(C+z). All of that of course did not required the twisted path I took.

in : M1 = m.(DV/ve) M1is the mass needed to psuh the useful mass to the desired velocity. But that fuel is not burned all at onnce and has to be pushed along. If you had to pushe the mass of fuel M1 all along, you'd have to push it with a mass : M2 = M1.(DV/ve) But halfway through the burn, half of the mass M1 is gone, you don't need to push it all the way. So for short, we take the average betwee nothing to push and everything to push. What's hidden here is the area of a M1 by DV/ve triangle (while M1 is the area of a m by DV/ve rectangle). One possible rigourous way to establish (2.0) M2 = M1.(2DV/ve) is to rewritte M1 = m.(DV/ve) as : (4.0) M1 = m.(TWR.Dt/ISP) Where Dt is the length of the burn (for example using ve = g.ISP and DV = g.TWR.Dt but an independant direct proof is possible), which can be generalized considering infinitesimal burn : (4) dM1 = m.(TWR.dt/ISP)* Which means to push a mass m during a laspse of time dt, you'll need dM1 as expressed. To find (1) from (4), it suffices to sum over times varying from 0 to Dt = (ISP/TWR).(DV/ve), the duration of the burn. (4) still holds when it comes to the second fuel mass carrying the first one, except, M1 varies with time : (4') dM = m(t).(TWR.dt/ISP) , in particular : dM2 =M1(t).(TWR.dt/ISP) Now if we make the reasonable assumption f a constant thrust, M1(t) = M1(0)(1 - (t/Dt)) And summing for t in [0 ; 1] yield the factor 1/2 : M2 = (1/2).M1.(TWR.Dt/ISP) = (1/2).M1.(DV/ve) Which is (2.0). Still working under the reasonable assumption that the thrust is constant the formula immediately extends to the subsequent fuel masses needed to lift M2, M3 and so on, and we have (2) Mn+1 = (Mn/2).(DV/ve) It has more to do with playing math than with playing KSP. I see it as a cute little paradox, or as an elaborate (false and) deceptive proof that 1+1 = 0. As I write this I've realised where the error lies but won't give any clue, mostly out of tiredom after such a long post. *Note that this equation is straightforward if you understand the definition of ISP, which is surprising given ISP was invented to circumvent translation issues of exhaust veocity between unit systems rather than to be something understandable.

Pretty sure there is a flag to tell a part has no hatch that modders should be using in order to avoid this problem. Be sure to slip a word to them. In addition to the solution given by Streetwind, which deals with new contracts, you can edit the save file for existing ones, to replace their pods by, for example, the mk1 pod. Search for a Mk1 pod to copy and search for the stranded kerbal, or for USILS parts to replace them. I think you even get to see stranded kerbins you hve not rescued yet, and get to know their orbit (kind of). "low orbit around" is easy, "orbit around" should be assumed to be the hardest possible orbit to establish, although sometimes it's a very easy equatorial retrograde orbit. The penality for declining a contract (or accepting and cancelling it) is not very high by default, so that's an other option, but hard orbit are not really harder, they are mostly about bringing a bigger rocket.

For the efficient trajectory part, do you know about : Hohmann transfer Launch Window Oberth effect You need to know about all three of them. It's completely possible to brute force your way any where in the Kerbol system using nuclear engines, but knowing how to do it the efficient way will teach you a lot of things, along which : What is Delta V How to read maps (search for ksp maps) how to plan ahead and to know in advance what your vessels are capable of As for the craft goes, go bigger. But do it smart. If you just scale up things, it won't work. Go bigger means add more stages with good proportion. Some rules of thumb I use to make an efficient rocket : Minimize the playload mass. The size of each stage influence the previous one linearly. The difference between a 450 kg and a 900kg playload may not seem big compare to the mass of a rocket, but the 900kg playload will need twice as big of a launcher as the 450 kg playload. So don't bring anything you don't need. Mass ratio between two stages should around 2.5-3. Just to be clear, this is the total mass of the craft at the ignition of a stage divided by the mass when the stage is ditched. If mass ratio is to small, you are likely staging too often, which implies you carry to much mass in engines and decoupler. If mass ratio is too big, you are suffering the tyranny of the rocket equation (dimishing return of additional fuel in a stage) Adequate engines : adequate thrust : initial Thrust to Weight Ratio of about 1.4 -1.8 for ascending from a heavy body, acceleration of 4-15 m.s^-2 for space bound transfer burns. If thrust is too high, you are probably carrying too much engine mass. If thrust is too low, some manoeuver might be inefficient, or even impossible. Adequate engines (bis) : adequate ISP some engines are better in atmosphere, some are better in vacuum. Some engines are poor reguarding both thrust and ISP, they generally only offer increased manoeuvrability and should not be fired for extended period of time (eg RCS thruster)** When all that is done, fly your rocket. if it is short on fuel, add a stage, usually aninterplanetary one, and resize launcher accordingly. Other solution : do several launch and refuel missioins (needs you to know how to rendez vous and dock). *acceleration divided by gravity. For Kerbin,g = 9.81 ~10 m.s^-2. Acceleration is given in flight in the vessel info on the map view **technically, it's more efficient to use the stages with worse ISP first, but you should not be carrying enough of poor ISP engines/fuel in the first place. Still good to know if you are very tight for some reason that you should first empty your monopropellant tanks to maximize your chances. I guess your aiming directly at EvE. Don't. Even in order to land on an body without atmosphere, you want to decelerate as horizontally as possible, in the same fashion and for the same reason as for a gravity turn. When transferring from and interplanetary orbit, you can't expect to land in one aero brake. the first aero brake should be with a periapsis high enough so that your craft does not burn and low enough so that you get captured. If both condition can't be met at the same time, prefer the first and meet the second with a breaking burn at periapsis. Then several braking passes may be necessary to slo into a circular orbit. If your craft has fragile (low skin heat temperature resistance) components outside of a protective bay, be sure to have a heat shield strictly bigger than the craft.

Just in case you don't know yet, you can click on the navball speed indicator to toggle between referentials.

Right click on the part containing crew member Select the option "transfer crew" Select the Kerbal you want to move Left click on the target part you want to transfer to Important note : you need one (or more) unoccupied crew compartiment to use this method. Alternate method : Go on EVA with the Kerbal you want to move Reenter the craft by an other module If needed, you can have two Kerbals in EVA at once to rotate crew, thus note needing free compartiment. Important note : for this method, you need EVA unlocked, as well as cleared crew hatches in both crew compartiments. Some compartiment part like MK1 crew cabin has hatches that are usually obstrued. Some mods, like USI (one you seem using) have not given any thought about hatches, which are thus inexistant.

WARNING, Math ahead. So I was trying to find an intuitive way of approximating the reverse rocket equation by hand (without havinng to developp an exponential) : M = m.exp(DV/ve) And came up with that : (1) M1 = m.(DV/ve) As the mass of fuel required to propel the playload mass up by a desired DV, with an exhaust velocity of ve (conservation of momentum). (2) Mn+1 = (Mn/2).(DV/ve) As the mass of fuel required to carry the mass of fuel Mn while accelerating (by summing over a triangle, one can see you only need to propel up to Dv/2 on average). Edit : here is exactly where the above formula comes from : If DV < 2.ve, then the sum (Mn)n>=0with M0=m is convergent and easy to compute by hand. Its sum is : (3) M = m. (2ve + DV)/(2ve - DV) Which is not consistent with the correct reverse rocket equation. Close enough for small DeltaV : if you take r = M/m, and z = DV/ve, we find r(z) = (2+7)/(2-z) = 1 + z + z2/2 + z3/4 + o(z3) Instead of r(z) = exp(z) = 1 + z + z2/2 + z3/6 + o(z3) For r > e, (z > 1), at interstage mass ratio that are not unseen, the approximation gets significantly off (in a conservative way at least). https://prnt.sc/jnq406 But more importantly, I don't know why I don't end up getting the correct formula, altough I strongly suspect step (2) to be at fault, and I'd like to be enlighten.

I have not updated to 1.0.5, so I do not know what does these new contracts look like, but the former contracts that asked you to establish an orbit need you to wait ten seconds without touching controls ("staibilize during 10 seconds")

Radial batteries are masseless (at least the smallest one), so don't count! also, once you're no longer in LKO, there are not so much eclipses. Your probes may be really heavy, because for any minimalistic probe under 2000 m/s, I find that a lv 1 is better than a 48-7s. I almost certain that Ion engines perform better than 48-7s for interplanetary, mass wise (but maybe not cost wise). Try to make the Lightest possible probe with dV requirement for a trip to EEloo or Moho and capture, I think they will appear to be the engine to use.

I love all of them. Off set for part clipping Rotate when WASDEQ isn't enough re root when I choose the wrong pod / playload

A 6 hours Kerbal day is a stellar day : The first Sunrise occurs at 4h13, while the 209th (half a year later) occurs at 1h08.

I can land on the Mun from trans Lunar for slighty more than 900 m/s (Set Periapsis slighty above ground to brake horizontally). However I can't do a Mun and back mission with 2700 m/s in LKO, but rather with 3000 m/s. 300 m/s to return seems a bit short since LMO is 550 m/s (at least <600 m/s), and Mun escape is about 850 m/s. But It might be as low as 350 m/s.

If it's just for the contract, you should be able to single launch your outpost, or at least assemble it in LKO, and land it in one piece (great docking skill or docking port alignement indicator are usefull to align modules perfectly). If it's for the fun of having modular base, I can't make better than the two post above. G'dluck!

For my full stock game, I could just overpower my craft and go, but I feel like getting the better out of my craft, so lots of testing. Using Kerbal Konstruction Time, I can and have to test, but the cost for it is so low (at least for launching to LKO/LEO) considered to what it should be (engineering cost should be far more than construction of one prototype, and is ~ 1/100th), I voted "avoid the cost". I'm very new to RSS, so I really can't have a good launch at my first tries, so I do many tests with KCT. Sounding rockets are dirty cheap though, and I've crashed some of it, but their unmanned, so I don't bother.

does the fuel symetrically flows? I guess yes since you said this does not happen in space, but check it in space until the fuel tanks are empty. - - - Updated - - - in stock aero only wings and some (mk2) fuselage generate lift. If fuel flow is your issue, check the fuel flow rules to know how to balance fuel consumption, or use a fuel balancer mod. AFAIK, the rules in the link still apply (despite dating from 0.24.2)

Using Realism OverHaul, Thiner rockets produce less drag, but thiner tanks have a worse dry : wet ratio. Since the effect of drag is not easy to figure out, I'm searching for empirical tips about how thin a rocket should be. Is it a sensitive parameter, is it worth optimizing, or does a rocket twice fater or thinner than optimal will still perform well? I've seen video where Mechjeb displays drag losses, but I'm a bit confused with all the different windows Mechjeb proposes (I'm more used to KER), but I think I could use it to do some trials (compare difference in drag loss with difference in dV).