soulsource

I just tried it with a newly built rocket, and it seems to be working fine for me...

I've been flying on Duna a loooong time ago. One rocket powered plane. Here's the Imgur Album.

<insert long rant about Twitch being utterly useless crapware, bordering malware> Probably the mod isn't properly set up on Twitch. I guess you'll need to manually install it. First download TAC Life Support from SpaceDock. The ZIP contains a GameData folder. Make sure to put the files in the ZIP file's GameData folder into KSP's GameData folder. Except for ModuleManager. TAC contains an outdated version of it. Grab the latest ModuleManager (4.1.4 as of now) from the forum thread: Put that ModuleManager.dll into your KSP install dir's GameData folder. In the end your GameData folder should have the "ModuleManager.4.1.4.dll" file, and the folders from TAC: "CommunityCategoryKit", "CommunityResourcePack", "REPOSoftTech", "ThunderAerospace" (along with the folders of other mods, and the game's original data folders "Squad" and "SquadExpansion".) Edit: It might also be a good idea to only have one version of ModuleManager in your GameData folder. That was a requirement some time ago, no idea if it nowadays works if multiple versions are installed. In any case, I'd delete all outdated ModuleManager versions.

A bit late, but: Windows has a video recorder built in. Not much in terms of editing, but simple record/stop functionality is there. Can be accessed by using the key combination "Windows"+"g".

Yes, but I'm not very active there.

I agree with everything you say, and my answer was really for the very specific case that Steam is already installed and running, along with the Steam Runtime. To be honest, I had already typed the question why one would even want to play games on Kali, but then decided against posting it because I didn't want to start that discussion yet again... Had it too often already...

I'm not a Kali user, so I cannot tell with certainty if it's going to run. However, if you already have Steam installed, and did not disable the Steam Runtime, I do not see a reason why KSP shouldn't work... The Steam Runtime is basically a minimalist Linux distribution replacing most of your own distribution's shared libraries for Steam games... Also, KSP is using Unity, and the Unity Player executable is mostly statically linked, making it rather distribution-agnostic. (Btw: I'm playing the KSP Store version on Gentoo Linux, and it's running perfectly fine.)

