evilwombat

March 16, 2018

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.

November 28, 2016

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

August 13, 2016

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?

August 12, 2016

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).

August 11, 2016

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.

August 11, 2016

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).

August 10, 2016

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.

August 9, 2016

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?

July 12, 2016

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...

May 2, 2016

7 minutes ago, v8Dave said:

You will also find better info on a crash in the log files, either in you KSP directory or in .config/unity3d

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

May 2, 2016

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.

May 2, 2016

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$

April 28, 2016

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

April 25, 2016

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

April 23, 2016

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.

April 23, 2016

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.

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.

November 13, 2015

Ah, that makes sense. Thanks!

November 12, 2015

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"

November 12, 2015

Thanks! That did it.

November 12, 2015

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

November 12, 2015

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.

November 12, 2015

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.

June 14, 2015

Manned Eve ascent (before and after 1.0).

June 4, 2015

Your Eve ascent stage is beautiful.

June 3, 2015

Hello. I had never published a craft before, but maybe this will be useful to someone. For anyone who is interested, I have built a craft capable of carrying an Mk.1 pod (with heat shield, decoupler, parachute, docking port, and occupant) into a stable orbit around Eve, starting from sea level. If launched from higher elevations, the final ascent stage typically has enough fuel left over to fly back to Kerbin and land. If launching from 1.7km ASL, I managed to return to Kerbin with something like 330m/s to spare. The craft relies on the mining capabilities introduced in v1.0 to avoid a refueling mission, or an enormous ascent stage. The resource mining also allows the lander/ascender's full fuel capacity to be re-used for the Eve transfer/descent. The only non-stock part is Mechjeb2 - it is recommended for efficient auto-staging, but is technically not required.

Suggested mission profile:

1. Launch from Kerbin into KLO, cutting away initial ascent stage as needed

2. Land on Minmus to mine and refuel

3. Ascend from Minmus (directly back into Kerbin SOI)

4. Transfer to Eve

5. Perform several progressive aerobraking manoeuvres (typically three-four passes, around 74k)

6. Begin final Eve entry

7. Use remaining fuel to avoid overheating during descent (a few basic fins might explode. That's fine.)

8. Parachute landing on Eve

9. Mine for resources and refuel (typically 120 days' worth)

10. EVA / science / admire the purple

11. Cut away mining equipment, landing gear, and fuel recirculation tank (this switches the ascender into asparagus mode)

12. Ascend from Purple Hell

Though the ascender is capable of reaching stable Eve orbit from sea level, you will need to land on terrain to mine resources and refuel. The ascender *does* have enough parachutes to survive a splash landing even when fully fuelled, but this would require an independent Eve transfer and entry stage, or a refuelling mission. These are left as an exercise to the reader.

Eve descent instructions:

1. Plan to aerobrake around 73-75km after the initial Eve transfer. Try to keep the craft pointed prograde if possible. Keep an eye on the orbit, and play with changing the orientation mid-braking to fine-tune things.

2. Around 85km, point retrograde and burn all your remaining fuel, to keep from overheating. A few Basic Fins may explode. That's fine - turns out these aren't actually needed. I'm just too lazy to go pull them off. If you aren't careful, you may lose a science instrument here, but aside from that, reentry tends to be rather uneventful. (NOTE: A suicide-burn entry from Eve orbit around 100km should work too).

3. Once out of fuel and going reasonably slowly (1200m/s?), point retrograde again and prepare for parachute descent. If you have Mechjeb2 installed, you must disable auto-staging prior to opening the parachutes.

4. Deploy landing gear, and activate the 'Brakes' action group to lock the landing gear suspension.

5. Land.

6. Deploy solar panels, start the drills, and activate the resource converter (buried in the center of the lander). Refuel.

Eve ascent instructions:

1. Make sure all ladders are retracted (using the '9' action group)

2. If using Mechjeb, under 'Attitude Adjustment', enable 'Use stock SAS'. Open Smart A.S.S. and select Surf -> UP. As of build #465 or earlier, Mechjeb's attitude controller tends to struggle with this craft while flying in atmosphere. Stock SAS does not have this problem. Make sure Auto-Staging is still disabled at this point.

3. If not using Mechjeb - activate SAS to point upwards.

4. Press 'Z' to throttle up all active engines.

5. Immediately afterwards, stage once to cut away the landing gear and mining equipment. This also cuts away a small recirculation tank, which will switch the whole ascender into asparagus / onion routing mode. The Stage delta-V display (if you have one) will now look a lot more sane.

6. One second after cutting away the landing gear, stage again to activate the remaining engines.

7. Mechjeb users- you should enable Auto-Staging at this point.

8. Ascend directly upwards until about 35-45k.

9. Perform your gravity turn starting from 35-45k. If using Mechjeb, this is a good time to activate the ascent autopilot. A target altitude of 100km should work. You may need to manually fine-tune the circularization by a few km. If you are past apoapsis, apply a small amount of radial burn (Rad+) to fix that, then wait until apoapsis and burn prograde for a tiny bit, to stabilize the orbit.

10. If you have ~1700m/s of dV remaining, go home. Else, use the docking port to add a splash of fuel first.

Craft files:

Complete craft, ready-to-fly: https://dl.dropboxusercontent.com/u/79740546/ESLA-Mk1-Full.craft

Eve ascender only: https://dl.dropboxusercontent.com/u/79740546/ESLA-Mk1-AscenderOnly.craft

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by evilwombat