diomedea

Single pictures are easy, first upload yours on a online site (most used here imgur, but other work as well) then the site should provide the link to that pic, which you need to copy and paste in your post.

You certainly mean "the batteries are taking time to recharge". Panels provide EC for the batteries to store, but they don't when in shadow or not oriented towards Sun (so, best if they are mounted on the vessel in a position where they have no other parts obstructing light from Sun).

ASAP as in "As Soon As Possible" so don't delay and start doing

In reality L/D depends also on speed, but believe here is where KSP lacks accuracy. For a more accurate aerodynamic model, you may wish to use FAR. Factors like turbulent effects and detachment of the airflow with Reynolds (which affect lift too, not only drag) aren't adequately modelled in KSP, neither is Bernoulli's principle that plays a major role with real lifting surfaces.

Actually no, L/D isn't constant. Both change with angle of attack, but their dependency isn't the same. Lift is roughly proportional to sin(AoA), at least for small AoA; Drag goes with the cross-section presented to the airflow, it generally increase with AoA but is never zero, and its function on AoA is distinctively different for different shapes.

You can't be using stock propellers because the base game has none. What you may be using are propellers built out of stock parts. This is essential to understanding what follows, because some propellers have been modelled (as add-on parts) which work very differently, in particular they directly provide thrust as stock jet engines do based on altitude and speed, but don't show any torque nor lift/drag of the blades. Using stock lifting (or control) surfaces as propeller blades instead works based on lift. Now, please refer to lift here, as KSP since version 1.0 models aerodynamic effects based on such laws (Lift = 1/2 ρ v2 A Cl; Drag = 1/2 ρ v2 A Cd). Both coefficients Cl and Cd actually exhibit a complex behaviour, as they depend on shape and speed (in Mach or Reynolds number). Here a pic showing how Cd changes with Reynolds, therefore speed: KSP bases Cd and Cl on a similar curve. Of course both Cd and Cl are function of angle of attack, Cl in particular (roughly proportional to sin(AoA) up to a maximum). Another important factor with both lift and drag is "ρ", air density, that changes with altitude following a curve made to mimic the barometric formula. Therefore, the lower the altitude, the higher air density and both lift and drag. As you may have noted, lifting surfaces (both in reality and in KSP) can't provide lift without also having drag (and the two are always correlated). All blades of a propeller show drag, so also in KSP your propeller built from stock parts will show torque (opposite to the rotation of the propeller) that increases with rotation speed and angle of attack of the blades.

If your lander is on the equator and the return vessel has a 0° inclination, then you should simply launch (east, unless that return vessel is in a retrograde orbit therefore west) a bit before the return vessel overflies the landing position, and climb to its orbital altitude keeping the same 0° inclination. But if you're not, we have to wait for the orbit of the return vessel to be close to overfly the landing position and launch at the same inclination it has (because Mun rotates, slowly, it may take time for the orbit to move in relation to the landing position so to align). Once on an orbit coplanar with the return vessel, you can use normal rendez-vous procedure (hope you already practiced that, if not do with the training scenario before).

I like you named the launch a "shot". The math you asked for is the same used for computing ballistics, and easier done with artillery shots. In ballistics, we need to know (with the greater possible accuracy) the following: speed at launch, angle of the launch (elevation, generally taken from horizontal plane), drag factor. The latest is by far the most difficult, as it depends from air density (therefore, how density changes because of temperature and humidity) and speed. Also (though not required in stock KSP) wind effects needs be computed. If it wasn't for drag, ballistics would be real easy. Given the "shot" makes for a suborbital trajectory, its shape is elliptic (so, the trajectory is symmetric left or right of the major axis). Elliptic orbital math can be found here; in particular, equation 4.26 allows to compute Apoapsis from known values (speed, elevation, radius at launch) (solution to your first point). equation 4.28 provides true anomaly from periapsis to launch point, which makes it easy to compute true anomaly from Apoapsis to launch point (complement) and because the orbit is symmetric, doubling that gives the anomaly from launch to landing (of course, expressed as angle, but it's easy then to find the distance with the radius). For the direction of launch, you need to use 4.33, that puts in relation latitude, azimuth and inclination. Believe you need a add-on to automatically deploy chutes at a specific time, though KSP allows to have them deploy at a given altitude or pressure. KOS would be the add-on of choice to make such things. KSP provides some records for the current mission (hit F3 to see them), don't know if they cover all you wish.