The launcher has never worked for me either. I think it's best to just pretend the launcher doesn't exist. To get the latest version of the game, assuming you bought it on the KSP store: Just log in with your store account (there's an "Account" button on the top right of the KSP website). The store will then show your purchases, and have a big blue "Download" button for KSP, that will bring you to downloads for the latest version.

The game seems to have issues with initializing your GPU. The first two things that come to my mind are first to update the graphics drivers to the latest version, and if that doesn't help, to try to run the game using OpenGL 4.5, OpenGL 4.3, or Vulkan ("-force-glcore", "-force-glcore43" or "-force-vulkan" command line parameters).

Unless your whole script is meant to be run in a loop, you might want to use the WAIT UNTIL ALT:RADAR < burnAlt instruction to just delay further script execution until you're certain to be below the threshold altitude.

You're probably talking about GoSlash27. I just wanted to mention them too. Had some really great discussion about maths, back in the days, when I was still more active in the forums.

From what I've found it's not the OpenGL implementation, it's that nVidia has custom workarounds for what Unity does to hardcoded constant-value matrices when transpiling HLSL shaders to GLSL. The issue here really lies with Unity. The problem is, that the HLSL->GLSL transpiler is not able to properly transpile matrices of constant values. Instead of simply outputting constant value hardcoded matrices on the GLSL side as well, the transpiler allocates a dynamic (aka: non-constant) array the size of the matrix for each fragment ("pixel") . This is done in global scope, so this array has longer lifetime than the shader's individual functions. for each fragment ("pixel") re-initializes this array with the hardcoded values at the beginning of the shader's main function. has the code use the value in that array (even though the same value is there, hardcoded, and used for initialization...) Now, this is a problem, because, if the shader compiler does not have a custom workaround for that broken behaviour of the HLSL->GLSL transpiler, the shader compiler will do as told, and allocate a bunch of vector registers to store the matrix for every fragment (keep in mind, that the code generated by Unity's HLSL-GLSL transpiler just tells the shader compiler, that there is a matrix of floating point values that could in principle be different for every fragment, and that that matrix is in global scope, so it has longer lifetime than any shader function and therefore cannot be optimized away). For small matrices this is bad, because in an ideal world, several waves (meaning: groups of fragments, vertices, whatever) should be scheduled on the same SIMD computation unit, to allow it to hide memory latency by working on a different wave if one wave is waiting for data. This is not "true" multitasking, meaning, that also registers of "background" waves are kept directly at the computation unit. If now one wave takes a lot of registers, less waves can be scheduled for that computation unit, increasing the impact of memory latency. While this is not optimal, it's not a full catastrophe either. If, however, the matrices are big, we go from bad to (much, much) worse. The shader compiler now is running out of registers in which to store the matrix. Instead the matrix gets placed in video memory (aka. "register spilling"). If this happens, the shader's performance goes from acceptable to "What do you mean, I should draw a picture? You just told me to spend most of my time copying numbers between video memory and registers!". I did report this issue to the Unity developers, but made the report from my personal (free) account (because I noticed it at home, while working on Scatterer's OpenGL performance). Of course the bug report was ignored... I should have really posted it at work, using our Unity premium support accounts...

Just because XBO and PS4 are planned later than Windows, does not say anything about Linux or Mac. Linux and Mac do not need extra certification by the platform operator, and do not require 100% of the UI to be controller friendly. (There is of course some platform-specific work involved, but if one plans to support more than one platform, one already sets up the project and the CI right from the beginning in a way that platform specific issues do not accumulate.)

Which is also null and void, at least in Germany: https://www.hk24.de/produktmarken/beratung-service/recht_und_steuern/wirtschaftsrecht/vertragsrecht/allgemeine-geschaeftsbedingungen/1156958

I agree, the only really important change was 1.0, as it added aerodynamics and heat simulation. Still, most of the old guides still hold true, especially the one about plane stability. The only thing you really need to forget is what people called a "gravity turn" back in the days, namely going straight up to 10 km, and then instantaneous tilting to 60°. That's pretty much going to break your rocket to pieces nowadays... Since 1.0 you need to do a real gravity turn, meaning that you give your rocket a very slight nudge towards east (or whatever inclination you want) right after launch, and let the aerodynamics do the rest (with minor adjustments). This of course only works if your rocket is aerodynamically stable, that's why I linked the guide to plane stability.

In my opinion Eeloo is easier to return from than Moho, at least without TACLS. I agree with magnemoe that Tylo is the hardest body to land/return from. Actually I think we need two lists, as there's usually quite a difference in difficulty between getting to a celestial, and returning from there. Just look at Eve. It's quite easy to get and land there, but returning is quite a challenge.

I'm rather certain such clauses in an EULA aren't legal and therefore void in many countries. Edit: "The EU requires Member States’ courts to presume that the arbitration agreement in consumer contracts is an unfair term, if it was not individually negotiated by the parties after the dispute arose" - http://arbitrationblog.kluwerarbitration.com/2016/02/25/consumer-arbitration-will-the-two-different-worlds-across-the-ocean-converge/

The barn was a concept for the lowest level of the KSC buildings. Some people still want to have it.

Are you on Linux? Unity didn't properly convert Scatterer 0.336's shaders to GLSL, and caused them to unnecessarily read/write to GPU memory quite often (see the discussion in the scatterer thread). The workaround for that Unity issue has been merged already on Github, but didn't end up in any released version of Scatterer yet. Edit: As a temporary workaround you can try using the Shaders file from Scatterer 0.331, but that is only a partial fix, as the Scatterer 0.331 shaders suffer from the same Unity issue, however the broken code is not running as often.

I agree. For instance, FAR on default settings, has significantly lower drag than stock.

Did you get the required dependencies (as listed in the first post, right at the beginning)? For me the (Linux version of) the mod is working perfectly fine.

Wait, what? You don't need an extra decoupler if using an engine plate? Why didn't anyone tell me?!?

It's not possible to be pulled into Mun's orbit in Stock. Unless you decelerate you will always get a flyby.

Hmmm, in 1.5 it seems that there's some crazy "lock orientation once movement gets small enough" code in place. I just had a lander on Minmus, that had SAS turned off, and trim at zero, and still it ended up tilted (with 2 out of 4 legs above the ground). Small torques (reaction wheels) could only make it oscillate around that orientation. Once a stronger torque (RCS) was applied, it shifted, but just to find a new "equilibrium" orientation, that wasn't realistic either... Either that, or the collider of the Poodle is now a meter longer than the visual model...

Okay, so I'm going to test if the issue persists with the latest Unity version, and if yes, file a bug report. Edit: I can confirm that the same issue persists with the latest Unity build for Linux (2018.2.something). Bug report is in the process of being filed. Edit 2: Bug report has been sent using Unity's Bug Reporting tool, including a minimal project with a really minimal shader for easy reproduction. Let's see if there's an answer. Edit 3: No news from Unity yet. I should have filed the bug report at work, where we have Pro licenses, instead of home using a free license..