Squelch

We are aware of the problem with the x64 plugin, and we have been working on it.

This isn't a bug, but a limitation. There is a warning dialog that pops up if you try to accelerate physics warp past 2x. this is because the number of calculations required to accurately render the positions of the craft can add a heavy processing load. The result may be misplaced vessels during the warp. This is corrected once warp is exited usually. I'm assuming that because you are going to 3x and above, you have elected to suppress the warning by checking the radio button "Don't show this again" It can be reset by opening the settings.cfg file and finding the line SHOW_PWARP_WARNING = False and setting it to true.

The supplied KSP.logs do not show any evidence of mods, but you are correct that this seems to be a common cause of crashes or loading freezes where mods have not been updated. The documentation isn't exactly clear when it comes to Linux and these commandline switches. -force-gfx-st is specifically mentioned as a workaround for Phenom processors in Turbo mode, whereas -force-gfx-direct does not. Both do force single threaded rendering as you point out, but poor performance will result. The purpose in its use is to isolate any potential conflicts, and should not be considered a long term solution. Any of the -force-* options should be used with care and are there for debugging purposes, or where it is absolutely necessary due to hardware limitations. @monstah is correct in that KSP.log does not give all of the information that we need, and Player.log will give far more indication of what is going on. It is suspicious that they are not being written.

Hi @Arugela What is your existing system open files limit? # ulimit -a The standard is 1024 and your increase seems to be excessive for normal operation. Your logs do not indicate which distribution you are using >OS: Linux 4.11 unknown 64bit Could you let us know by running uname? # uname -a Player.log should be created in your "Home/.config/unity3d/" and "Home/unity3d/Squad/Kerbal Space Program/" folders unless specifically suppressed. You say these are not present? Is the prefs file missing too? Could you go to your KSP installation folder and open a terminal. Run the following to establish that a new folder "Home/unity3d/SQUAD/" is created if it's not already? It should also create a Player.log file there. Posting all Player.log files may help us to identify the problem. # ./Launcher.x86_64 Would you also mind trying to start KSP with the following switch from a terminal in the KSP installation folder to see if it helps with your Phenom processor? # ./KSP.x86_64 -force-gfx-st

We have identified the problem and a fix is currently being tested.

There may still be small visual gaps which are unavoidable (think of it as grass growing between the paved sections), but there should not be bumps. If bumps are still present, then please report this on the tracker. The facility levels will need to be identified preferably with a savegame attached.

Hmm, that's an interesting one. We supply 3 presets that can be selected from the setting menu. We don't directly support custom presets and manual edits are at your own risk. However, this may have worked in the past and the new preset appeared, but with localization, it seems that only 3 presets are expected. Adjustments of the individual "Planet" detail on the settings page wanders into feature territory, so not really a bug. Please do report this on the tracker as feedback so we can take a look. Outline exactly what you are trying to do, and provide an example. In the meantime I can offer two suggestions: Edit one of the existing presets to your liking - Select this preset from the settings panel Place your custom preset at the end of the preset list - Select the last preset from the settings panel and ignore the "New Text" label

The screenshot indicates version 1.2.2 @The Moose In Your House Please do take advantage of our update, and if problems continue, then please also follow the reporting guidelines I linked. I was referring to your GPU drivers and control panel, but do not know what they might be. Logs will help us identify if the game is broken, and information about your system which may be relevant to your problem.

Hi @White-Gandalf Welcome to the forums, and more importantly,the world of KSP. Since your post we have released the full 1.3 version. Please do try this instead. Depending on where you obtained KSP, the launcher may not be necessary, and the executable can be run directly or via the shortcut that is generated. Please let us know your system specifics and distribution (KSP store, GOG, etc) to enable us to help you further? The game logs help us in identifying problems immensely. Here is a guide to where to find the information we require.

For the colored screens, it really depends on your system. You don't say which distribution you have, so I can't guess where the game is installed. Please follow the advice given on the bug reporting thread linked below to find the files we would need to help you further. The jagged orbit lines may be something else entirely, but let's concentrate on the other graphical problems first? We have just released a new version which may resolve the problems you are encountering already. Please do update the game and report back.

We don't have a native 3D mode for sure. I'm a bit confused about where this happens. Main menu and other scenes except the loading screens? Please can you supply your logs, and also check your graphics driver/control panel settings. It looks like anaglyph 3d has been globally, or game specific enabled.

