diomedea

Heat is transferred through conduction, convection and radiation, both in reality and in KSP. Radiation occurs from any hot body, the transferred heat Q proportional to Stefan-Boltzmann constant, the emissivity of the material, the area of radiative surface, and the temperature at the fourth power. Convection is when a part is immersed in a fluid (like atmosphere), the transferred heat Q proportional to the heat transfer coefficient of the material, the surface, and the temperature difference with the fluid. Conduction occurs by contact with other parts at different temperature. Radiators work by having a large surface and high emissivity (and also by pumping heat so they're always very hot), but still may not be enough to control heat build-up if conduction/convection is high. Now, please have a look at the AeroGUI panel with the pic here (http://imgur.com/ktMhQct), taken just below kerbin's atmosphere limit. Due to the high speed of the vessel, there's a serious difference from the static ambient temperature at that altitude (212.32°K) and the measured external temperature (5968.07°K). Thanks to the very low density of air at that altitude, convective flux isn't too high (5.48 kW with the cockpit) or the vessel would easily burn; but still you should notice it's a positive flux (while instead, radiative flux is negative, a net loss of heat; but at the same time, conductive flux from adjacent parts is very high). Just above the atmosphere limit, in KSP the air density is made = 0 and therefore the external temperature drops suddenly at the temperature of void (4°K). So you have that marked difference by being just above or below the atmosphere limit. KSP thermal mechanics work, at least just as designed. As anybody else, you may need to build and launch vessels considering the above, so fitting enough of radiators and heat shields, but also avoiding to stay too long at very high speed in atmosphere.

We've had asymmetric aerodynamic forces, wheels, reversed control surfaces, choking engines starved of air. Most often, seen planes veer suddenly to the left for no apparent reason; however there's always some hidden cause. Unless your plane has some asymmetry (like not centered wheels, or wheels with some camber), finding the cause may require some effort. I'd start with having aero forces displayed (F12), and keeping all of engines and wheels action menus displayed at the same time while taking off (keep Alt down while right-clicking each part). If all goes well, you may capture a shot (F1) of the moment anything weird starts to show and some asymmetry should show with the parts data (then, of course, please show that shot here). If nothing, have an exorcist ban the kraken.

Something you're not going to catch unless you start listening. Here are a few lines to compute drag in KSP (not from KSP itself, that wouldn't be allowed, but a tool doing the same). Now tell me if that's helping more than providing the rationale of how those work. Computing drag is a very complex thing, both in reality and KSP. The tool I showed a bit about, strictly interfaces with KSP itself to receive data about each part of a vessel, the air density, the speed vector, and else. All things you will need to compute yourself first, and the only way is to understand how KSP does. The whole procedure is far too complex to give in a post. I can only hope you may work through it a bit at a time. And however your stance is disheartening.

Ok, let's go a bit deeper about Cd. Size of parts has no meaning with Cd (it affects A, the cross-sectional area, and that is computed out of the dragcube for each part, known the aspect of the part against the flow direction). Cd instead is computed out of curves ("lerping" values where curves are described as collection of points in Unity). Look at the physics.cfg in the KSP root folder, you'll find those curves (e.g. DRAG_TIP, DRAG_SURFACE, DRAG_TAIL), those are for the direction the part presents to the flow, at different mach speed (first value with each point is mach speed, then is the drag coefficient, then the in and out tangents of the curve).