@amoksepp: that thread you are using as a reference is outdated, tests were done with KSP 1.0 and lots of changes have been made to the game since then. In particular drag calculations. The value reported in that map for getting in a 80 km circular orbit from Kerbin (3400 m/s) is a good average of what required with KSP 1.2.x, as such a good indication for planning space missions. I'd say your tests actually confirm what that map shows. Still, actual DV required to get to orbit depends a lot from TWR and drag of the vessel used. If no drag existed (no atmosphere on Kerbin), getting to a 80 Km circular orbit would take ~ 2559 m/s DV (this value comes from comparing the total energy of a spacecraft while in orbit against its total energy while landed at sea level). Clearly, if we could build rockets so slim to present a minimal drag during the whole ascent, the total DV expenditure could approach that limit. You've also found the "turn altitude end" being a crucial factor to a lower DV expenditure, that confirms a pure gravity turn to be the best possible ascent profile (all thrust always goes to accelerate the vessel, instead of being spent to change its direction of travel).

@Grease1991: if you really want to be involved, best would be to contact the author of Kerbal Weather System (don't stop at the version currently in the OP, I helped him make one a lot more complete for KSP 1.1.3, it's a realistic simulation of weather running on the base of KSP, though without graphics effects and currently takes a good chunk of CPU cycles). Last I knew he was still looking for someone to help get weather right. But be prepared for a lot of work and having to learn an enormous amount about thermodynamics, fluid dynamics, chemistry, and many other fields. In the end I couldn't afford to keep spending every hour of every day on that, more so while having other more important personal issues.