Hi @Silverwood and @brian4951welcome to the forums. Persistence is another name for the saved data. This normally resides in memory during a game, and copies of that data are written to the .sfs save file. Loading a save file writes that data back into memory so that you can continue where you left off. This particular bug is caused by the data that is still in memory not being updated when the training save is loaded. The level of the buildings affects the options that are available to the player. The workaround is as the others say - Either restart the game and go straight to the training session, or load another save that has fully upgraded buildings before going to the training sessions. This bug has been reported and has been fixed in the Pre-Release version as part of our feature addition and maintenance program.

Hi @kolmansverre I have marked your self found answer as the solution. On MacOS Sierra, the security settings are more strict, and gatekeeper is blocking access to the files. By moving and then replacing these files, the filesystem now sees these as safe and does not quarantine them. This should no longer be an issue in KSP 1.2.9 on Sierra, but alas this workaround is still necessary on 1.2.2

Fantastic design, execution, and what a brilliant presentation?

Hello @Daveroski, We have a triage system on our bug tracker. Each report is reviewed, verified, and checked against other similar reports or known issues. The report is then prioritised based on that information. I replied to your report when you first made it, and asked for more information, and you kindly provided us with that information. As I remarked back then, this seems to be an edge case (something that is rare or hard to reproduce) and your report was placed in the queue for further investigation, but with a low priority due to the difficulty of reproduction and rarity of occurrence. We do not ignore bugs, but have only so many resources available to us to deal with every one. I'm sorry if it appears that nothing has been done. I have spent some time specifically looking at your issue, both then, in the intervening period, and again more recently. Yes the savegame certainly exhibits a problem, and it is not a nice one, but it is unique and very difficult to reproduce. A savegame alone does not constitute a full reproduction. There are an infinite number of variables involved in a sandbox game such as ours, and any confluence of circumstances can bring about behaviour that might not be expected. That sometimes is rather unpleasant when hours have been spent getting to that point, but it is a regrettable possibility. To the issue. The game engine that we use (Unity3D) allows flexible joints. These can also be joined together and we use that ability in the construction of craft. The joints are never fully rigid, and there will always be a small amount of flexibility even when they have been constrained. KSP is (in)famous for wobbly rockets and many steps have been taken to successfully stiffen large constructions in recent releases. There is still some flexibility in all joints, and this has been kept as a design decision to simulate the natural non rigidity found in every day life. It is also part of the destruction system, and KSP is equally famous for things blowing up. However, when joints are close to each other, they can sometimes interact and cause mutual oscillation (they fight against each other) and this can increase in amplitude to the point where the assembly will destroy itself. This is what I believe is happening with your particular craft. We are aware of some assemblies that oscillate in this way, particularly where several joints converge close together. This is also a well talked about point on the Unity website. A quick search for "Unity joint wobble" should reveal a myriad of questions and offered solutions. We have tried them all, but none have worked without severely restricting other parts of KSP. It is an inherent part of the game engine. We do have a device that helps - Struts - They serve to stiffen the joints when placed appropriately. In engineering, the triangle is known for its strength, so attaching struts so they complete a triangle is often the best strategy. However, a triangle only acts in one plane. A real world analogy might be a shelf bracket, it forms a triangle with the wall to support the shelf. It works best in the vertical plane. It is not so strong in the horizontal plane and can easily be moved in this direction. To gain the best advantage of the triangle structure, a placement of more than one, and in more than one plane will give the strongest assemblies. Your vessel. I have looked long and hard at your vessel both in the save and the craft file. The savegame vessel destroys itself in quick order when loaded. I have extracted the vessel from the save and loaded it independently. It still destroys itself. I have reduced the craft file so that only the final stage (the miner) is left, and this appears to be stable. Both the extracted vessel and the original craft file look identical. I then reduced the problem vessel down to the bare minimum that still showed the problem. The craft file was also reduced to the same level, and the two files were compared. The differences are minor, but there are some very small differences between joint locations in the two craft. This comes about when two vessels are decoupled from each other, and they are both effectively rebuilt at that point. The very small and unavoidable differences that are introduced when this happens are not normally a problem. However, this insignificant position difference combined with joint wobble is the enemy in my opinion. Your miner craft has eight legs radially attached. You have attached two struts to tie each of the ore tanks to the central fuel tank. This completes a triangle in the vertical plane. This is much like the shelf bracket example. There is no secondary strut to tie the legs together in the horizontal plane. The instabilities talked about previously are not always immediately apparent, and it may take the smallest impulse to trigger them when combined with structural weakness or a small change in position. I have only managed to trigger the instability in the craft file once in 30 decouples and reloads. The simple modification of taking one of the struts that tie the ore tanks in the vertical plane, and re-attaching so the ore tanks are tied to each other in the horizontal plane immediately solves the shake and the vessel is safe. Conclusion. This particular craft has been an unlucky casualty of a combination of circumstances. It is rare, and incredibly hard to reproduce reliably in recent releases of KSP. That does not make it any easier to bear after you have invested time and effort. However, there is little that can be done to prevent this from happening from our development perspective and due to the rarity of it's occurrence, it would be hard to justify the effort involved. Physics is both the cause and the solution. The cause, because there is weakness in the horizontal plane which is an invite to the oscillation problem inherent in the game engine. The solution, because it takes just a simple strut to add that horizontal strength and therefore prevents the oscillations. History is full of accidents and disasters caused by the simplest of design oversights combined with unforeseen circumstances.

