evilwombat

I'm trying to pay the very first stock mission. I've built the first two craft and accomplished their goals successfully. Now I've built the third craft and it's sitting on the launch pad, but I realized I wanted to change something in the craft's design. How can I do this? From the launch pad, my only options are "Recover Vessel" and "Space Center". Clicking either of them takes me back to the KSC, but all facilities are "locked" and I have no choice but to exit the game to the main menu. I can use the "Pause" menu to revert the mission to the last vessel spawn point, but this does not allow me to bring the vessel back into the editor. It looks like my only option is to restart the whole mission from the beginning, which seems rather silly... What's the deal? ... selecting "Restart Mission" at this point causes a never-ending Loading screen and the only option is to kill the application. BTW, 1.4.1, Linux x86_64.

I've got one for KSP 1.2.1. I really need to make a thread on this. Craft file is in the video description. Instructions are at the end of the video. Alternate link: https://vimeo.com/192782068

I need the LD_LIBRARY_PATH part because I don't have Pulseaudio installed on my system, and instead, I have a local symlink called libpulse-simple.so.0 (whatever that's called) to /dev/null. Or has that been fixed in v1.1.3?

Hmm. I generally leave the KSP window alone. Since it seems to be sensitive to window size (and possibly position), I generally leave it untouched as the game is running. Usually the window can be moved without incident, but once or twice I've had some sloppy mouse movement resulting in the window getting "touched" in a way that brought out the problem. But I'm less worried about that, and more worried about simple startup killing off the X session. Here's what mine does (half the time): https://dl.dropboxusercontent.com/u/79740546/VID_20160812_035954.mp4 You can see why a screen recording program would have been unuseful here In some cases, the KSP window becomes outright huge (spanning the entire screen width) maybe a split second prior to the whole environment imploding, though this video does not capture that particular behavior. In the cases where the game DOES successfully start up, I do see a distinct moment where the window is resized. That is, the game starts up using some Unity default size (controllable through command line options you specified), and the game window remains this way (with no content) for the first few seconds after launch. A few seconds later, window resizes itself to match the dimensions set in persistent.cfg (this happens right when the monkey head appears).

