diomedea

Not really... or anything colliding with a building would make them go boom. Each building has a set amount of damage it can withstand, KSP computes damage based on a number of factors, including mass and speed of the object and time it takes to cause damage to the building. But sure fairing shells shouldn't do.

The Dev builds for MechJeb work with 1.2.x. If you wish however only info, consider KER or VOID, both updated for 1.2.x as well. Probably other add-ons also fit your needs for specific set of data.

Wonderful work. Looking forward for the opportunity to buy you a beer .

@cartman: not sure how many in the community have multiple joysticks to test how KSP works with them all. I have one (and a bunch of other input devices) and know of noone else having more among KSP testers. You may be the first to have found that issue; but to let KSP developers know more and possibly find a fix, would be better if you could fill a report on the public tracker (http://bugs.kerbalspaceprogram.com/projects/ksp/issues). Please include the whole of settings.cfg and output_log.txt with the report.

Well, to me, good choice to not have started another thread. This one is still relevant. Beyond that, concur about DMP. Lot of fun, truly. In the end, wasn't DMP that good already, would be a lot easier for Squad to create something better in stock. Other features have priority for some reason...

Sure you know you're not going to get any lift from wings with your Spaceplane, because no atmo. So, the landing procedure is going to be a lot similar to what a lander would do, hope the spaceplane can make it. In short, you burn retrograde all the time, first to lower your periapsis, then to kill most of your speed, in the end to achieve the suicide burn that will stop the vessel exactly at soil altitude. Only problem, if your main engine is at the back of the vessel (normal with spaceplanes), your vessel has to be able to stand on its rear. If only you had RCS, you may control attitude in final, to have the spaceplane land horizontal. Your seems one of those very kerbal cases, when a player discovers at the worst moment the vessel they built isn't fit for the mission. Good luck....

You are indeed correct there are interferences; and true, the issue isn't limited to solar conjunction either. Any body able to radiate energy actually is a source of noise, just because thermal energy follows Wien's law and the radiated energy spectrum encompasses the bandwidth used for communications. And the max rate for data follows Shannon/Hartley, where Signal to Noise ratio is central. Also, even while highly directive, real antennae used for deep-space communications can't filter out all of the background interference coming from outside the main lobe, a real antenna gain has some nulls but hard to make all sources of noise fall in them. It is definitely possible to correctly simulate noise coming from Sun in KSP, and even noise from other warm bodies though a bit more complex.

In stock you can get a similar behaviour of a variable incidence wing using a large control surface part, setting it to inactive for pitch, roll and yaw control, and setting a limited authority when it deploys. Then, have one custom action control its deployment, so it changes inclination as you like. Tested with a medium-sized SSTO with FAT-455 Tail Fins as main wings, worked perfectly. Theoretically any of the stock wings can be modified in a variable incidence wing (so, would work with larger planes). But while changing a wing config to include a moduleControlSurface as appropriate (instead of the moduleLiftingSurface those parts have) is pretty easy (and the wing still works, tested), to have it really work requires to compute the dragcubes for its deployed states, and add them to its cubes definitions in PartsDatabase.cfg. Believe some routine with modelling programs allow to easily determine a cube values, but those are beyond my current knowledge.

If you're playing stock (unmodded), you don't really need a heat shield for a reentry from LKO. But your vessel shape and Center of Mass (CoM) could help or hinder. If your vessel is thin and long, pointing it retrograde (as understand from the engine overheating first) or prograde would create little drag against the weight of the ship, so it doesn't decelerate fast enough (it would show a very high Ballistic Coefficient BC from the AeroGUI panel). Better to point it normal: the sides, even if not able to stand very high temperatures, can create enough drag and slow the vessel fast enough, so dynamic air pressure wouldn't mount so sharply (that will diminish both drag/lift and heat from attrition) and the final speed would be slow enough to let open the chutes. The above, unless the Center of Pressure (CoP) is too distant from the CoM, because then the vessel will keep orienting with the CoM prograde of the CoP (we have no means to see the CoP in KSP, but it is generally close to the Center of Lift). In that case, once the dynamic pressure mounts enough, the rotation caused by pressure on the CoP would become too high to be kept in check by any of the attitude control systems aboard. Then, if you have means to reduce the mass of the vessel (staging the engine?) could move the CoM and reduce that rotational force, or even lower the total mass to let drag from the bottom be enough to slow to chute opening speed. Better advice could be given if you showed your vessel (or upload the craft file).

Could be best to have a proof of purchase to show, if you have no data about your account. Anyway, bettter to mail support@kerbalspaceprogram.com explaining the issue.

Somebody already hinted at the regularity transfer windows occur. That's because the relative position of two bodies (same phase angle from the common mainbody, like Sun) repeats at regular time intervals. The interval between any two such positions is the synodic period. There's a very simple equation giving synodic known the sidereal (orbital) period of the two bodies (below, S = synodic period; A = sidereal period of the inner body (lower orbital SMA); B = sidereal period of the outer body (higher orbital SMA) ): 1/S = 1/A - 1/B Therefore, once known the time T0 when the first window comes for any couple of bodies, all subsequent windows for those same bodies will be at T1 = T0 + S; T2 = T0 + 2*S and so on. Scheduling all such events for any couple of bodies within a system then becomes almost trivial. BTW, this wouldn't be complete without a way to compute the phase angle, as it determines when T0 is (though using the earliest window provided by AlexMoon's Launch Window Planner would be simplest). Best one was provided in this old thread, implemented with this online tool.