We can neither confirm nor deny that such a feature exists. We can confirm however, that this is not a bug.

Yes, they are in the settings.cfg file found in the installation root folder, towards the bottom.

Well gravity does suck...allegedly Just about every sandbox game could be described as lacking something, so providing the ability to modify the game to suit individuals needs and wants is really a no brainer. Are there a set of rules that dictate what should and shouldn't be in any given game? Some of the best ones have broken any perceived conventions and are later hailed as groundbreaking. It is the territory indeed.

I'm currently running Windows 10 and have used the controller with KSP previously. However, plugging in to check this issue required a driver update and reboot, so there may be something what you say. If the controller seems otherwise dead, try the following assuming that the controller is using the USB port and is wired directly. Check the controller is being detected by windows - Open Game controller settings [Typing joy.cpl into the search box or navigating the settings windows] Alternatively type devices and open the devices and printers page. With this method, the device may be shown as an unknown device named controller. Opening the properties revealed a reboot was necessary to finish installing the drivers in my case. (Windows does have a tendency to partially update some files thereby restricting any services that use them until the next reboot. This is not always conveyed to the user and can result in some functions simply failing to work). If a wireless adaptor is being used, check the driver installation for the adaptor first.. After the controller is verified as being present and functioning on the system via joy.cpl, it does appear to be recognised by KSP with all axes and buttons able to be bound.

Thanks for sharing that. While the console utilities do allow the controllers to be customised, these customisations will not be reflected in the game help screens. If anyone does change their scheme, please make a note of any changes you have made, particularly if reporting problems later. Caveat emptor. Thanks for sharing that tip. A further tip is anything that would use the Mod key on the PC versions, will also use the mod buttons on the consoles more often than not.

While in docking mode, the X or Square button will toggle between linear and rotational control. they can't both be used at the same time currently.

The pointer can be toggled on and off by pressing the left thumbstick. Be aware that while it is enabled, many controls are disabled, so if it looks like you have no control of your craft, check the pointer mode.

To toggle the motion sensor on the PlayStation 4 controller in KSP, Long tap L3 Button.

1. We really need more details on how to reproduce this one. The steps that you took before this happened could be revealing. You have ruled out being in pointer mode, but there are other valid reasons for a loss of control. Has the craft flown successfully already? Running out of electric charge with a probe core is an example. If possible, try to explain the situation as fully as possible, so we can investigate. 2. There could be a number of reasons for this. Steering while on the ground and travelling at significant speed (we are often travelling faster than we realise) will make any plane slide. If the plane does not travel in a straight line, check that your wheels are not canted as this can make them unstable. Asymmetric parts can induce drag on one side that will also cause an aircraft to veer. 3. Precision control can be turned on with Mod (Left or right bumper) and tap the left stick.

I won't call you stupid, but I have clarified my original assertion. While the PlayStation 4 does have mouse and keyboard input support, not all titles utilise it. Xbox One does not currently have mouse input support, and keyboard support is partial. The differences between the two platforms might give an indication as to some of the rationale behind it not being implemented at this time.