Hmmm. Indeed, I have noticed the problem happens (at least, more) frequently on Gnome (Metacity) than on something more basic (twm). But, I am not running any fancy Gnome screen effects, or even the Unity environment (not to be confused with Unity the game engine - argh). I do indeed delete the 'prefs' file (or rather, overwrite it with a version without any of the ScreenManager options in it) on every startup, but this workaround stopped working in v1.1.2 / v1.1.3. Still no luck. The Unity resolution options don't seem to be the problem per se anymore. The game starts (with just a black window) using Unity size settings, but the mad resizing only right about when the Squad logo is about to appear. In some instances, the window resizes *once* and the game starts, but in others, the window grows out of control in a matter of less than a second. This makes me believe that the resizing / crash problem is not due to Unity internals, but due to something KSP code is doing as part of its startup sequence (like resizing the window again, this time to match the screen dimensions found in settings.cfg rather than in prefs). It's interesting that another user had a similar problem. While trying to catch this problem in the act, I managed to kill KSP an instant before it took down X. As it turns out, the memory leak is not within X itself (I don't think...) but within the window manager (metacity), as evidenced by a large amount of memory being freed if I kill/relaunch the WM without relaunching X. It makes sense that a giant burst of window resizing (and fighting the window owner) could bring out gremlins. I just wish KSP made a single attempt to resize itself and then left the dimensions alone. Sometimes this problem can even be triggered by inadvertently dragging the game window to a new location on screen. Sigh. Anyway, what is needed to diagnose this further? I am not sure what the exact logic is that KSP uses to set its screen dimensions, but clearly this happens in two steps (once on startup, through prefs, and the second time, through settings.cfg). Maybe the settings.cfg mechanism is being a bit too aggressive. Shrug.

Thanks. I appreciate the effort, but the Unity options don't do jack excrementse. Well, that's not entirely true. The -screen-width and -screen-height options *do* in fact set an *initial* screen resolution. As soon as I launch KSP.x86_64, I get a black window sized to the dimensions I specified. However, after a few seconds of showing a black window, the game will either resize itself to whatever was configured using the KSP Graphics options, or it will start madly resizing itself until it occupies the entire screen and the entire window manager crashes (killing off any other graphical applications that were open at the time, and kicking me out to the login screen). So, no. Unity (or the game) still insist on forcing a screen size, and they still try to fight the window manager (classic metacity) until the WM runs out of memory. Normally I wouldn't be a cheeks hole about this type of nonsense, but (a) paying customer and (b) it's been months, and despite my love for the KSP developers, the situation at hand is nevertheless frustrating. Especially so because this wasn't a problem prior to 1.1, and the crash takes down the whole damn desktop environment with it. As for the Patcher, hmm. I am able to run Patcher and it completes rsync successfully. Problem is, the resulting game instance is unplayable, and I have to log back into the KSP Store and download a fresh copy (or unzip the local archive if I kept it).

Problem still happens. KSP developers are working on console ports, but existing paying users still have to deal with Unity getting into an infinite-resize loop and taking down the rest of the desktop environment with it. Plus, the Patcher repo still points to a KSP instance that is outright busted, to the point where it won't even start (for months now). Since v1.1.3, the workaround of deleting the screenmanager crap from 'prefs' no longer works. Come on. Is there no way to force Unity to operate at a fixed geometry, and stop trying to alter the size of the game window more than ONCE during startup? Come onm guys. I've been with you since 0.2whatever.

The Linux version *still* fails to launch (two months later) with a "player initialization error" if Patcher is used. The version downloaded from the KSP Store works, kind of - every other launch, Unity gets into a situation where it starts madly resizing the game window on startup, until the window manager runs out of memory and is killed. This happens in a matter of seconds. Deleting the size/screen selection from 'prefs' helps, but only about half the time. Versions prior to 1.1 did not have this problem. I know everyone thinks that Xpox and PS4 are the next shiny things, but can existing, paying customers get some bugfixes, please?

Thanks for the 1.1.3 update. However, I am afraid the Time Warp feature might be working a little too well. That is, if I accept a contract, it looks like the contract vanishes as soon as I click on the VAB. I still get to keep the funds for the contract, but the contract itself seems to be gone (as my entire contract history). I've got my savestate backed up, so that's all good, but I think the warp feature is skipping just a tad too much of the gameplay :). Am I the only one seeing this? Removing BetterTimeWarp (the pre-release off dropbox) seems to resolve this for me, at least in the one case that I tested. I'll try again but am discouraged by the prospect of Unity doing the thing where it constantly resizes the window until the window manager runs out of memory. Maybe another night. Sigh...

Such logs do not exist in the event of this crash.

It's a patcher problem. Go to the KSP Store and download a fresh copy of 1.1.2, and unzip it overtop your existing KSP_linux directory. That'll fix it.

Solution: Rather than using the Patcher, (re-)download KSP 1.1.2 from the KSP Store and unzip it overtop your existing KSP_linux directory. That should fix it.

Ever since patching v1.1.1 to v1.1.2, startup on Linux (Ubuntu 14.04 LTS, x86_64, nvidia) results in the following error. steve@hypernelson:~/KSP_linux$ ./KSP.x86_64 Set current directory to /home/steve/KSP_linux Found path: /home/steve/KSP_linux/KSP.x86_64 Mono path[0] = '/home/steve/KSP_linux/KSP_Data/Managed' Mono path[1] = '/home/steve/KSP_linux/KSP_Data/Mono' Mono config path = '/home/steve/KSP_linux/KSP_Data/Mono/etc' displaymanager : xrandr version warning. 1.4 client has 2 screens displaymanager screen (0)(DP-2): 1920 x 1080 displaymanager screen (1)(DP-1): 1920 x 1080 Using libudev for joystick management Importing game controller configs PlayerInitEngineNoGraphics settings: Could..... not preload global game manager #0 i=0 Failed to initialize player steve@hypernelson:~/KSP_linux$

