sal_vager

Unfortunately it has come to my attention that members are taking this game far too seriously, I have received several complaints of argumentative behaviour and accusations of cheating, and this thread has devolved into roleplay, fighting and similar behaviour on several occasion, these are forbidden by the forum rules. It has become an administrative burden, hopefully in the future a new game can be run where all participants can act as adults and enjoy some harmless fun, but that time isn't now, so this thread will be closed. It's time for a new game.

Glad it's working @Kerbal101, it seems Unity isn't detecting OpenGL correctly unless forced, it's a bit of a worry that you need to use LC_ALL=C though, as locale agnosticism is set in Unity, it should always write cfg files using period as a decimal delimiter instead of comma.

I think it is Mesa 12.x, this came up a few weeks ago and the member solved it by updating Mesa, that might have been Fedora though so the newer Mesa was available. Edit: I may be losing my mind, this is all I could find and it was not resolved. Can you try forcing OpenGL and direct rendering, see if one or both fixes this. -force-gfx-direct -force-glcore Also try with anti-aliasing disabled, that has caused trouble in the past with the Mesa drivers.

Hi @Alex Vovk, we do not have any access to accounts here on the forums, please contact Squad at support@kerbalspaceprogram.com for assistance.

Hi @Kerbal101, this is a graphics driver issue, I hear the latest stable mesa driver fixes this.

Merged in with your post, good luck with your planes, they must be large if they are 1:1 scale as Kerbals are small

Moved to support.

It does though, but your docking port on the rover needs to be the rovers root part. Here's where the question "Why do I have to click twice to re-root my vessel?" is also answered. I assume your Pathfinder is in the VAB, load in the rover using the merge button and place it to the side, press "4" then click the rover, then click the rovers docking port. You can save a step by pressing 4 while the rover is held by the mouse, KSP assumes the sub-assembly (or the entire vessel) that you have picked up is the one you want to re-root. Now the newly re-rooted rover will have a node to attach the docking port to the port on the Pathfinder.

Hi @cartman, Unity3D enumerates the controllers it can detect when the engine is started, unfortunately a controllers number can change if it is unplugged or the PC is restarted, even if only one controller is present. This is a major issue on Windows where controllers can be enumerated by Unity differently each time, less so on Linux and OSX where controllers are labelled by the operating system as js0, js1 etc. This meant of course that your bindings would not work if the controller was 1 this time, but 0 before, as Unity treats the keycodes from each joystick separately. Unity3D offers a way to deal with this though, via the controllers name, however as you have found this fails with two identical controllers, and there is no method in Unitys Input class to get a controllers unique identifier. This is fine for basic games where all 8 joysticks in Unity's input manager can be treated the same, or a few popular controllers can be set up and detected via their name, for example the X-Box and Playstation gamepads. It's not good for games where the player could use any number of flight sim sticks, especially where the player can bind those sticks to suit their tastes, the developer has to write an intervening layer to translate the players custom bindings to the ones baked into the game when the project is built. That only gets around one problem though, there's plenty of others such as the hard limit on fire buttons and axis, the lack of hot-swapping, the detection limit of 4 controllers and complete lack of access to the UID. None of this is news to a developer using Unity for their game, people have been complaining about all of these issues since at least 2012. So the controllers enumeration cannot be used because this can change, the controllers name can be used but there are limitations, and using both the name and the controllers number in the enumerated list doesn't work as you have the same issue as using the number alone, T.16000M#0 can be T.16000M#1 the next time you play, so none of your bindings would apply. There's 3rd party controller plugins for Unity, though incorporating them at such a late stage in KSP's development isn't going to be trivial it's something I've been asking for for a while. A more immediate option might be PPJoy, letting you combine both sticks as one device with twice the axis and buttons but watch out for Unity's hard limit of 20 fire buttons per controller, or set up one of the T.16000M's as a virtual stick with another name. Hope this helps.

The retina display is not radically different to any other monitor, it just packs more pixels on a smaller screen and to software it looks no different than a regular hi resolution monitor. OSX automatically doubles the size of UI elements to make them usable, otherwise you'd have the same problem with the Apple desktop. You can easily use KSP on a high resolution monitor by increasing the UI_SCALE entry in the settings.cfg above 1.5 As it is a floating point value 1.5 is 150% scale, 2.0 is 200% scale and so on, so increase it until it looks right on your screen. Hope this helps.