Believe your is an interesting report, could probably win the attention of the devs. Would be great if you filled it with the public bugtracker (http://bugs.kerbalspaceprogram.com/projects/ksp/issues) as that's the place where most probably issues will be looked by devs.

@MusicMetalHead: if you had a part showing multiple times both in the tech tree and the editor, I would sure point at multiple config files for the same part being loaded. Don't really know if multiple parts only show in the tech tree. It would mightly help to see what KSP does during initial load, when opening the tech tree and the editor for those parts; but we need to read a log file (output_log.txt or player.log depending on your OS, more info here). Best also to provide all the other info as suggested in that linked thread. Of course, as you posted in the unmodded section, I start from the idea you are running KSP unmodded; however should you have any modifications let us know.

Hey hey, who knew I was around? @Niemand303, are you too?

Best advice could be given knowing more about that contract and the actual orbit of your probes. Your savegame (by default, the file in /saves/<yourgamename>/persistent.sfs) has all the info needed to check this issue, would be great if you could upload and link it. One of the most common errors with achieving specific orbits is their inclination. Some required orbits are retrograde (inclination ~ 180°), often the direction of flight on the orbit isn't noted and players fail the contract though it appears in map mode the achieved orbit perfectly overlaps the required one (but, going in the opposite direction!).

Yes, there's an issue currently, is already being dealt with by Squad staff, though may require intervention from the company hosting our servers. Sorry for the wait.

Nodes always exist for an elliptic orbit (eccentricity < 1). But going from Mun to Minmus involves a conic in Mun SoI, one in Kerbin's SoI, one in Minmus' SoI. Of course you're escaping Mun's SoI (and entering Minmus' at the end), those conics have eccentricity > 1 (are hyperbolic trajectories, open). Nodes exist where the planes of the two orbits intersect, but that may be beyond infinite distance with open trajectories (imaginary solution if nodes are computed with complex numbers) or below surface of the mainbody (therefore not shown). Or simply, could have occurred after the switch to another conic (so, after leaving Mun's SoI) and therefore aren't shown.

Change the forward landing gear to a steerable part (the larger steerable being the LY-35 medium gear). With all fixed gear (LY-99 as you're using), yaw is only controlled by the rudder, but it loses effectiveness at slow airspeed like 60 m/s Of course you'll need to adjust the vertical displacement of all gear to have the plane not pitching downward while taking off. Also, be gentle with that steerable gear when landing, touch down with the main gear (aft) first and rotate slowly to make ground contact with the forward gear.

Interface isn't much different from what normal users see. We have a few options with all normal users posts (where you find the quote button) and threads, can find some more info about users (mostly from their profile, something by simply mousing over their avatar) and with the same menu where account settings are, can access the moderator control panel, good to see all the reported things and queued posts nicely listed, plus a few other useful things. Plus, we have access to some hidden forum areas and can have notifications enabled about a number of "events", e.g. when something gets reported. But there's nothing strikingly different in the way IPS software works. Only after some new KSP release....

I watched this vid live, was already grown enough to get most of the technical details about the mission.

Please know RT 1.8.1 also broke stock CommNet functionality, so you may wish to check it gets fixed as well. All was working right in RT 1.8.0, but with 1.8.1 need to have RT active to control probes; CommNet always shows lack of control whatever the settings in RT 1.8.1 start options.

I know of no mechanic in KSP for radiation flux to be intercepted by other parts or a body surface. In real world that is certainly true, the solid angle another object has in relation to a radiator (so, figure a sphere centered on the radiator, with the other object projected on the sphere surface) would define the relative amount of radiation captured. It shows you have good knowledge about thermal phenomena. However let me one consideration from what you wrote. Radiators in KSP work by irradiating energy, in a similar way to how radiators work on a space vessel. Radiators we commonly know on Earth also irradiate a bit, but mainly work by convection. When a radiator is at the same temperature of the air around it, convection ceases to work (and that perfectly matches what you wrote). Instead, radiation works with temperature at the fourth power (and surface of radiator, and Stefan-Boltzmann constant) and emissivity of the material. Because of difference in emissivity, is common to have a radiator at a lower temperature (but with emissivity = 1, as a black body) losing heat to another facing object with low emissivity (e.g. silver, emissivity = 0.02). Some devices in real world use this phenomenon to actually pull heat from one warm surface to another at even higher temperature. Heat pulling is simulated with TCS in KSP.

@Magzimum: those numbers are still correct; also other values in the config for those parts are the same. There is no intended difference due to the presence of atmosphere on the efficiency of those parts. The different sizes should allow for different vessel designs. Of course I would never keep a TCS open while moving in atmosphere (those have the windResistance stated at 2.5 in their config, the part will break with enough dynamic pressure), so have to thank the OP for running that experiment. However, in the design considerations, the orientation of the radiating panels has to be included. Panels radiate heat outside, but also are very efficient at catching heat should they face a heat source (also in real world). As the TCS designs all have rotating panels (that will always face away from Sun), their efficiency will generally be higher than fixed radiators (unless the case radiators are kept facing away by keeping a vessel direction, or having them in shadow).

Really old, not worth bumping. Locked until author wishes to revive it.

@Jarin: yes, quite close to how KSP treats SOI, does with atmospheres too. Real-world accuracy was sacrificed to have a simplified model, much easier to compute (and to play with). Please enable the visibility of thermal data with parts action menus (Mod-F12 to open the console, then Physics tab, then Thermal, then "Display Thermal Data in Action Menus", that will show at the bottom of the parts action menus (opened right-clicking on parts) data as the radiation, conduction and convection fluxes. 1. Radiators actually work, even when the net thermal flux is positive. For parts connected with radiators, conduction flux should be negative anytime the radiators pull more heat from the part, than the heat that part is receiving from others. For radiators themselves, the radiative flux would show how much they are radiating outside. 2. Mining actually creates a build-up of heat from the drills and converters. You have need of radiators actively pulling heat from those parts. Please know there's a sweet-spot of a specific temperature with converters, when their efficiency is the highest, so you only need to deplete heat as needed to not go beyond that temperature. Hope the above is enough help, but please ask if you need more, if not me others will answer.