@Lynch: can see a few simplifications in your model, let me try to tell a bit (I'm also developing something similar, though with different purpose). Any flying body is affected by 4 forces: - Thrust (always directed in the engine's gimbal direction, therefore not always aligned with the vessel longitudinal axis), it's scalar being ISP*g*dMf/dT. ISP changes with atmospheric pressure, therefore altitude; g is the value of gravity at that altitude (also changing), dMf is the amount of fuel burned in dT time (that depends on the throttle setting and engine specification). - Weight (always directed towards the mainbody center) is variable with altitude, W = m * g where g = GM / (R+h)^2 (g = gravity, G = gravitational constant, M = mass of mainbody, R = radius of mainbody, h = altitude); m is the vessel mass that is also variable (at least because of dMf/dT, the fuel burned). - Drag is a vector always opposite the direction of travel (therefore, retrograde). Fd = 1/2 * v^2 * ρ * Cd * A, v being the vessel instantaneous speed, ρ the air density (changes with atmosphere pressure and temperature, both change with altitude, temperature also with Sun position and latitude), A the cross-sectional area of the vessel (so, if the vessel isn't aligned with the prograde vector, A increases), Cd is the drag coefficient that depends mainly from shape and speed v (against the mach speed, that also changes with air density). Computing Cd is actually the main issue here, KSP has different coefficients for speed with nose, surface or tail relative direction of each part, and A is computed for each part given direction of travel and occlusion from other parts. - Lift, a vector going perpendicular to the direction of travel, Fl = 1/2 * ρ * v^2 * Cl * A (quite similar to drag, isn't it?), where Cl (lift coefficient) depends sharply from angle of attack (AoA), that is the angular difference of the longitudinal axis from prograde direction. Sorry it the above appears intimidating. It's rocket science actually....

Those legs crash tolerance is 12 m/s. Even breaking, those won't reduce speed enough for the LV-909 or the T200 tanks with that lower stage (crash tolerance at 7 and 6 m/s respectively). Parts above those tanks should survive, but then there's the danger with the vessel capsizing with no chutes to stop it, what could probably destroy parts in the top stage too.

You ship is too heavy, and that's certainly a problem if you want to land on those legs. But it's too heavy for the chutes you used, not for reentry. I built an exact replica (from the pic you uploaded), had it in a circular orbit at 88.5 Km from Kerbin. It is even heavier because I let all fuel with those tanks (while the pic shows your being at half fuel). Then performed the reentry this way: - burned retrograde to aim at KSC, periapsis 50Km (yes, that high); - turned attitude to normal (yes, it seems contrary to experience, however works). Reason it works, it exposes more on the ship surface to drag, so depleting more kinetic energy (lowers the ballistic coefficient). - kept the ship rolling to distribute the heat on all sides. - turned attitude to retrograde when components on the ship sides started to raise temperature too high (that was at 50 Km altitude, speed was decreasing but still about 2300 m/s). - started burning retrograde at full throttle when lower than 40 Km (probably unnneded to decrease speed, but intent was to land without fuel). - opened those drogue chutes when turned white, and then the Mk16 chute (had to modify the staging to have that sequence). Even with all chutes opened, and the engine at full throttle, final speed still was 16 m/s. Too heavy and the LV-909 has too little thrust at low altitude, so had to fire the decoupler and sacrifice the lower stage. Hope you have nothing to save from that stage. - Landed successfully with the top stage. http://imgur.com/bwbXLiH

Nice explanation about how thumbsticks work. But you're assuming untrue things about my HOTAS. It has 3 programmable hats, each can be independently set to act as 8-way or 4-way POV controller or as a set of 4 or 8 buttons (D-pad). Unity only recognizes raw key output (single key presses), nothing alike a POV controller, that's why I wrote of such limitations above: I have to program those programmable hats in my profile as sets of different buttons and assign each button to one key defined in the KSP Input settings. Apart those, it has one other programmable hat (called "mouse controller" because when not programmed to something else, it acts as a mouse replica). That's your "thumbstick". Of course when used as a couple of axes, it is mapped by Unity and usable in KSP. Or it can be programmed as a additional set of buttons. Also, it has a programmable "scroll wheel", which also isn't recognized by Unity (but keys programmed to the scroll directions are) and other 2 scroll controls (generally used to control HOTAS functions, require external programming to interface with the application and use with the LCD display to show real time game data). Of course, Unity can't control those, and neither natively the multi-state LED lights with this HOTAS, as it has no interface with the library of HOTAS functions. But I'm confident some KSP modding could extend control to those lights. Another feature with my HOTAS, not recognized by Unity, is mode selection. That allows to use up to 6 different profile pages, to match each of the HOTAS controls to different commands, that comes good in different phases of a flight. All included, 9 axes and 39 buttons (when all hats and wheels are mapped as buttons), 11 programmable state lights, LCD display, a feel and durability only matched by more expensive devices (and not all). But let's stay on the subject of how HOTAS and KSP work together, instead of discussing the relative merits of each brand and model.

Mhh, have half an idea your issue could be related to thermal part highlighting, as part highlighting is a feature giving issues in recent KSP versions, though never to the point of causing a shut down. You may try if that's true by choosing to not have thermal highlighting (pause menu, settings, gameplay section). Try also to not have thermal debug colors enabled (F11), or via the console (Mod-F12) in Thermal panel. Can't think there are issues with your hardware given the performance data you gave. If nothing helps of the above, mind uploading your vessel to allow others to check?

Making a past history of Kerbin and Kerbalkind based on what is in KSP is certainly doable, though can't see it as a game development. Maybe something to be done in KSP Fan Works? Sure I wouldn't see anything of a "story" we have to play within KSP, e.g. redoing space missions in exactly one way because "history has them that way". Being free to experiment and decide is one of the great things about the game and better kept that way.

OK, of those config files, the adapter and the tank "large.cfg" perfectly match what expected, in particular their nodes descriptions (with each node, a triplet for position on X,Y,Z axes in relation to the part center and a triplet for orientation, then node type; part center actually comes from the part mesh). Also the config "part.cfg" for the tank matches, but you shouldn't have that "Size3LargeTank" subfolder within FuelTank, it probably is an obsolete folder that wasn't deleted when you upgraded KSP. Having two different config with the same name for the part, creates a conflict. Still can't see why it would result in the nodes (for that tank) behaving that way, however please delete that "Size3LargeTank" subfolder and check if that solves the issue.

Eh, very good question. I use a PC and a Saitek, not a Thrustmaster, therefore can provide no experience. Googled a bit around, but could not find one single site telling for sure.

So ? Are you implying my HOTAS hats should work like your stick does? I'm absolutely sure they don't. I've told there are no problems with axes, Unity recognizes all of them, that seems consistent with what you said. On the other hand, MS Precision 2 has just 8 buttons and a 8-way hat, doesn't it? That means Unity has no trouble to recognize all 16 the buttons, be it in KSP or Sky Rogue. But Unity can't recognize anything beyond button #19, something you won't be able to notice with your stick.

Hmm, still considering possibilities: not that your game is named in a way to include special characters (anything but a english keyb letter or digit) ? We have quite some story with special characters causing trouble in various places where save/load functions are managed through Unity. Note that just having one single game named in such a way, the whole list of games could be messed.

The very first time I landed on Mun, happened to be very close to one of those arches. I was a real noob with KSP at the time, knew nothing about them or other peculiar places, not to mention Easter Eggs. Left the place, but didn't care to put coordinates down. Few days later I learned what it was, sent a few missions to try and land again in the same place but didn't succeed. Took me to gain a lot more experience and dedication with the game to find those things again.

Is your issue about resuming a saved game (from the Start screen) or loading a save (F9 or Load Save... from the Paused Game window) ? As from your description, seems you are about the Load Save... that applies only to sfs files with the current save folder, however you checked against different saves in the KSP folder. If about resuming a saved game, can you tell how you start KSP ? By using Steam browser, clicking the KSP icon created by Steam (actually a link to steam://rungameid/....), using KSP launcher, or opening KSP.exe? Changing the way you start KSP would solve the issue? Is there any possibility of a mismatch, as if you had a different KSP folder than the one (with Steam) where your saves are stored, and actually running KSP from that other folder?

Indeed joysticks (and other controllers) are compatible with KSP, at least for what Unity is able to recognize as valid input. E.g. I use a Saitek X52Pro, all its 7 axis are recognized and all the buttons mapped from 0 to 19. However Unity knows nothing about buttons ID greater than 19, and clearly knows nothing about the multiple-action controls (Hat, POV 1 and 2) or the different modes. To make full use of all those controls typical of a HOTAS, I had therefore to make a profile with the joystick to match those extra buttons to keys recognized in KSP.

@Goldenseek: from the pic you linked, can't see a reason why those two parts shouldn't connect. I'd first of all try with just those two parts (make a brand new vessel, get the ADTP-2-3 as root part and slam that Kerbodyne tank on it). I have them working just fine (KSP 1.2.1), and expect you'll see them working as well. If they don't connect, I suspect one of the two has a messed config file (for the Kerbodyne tank, /GameData/Squad/Parts/FuelTank/Size3Tanks/large.cfg; for the ADTP-2-3, /GameData/Squad/Partss/Structural/Size3To2Adapter/part.cfg), with the relevant node position altered or outright missing; would then be nice if you could show those config files content. If the two connect, try connecting the parts above (the TR-XL separator, the engine above it and so on). You can always change the root part with the re-root tool in the editor and save as a subassembly, that can be attached to the vessel you were building. Let us know if and where you still find parts not connecting doing so.

Not owning a device alike your USB audio interface, checking what causes the issue and giving correct advice is close to impossible. So, take what I'm writing with caution. Your audio interface is indeed a sophisticated device, to perform better it uses software alike all modern digital musical instruments (a DAW, e.g. Ableton). That means the audio files are processed through the DAW, of course that is resident in memory. The DAW requires the audio file to be sent to it at the same time it would be played (through DirectX) from your PC native audio interface (then, to your headset that I understand is directly connected to the PC, instead of through the Focusrite). During initial loading, KSP (as well as any software) loads a wealth of data from disk (the OS takes care to load all needed from disk to memory and reserves that memory to KSP). Memory isn't only RAM, it includes the swap file that is written to disk. When RAM isn't enough to hold all, those pages in memory that weren't accessed recently are swapped to disk. Of course, having multiple programs open at the same, means they all "fight" for available RAM. Given your system has 8 GB RAM, and KSP 1.2 unmodded alone loads in 1.8 GB, is quite possible your OS is finding a shortage of RAM and then needs to swap memory. Just when the DAW should be playing those audio files, is quite possible those files (and possibly even some of the DAW software itself) have to be swapped back to RAM to be accessible. In fewer words, it all is due to the bottleneck of the system in passing data from disk to RAM. Clearly, there is no error to be reported about the time taken to move data, no wonder you'll find none with system and KSP logs; but you may find some programs able to show how memory is used and the amount of data moved by your system in real time, those would help diagnose the issue. Can't really tell about the VAB, sure if the vessel you were building was complex, would require more RAM, and that alone would push other things to the swap file. Quite possible the audio parts among them. But you told it takes few parts to have that effect, so something else could be the cause. Of course, more RAM could solve the issue if swapping memory is really the cause; a SSD to host the swap file would also help greatly. But I'd not commit to buy components before having confirmed that is really the issue.

Specifically about the bug with 6DOF key assignments (issue #13208), if wanting to edit those assignments manually, find the sections named "TOGGLE_SPACENAV_FLIGHT_CONTROL" and "TOGGLE_SPACENAV_ROLL_LOCK" in the settings.cfg. Primary and secondary lines with those sections hold the current key assignment and can be changed to any valid key Unity recognizes.

@p1t1o: and you are right! Didn't test in KSP (though you're welcome to do if you like), but computed the maneuver. Sorry if math below is less than clear. Vpe = SQRT(G*M*(2/Rpe - 1/SMA)) gives the speed to have at periapsis (known gravitational constant G and mainbody mass M, orbit height at periapsis Rpe and orbit semimajor axis SMA), this allows to know how much Delta V to put in the first burn to have the apoapsis raise to Rap = 2*SMA - Rpe. Then, speed at apoapsis Vap = SQRT(G*M*(2/Rap - 1/SMA)). That is exactly the amount we have to deplete with the second burn. E.g. in KSP: Kerbin's orbit SMA=Ap=Pe is 1.35998E10, Sun mass = 1.75655E28, so Kerbin moves at 9.284 Km/s (that would be the same speed of an ICBM launched from Kerbin with just the escape velocity to enter a Sun orbit). Then the ICBM burns prograde in Sun orbit, to raise the aphelion (Rap) to, say, 3.35998E10 (2E10 meters higher): new Vpe = 11.078 Km/s (so, Delta V = 1794 m/s). At the aphelion the speed Vap = 4.484 Km/s that is the amount to deplete. Therefore the total Delta V required with the maneuver you suggested is 1794 + 4484 = 6278 m/s that is well lower than the 9284 m/s speed in the original circular orbit. Anyway, I'd still go with some gravity assist (e.g., a multiple pass by Eve, Moho, Eve to keep reducing orbital energy until needed; if done right won't cost more than doing the initial Eve intercept, that's lower than the bi-elliptic burns).

@p1t1o: well, I'm not about to rule out definitely what you suggested, I saw similar ideas in the past and I'm sure those work in some cases. But while achieving a higher Ap definitely helps with other maneuvers, I'm not so sure it does for just lowering Pe when starting from a an almost perfectly circular orbit. May have to compute how it goes, my initial feeling is the energy added for raising Ap just balances out with the (less) energy required for then lowering Pe.

@p1t1o: bi-elliptic transfers work great if the result you want is to attain a specific orbit (so, matching Ap and Pe with what desired, one first aims to meet the Ap and therefore enters one specific elliptic orbit, than when at the Ap burns to meet the Pe, resulting in a different elliptic orbit). For hitting the Sun, what is required is to decrease Pe to a value lower than the Sun radius, no need at all to change the Ap. Earth's orbit around Sun is slightly elliptic, so a very small change in orbital speed exists; to make that maneuver, would be better to be at the Aphelion (so our speed is already lower, and will require less to drop it for lowering the Pe).

oh, what you ask is quite easy: it is the escape velocity from Earth's gravity well, which is 11.2 Km/s at its surface. Of course you need more than 11.2 Km/s Delta-V to compensate for atmospheric drag during the ascent (can't give sound numbers here, depends on TWR and aerodynamics of the rocket). Really, to hit the Sun then would be needed to drop all the orbital speed the rocket still has by being co-orbital with Earth, that is about 30 Km/s on average. Possibly by using other bodies to craft a few gravity assists instead of using fuel.

If what I wrote before wasn't clear, my fault, sorry. The tutorial section is sure very appreciated (number of views and likes are a good measure), having more is welcome. But to make more is left to the community.