Okay @Rich T, I can fix your ship, though it's only by using the very same autostruts I recommend against... To answer the questions above though, this is not a normal real world phenomenon, it's a bug, but there's a problem. This particular bug appears to be in the Unity joints themselves, which use PhysX for their physics, and while they behave most of the time under some conditions they can start feeding motion back into each other. Here's my demonstrator in 0.19.1 And another in 1.2.1 This seems most likely to occur with several relatively light long parts, it can also manifest when solar panels are extended, and when a long vessel is low on fuel (it's lighter). Stations seem to be prime targets too. Unfortunately, stiffening the joints has no effect, whether using KJR or the new joint reinforcement, modifying the joint values in the Unity editor also doesn't prevent this. The only things that work are to strut vessels that show this behaviour, the feedback still occurs but parts are prevented from moving further than the struts will allow, and to increase the mass enough so that these vibrations dampen out. Now that we have autostruts we can abuse them to save our stations from the PhysX Kraken, and I saved your space station by finding all instances of autostrutMode = Off and changing them to autostrutMode = Root You can find the autostrutted save file here. This may have left some of your other craft somewhat rigid, but they are likely going to still work unless they relied on being flexible. Most of the time the above just doesn't happen, and PhysX in Unity is a bit of a black box, you can get the current position and velocity of the parts as they are flailing around but not why this force is being applied to them. Any explanation would be a guess and the damper values should be preventing this, I do know though that PhysX is 32bit, so integer overflow might be occurring here, but without debugging PhysX itself I can't know.

Hi @Skavies, can you tell us where Steam is installing KSP, and if this is different to the hard drive containing windows? Your logs may help with this issue, please upload the output_log.txt and dxdiag hardware report to a site like dropbox for us, thanks you.

Autostrut and rigid attachment are still fairly new, there's not a lot of information available, though I'm sure in time someone will post everything they've learned about them. Autostruts were added only to wheels to begin with, and were an attempt to make them behave, several players discovered them when they saw that their stations became much more rigid after docking a spaceplane, or any craft with wheels. They have since been expanded to be an option on nearly any part (it must have an action menu), the autostruts attach to the heaviest part in the case of wheels, but can optionally use the root and grandparent part when used by the player. Autostruts provide a strong support from the part to the root/heaviest part, but don't provide the flexibility in placement as regular struts. Rigid attachment was added as an alternative to autostruts, rather than magic invisible struts solidly securing a part to the root etc, rigid attachment increases the strength of attachments between parts, and allow for some 'give' or flexibility in the joints, several rigidly attached parts can still bend or sag, but to a much lesser degree than regular part attachment. One use for these is with the T38 decoupler, which used to be physicsless so it wouldn't wobble, however this caused the game to crash on OSX when this decoupler was staged, now it is a physics part and rigid attachment makes it usable. Of the two, rigid attachment is simpler, strong enough for most uses and is designed with large heavy vessels in mind, autostruts were a workaround which has been dressed up with a UI, and unless you cannot make your craft work using rigid attachment or regular struts I recommend that autostruts are avoided. I personally prefer the good old fashioned strut, as its properties and the control they give me are fine for all my designs, whatever the size.

I think you will struggle to re-enter safely with that craft, the pod can take the heat if it's re-entering blunt end first but the other parts are not as tolerant, you really needed that heat shield. But it might be possible, first you need to get into as low an orbit as possible, with as little fuel as possible. Luckily this is the easy part, when you're at apoapsis burn retrograde so your periapsis grazes Kerbins atmosphere, I'd not go lower than 65km, 68km would be safer, at that altitude you will gradually aerobrake without overheating, lowering your apoapsis with every orbit. Many orbits later, you have two choices.. You can raise your periapsis out of the atmosphere so you don't re-enter, send a rescue ship and EVA the Kerbals over, don't forget the heat shield, or... Re-enter, burning all your remaining fuel to slow yourself down, the less time you spend at high speed in the upper atmosphere the less heat you'll have to deal with, and the thicker lower atmosphere will have enough time to slow you so you can open the parachutes, don't open the parachutes early, they should be set to open when safe but if they aren't then wait for the icons to turn white. Good luck!

Well, Rich T does say he's using mechjeb immediately above my post, soooo.... Emphasis is mine but I doubt it's the issue here.

Hi @Crampman, are you overclocking? This thread on the Microsoft forums suggests that can be a cause. In some other threads I have found on this error the user has resolved it by updating their bios, see here and here. If your computer is still under warranty you can have the vendor flash the bios for you.

Have you installed the latest module manager into 1.1.3? I ask this as it appears to be causing your issue. As far as I know, MM 2.7.5 is for 1.2.1, not for 1.1.3 and should not be expected to work. You'll have to remove it and try again.

Also make sure you have pressed Z for full throttle

These might help, they discuss the problems of saturation even with control moment gyroscopes. Control moment gyroscopes on the ISS. Optimal Reorientation of Spacecraft Using Only Control Moment Gyroscopes.

Well, dropbox is okay for files, though I really need to find an alternative as dropbox's "Don't forget to login/sign up!" messages are really annoying. Mechjeb is not likely to be causing the issue, but I hear it's not yet updated for 1.2.1

Saves that are migrated over several versions can have duplicate parts as the tech tree changes, and what you have unlocked is recorded in the sfs, it's unusual to see so many of the same part though. These additional parts can be edited out, if you upload the save we could take a look.

Is it perhaps hidden on your system? We know almost nothing of your PC so far, except that you are running the Windows version of KSP 32bit. Your output log should be in the KSP_Data folder, if it isn't it suggests a permissions issue, which is unusual for Steam.

@Firemetal, @Rich T, could you please share your saves just before docking, the rest of us could take a look and see if we can come up with something.

Improved link visibility. Edit: Uomocapra has fixed the file and link.

@Red Iron Crown found some Raid and has gotten rid of those pesky spidermen, arachnid-free version now available.