Can't think that would be the best way to achieve a retrograde Sun orbit. Kerbin travels at ~ 9196 m/s around Sun (of course, prograde). You can of course setup a retrograde burn relative to Sun while still in Kerbin's SoI (need to burn so to increase Ap in the opposite direction of where Kerbin moves, meaning burn prograde in Kerbin's LKO when Sun rises above the horizon) but why waste 9196 m/s DV that way? (that would only be useful in case you want to dive into Sun, and even in that case would be better to save DV using a slingshot from Eve or other bodies). Going farther away from Sun however reduces orbital speed (Jool speed is on average ~ 4120 m/s) therefore is easier to set retrograde Sun orbit by first raising Ap. And then, intercepting a massive body as Jool at the correct angle (get a Pe in front and higher of Jool) provides a lot of DV to make that retrograde orbit.

That message "FMOD failed to initialize..." seems really the hint we need. Googling with that message I can see a number of similar issues reported (e.g. this or this, but please check others too). As I can't replicate the issue on my system, I'm unable to check if what suggested in there works or not; however you seem to have good enough knowledge with PC to be able to test yourself. Hope something works. (Note: Filename: Line: 1197 refers to something else than the output_log file, could be about a Unity file). As you could have noted, all googled pages refer to a Unity or FMOD bug (or, to how Audio service in Windows interfaces with Unity). That tells to me there isn't much to be done to fix it in KSP code. Also, Unity uses FMOD library but doesn't develop it, they also are probably waiting a fix (which may not be considered a priority, if other solutions to such issues work).

In the best of my knowledge, KSP does not care at all about how sound is going to be played. All it does have are settings about audio volume for different kind of game sounds, and for the "sound normalizer". All sounds are processed by the system (e.g., by DirectX in Windows) and other specialized software. Please check if you have other games showing the same issue (sound playing only from headphones), that would help finding where the issue really is. In case it only happens with KSP, I'd look if audio drivers are actually ok in the log files (please provide them as described here).

Oh, glad to learn the above . Pity such features aren't so well documented, it takes very good modders to unveil them.

AN stands for Ascending Node, DN for Descending Node. Both described here , anyway, AN is where your orbit crosses the plane of reference moving from down to up in that reference frame; DN is where the orbit crosses from up to down.

Best would be to revert to a previous save (look also at those files in the "Backup" subfolder with your game, may be they help). If you have none, be prepared to "cheat" the game. That ship may indeed encounter kerbin again, but could take years to have an encounter (not less than the synodic period with the orbits of the ship and kerbin around Sun) and then you have no fuel to change periapsis, you'll probably miss kerbin or hit it at astronomical speed. Planning a rescue in solar orbit is no small feat and could take a very long time too. If you want to consider cheating, you need to "put" a bit of fuel back into your vessel, then use the "infinite fuel" cheat from the debug console (Alt-F12). To put some fuel back you need to edit your savegame, find your vessel in it (look for a VESSEL with name = <nameofyourship>) and within your vessel find a tank (you can just look for a line with "name = liquidfuel" and another with "name = Oxidizer" if both are required). Change the lines with "amount = ..." to read the same quantity as in the following lines "maxAmount = ...". Repeat for more tanks. Please know that even with infinite fuel a return trip to Kerbin will take time and is better to plan it carefully.

As you wish!

Seems like you have different KSP folders, as if you installed different versions in each and you just launched KSP from an old one instead of the most current. But believe you know how to find other folders with KSP in them.

Seems like you need to ask assistance for your Steam client. Unfortunately I am not qualified to provide support about it. Without a working Steam client, it would be impossible to verify your KSP files, update or re-download them. But if your KSP install isn't damaged, it would still work without the Steam client (just find the KSP.exe or KSP_x64.exe in your SteamApps/common/Kerbal Space Program folder and launch it).

Please provide info as described here, that will allow to better diagnose your issue.

Hasn't to be 2 different commands, I have other ones set as toggles so the same key switches between states (though, you need a joystick that is set so to send the command just once - instead of repeating it - for that to work). Squad made two different commands for those modes so to allow more customization. Indeed, may seem alike "reverse programming", you find what the command is named by assigning to another function, then use the name with the function you wish. Believe it won't be difficult when you have the opportunity to try, however just ask in case you need better info.

It is true those settings aren't exposed in any of the tabs under Settings/Input (where I'd expect to find them). They correspond to the following within the settings.cfg file (in KSP root folder): - UIMODE_STAGING (default primary key = Insert; default secondary = None); - UIMODE_DOCKING (default primary key = Delete, default secondary = None). Now, you have to find how Unity names the command on the joystick you wish to use (could be something like "Joystick0Button5", where 0 and 5 are the ID of the device and the button, of course those will be different in your case). A good way to do so would be to assign that command to another function with an exposed setting (in the Settings window) and read its value (directly or opening the settings.cfg file afterwards). Then, you need to edit the value of the primary (or secondary) key in the section of the settings.cfg file corresponding to the mode, with the value for that Joystick command.

Fine, got what you meant now. Yes, 1.65^2 = 2.725 times the radius.

Allow me to correct the above a bit, could be I wasn't clear before, radius goes with the cubic root (not the square root) of volume. 1.65^3 = ~4.5. Can't tell about the patch; but certainly each asteroid when discovered has a size assigned (not exact mass, that is determined only after it enters the bubble if I'm right)

The 4.5 ratio from one class to the next applies to mass. Mass is tied to volume by density (so, assuming same density with all asteroid classes), volume scales by 4.5 as well. Assuming asteroids to be roughly spherical, volume V = 4/3 π r3, therefore radius r = 3√(3V/4/π); the difference in radius from one class to the next is ~= 1.65 (please note this works with average radius even with non spherical objects as the asteroids are).