Two things that have helped me: Since I don't have PulseAudio installed (credit goes to another user of the bug tracker): $ cd KSP_linux $ ln -s /devl/null libpulse-simple.so.0 Then, launch the game with LD_LIBRARY_PATH=. ./KSP.x86_64 If that still doesn't help (and causes mad window resizing, or crashes your display server), edit ~/.config/unity3d/Squad/Kerbal\ Space\ Program/prefs, and delete any lines containing the word 'Screenmanager'. Save, then launch the game (as above). This deletion needs to happen every time you launch the game (or, I guess, when it exits cleanly). A shell script is recommended

Thanks. I've had a little more success after I realized that the 'Screenmanager' nonsense in the 'prefs' file gets saved back to the file every time you exit the game. So, it's been standard procedure to delete the 'Screenmanager' lines from 'prefs' on *every* startup. Yeah, I should write a script. I am not using steam, so I don't have any launch options, so I don't think "-force-glx-direct" applies to my situation... Maybe I can try *adding* and see if that helps

For me, the X session restarts all on its own, presumably due to the window manager not liking size abuse (how on earth...?). I should point out that in addition to the screenmanager workaround, I had to synlink libpulse-simple.so.0 to /dev/null (inside the KSP directory) and launch KSP with LD_LIBRARY_PATH=. or else it aborts even before getting to the point of (maybe) crashing the window manager.

Hello Linux x86_64 here, Ubuntu 14.04 LTS, Gnome Classic (metacity, no compiz or other graphical crap), nvidia-340. I am seeing a fairly consistent crash on startup. I am running a 2x 1920x1080 setup, but the problem happens even in single-monitor mode. After launching KSP_x86_64, a black game window appears (sized to be about 1920x1080, plus window decorations). A few seconds later, the (still black) game window flickers, killing my window manager, all running Xorg clients, and my entire Xorg session, meaning that I have to log in again. This is quite reproducible. I found that the problem is a lot less likely to happen if I edit ~/.config/unity3d/Squad/Kerbal Space Program/prefs and delete any lines containing 'Screenmanager'. However, usually these lines will return if the game is restarted, meaning that I have to do this every time the game starts. Sometimes, even deleting the screenmanager lines does not prevent the game from crashing the whole graphical interface, but it generally helps. Any thoughts? Edit to add: These are the lines that I have to delete in 'prefs'. I imagine the actual resolution is a little lower than 1920x1080, due to sizes of window borders and window decorations. Perhaps Unity's initial attempts to attain this resolution (before KSP does its own internal window resize) is what's causing the disaster. <pref name="Screenmanager Is Fullscreen mode" type="int">0</pref> <pref name="Screenmanager Resolution Height" type="int">1053</pref> <pref name="Screenmanager Resolution Width" type="int">1912</pref> During the startup phase (before the screen with the progress bar and three kerbals), it is very easy to crash the game (and the window manager, and X) just by trying to move the game window or to resize it.

Ah, that makes sense. Thanks!

Fair enough. I would have imagined this to be a bug rather than a feature. I expect the intention of the biome mechanic would be to allow for different science data to be gathered depending on where your craft is LOCATED, rather than how it is moving. For example, if I want to collect an atmosphere reading while passing through some body's atmosphere, the craft should be able to do it as long as it's deep enough in the atmosphere, regardless of the trajectory. I expect this is how it would work "IRL"

Thanks! That did it.

Sadly, it's a rather distracting feature. Is there a way of turning this behavior off?

Hello. Passing through Duna's atmosphere (say, at 25k alt) while on an orbital / suborbital trajectory causes the current biome to be reported as "flying low" (as it should be). However, passing through Duna's atmosphere (again at 25k) on an aerocapture / escape trajectory (eccentricity > 1.0) causes the current biome to be treated as "in space near", even though my craft is only at 25km altitude, and flame effects are in full swing. This seems like a bug - in both situations, the craft is in essentially the same location. I am running v1.0.5, with MechJeb2 (2.5.4-522) and TimeControl (v1.0.4-hotfix2) installed, though I can't imagine either of these having an impact on this problem.

Hello. If I accidentally double-right-click on a vessel (such as while hunting for the right part to right-click on), the camera gets stick in click-and-drag mode until I right-click away from the vessel. This happens in the VAB and during flight. This looks like a new glitch in v1.0.5.

Manned Eve ascent (before and after 1.0).

Your Eve ascent stage is beautiful.