soulsource

It depends on what you expect. If you want an orbital mechanics sandbox that's simplified enough to be quite an entertaining game, but still requires you to learn a lot about classical mechanics (assuming you don't know all that stuff by heart already), then KSP is really great. If you expect a game you can play without reading up on physics, and without having a spreadsheet calculation (or someone else's results found in the KSP wiki) open in the background, then KSP is not for you. For me as a physicist KSP is one of the greatest games of all time, but yeah, I might be biased, as I consider it fun to calculate everything myself.

As others have said, the wobbly rocket are intended to be like that, as a gameplay mechanics. KSP is not an accurate simulation, it's a game, and the developers put in a lot of things they consider fun. Of course their definition of fun does not necessarily match yours, but luckily KSP has quite an active modding community. Kerbal Joint Reinforcement is probably what you are looking for. There's an updated dll file for 1.4 available.

I'm against this, for a simple reason: Who has to decide what is political and what is not? Is it political to discuss the benefits of Soviet engines over American ones? Is it political to talk about Valentina Kerman (female Kerbals were a topic of political debate...)?

Sorry, I have to defend Unity here. The bad reputation it has is mostly caused by the licensing terms, which make it an attractive choice for asset flips and other low-quality games. Furthermore it doesn't help Unity's reputation that the free version forces the "Made with Unity" display, while the paid version (used for professional games...) does not show it. From my experience as a game developer and from what I've heard from my coworkers, Unity's quality is actually rather good when comparing it to other game engines...

Not that I have ever attempted it, but shouldn't it still be possible to use the little thrust one gets for aerodynamic flight? Anyhow, I thought the Joolian surface cannot be reached as all probes will sooner or later explode on the descent? Back on topic of balancing an atmosphere. You'll also have to ask people if they play with or without FAR, as without FAR drag is unrealistically high, so return missions are more difficult.

It's technically not possible to stream video games over a package based service at an acceptable quality, as there are routing and caching delays, leading to an often unacceptable input lag. Of course there are exceptions: Games where input lag is not an issue. Also, since the delays are a fundamental property of the used technology, having more bandwidth will not be able to solve them. It will however reduce latency spikes by allowing redundancy. If it were a connection based service (what the internet is not), quality might get close to acceptable as it'd "only" be limited by the speed of light (what is still a quite considerable input lag for realistic distances between server and client). I personally would not like to play KSP with input lag, although it's certainly playable, as anyone who landed a probe on the moon in Realism Overhaul can confirm (thanks to signal delay of Remote Tech).

0.23.5. I think it was my first Mun "landing", a probe that tipped over and partially exploded, but the core and sensors survived, so it was a success. I don't have that picture any more though. The oldest pictures "I" still have are in this forum post:

Does the logfile say anything? See this post to find out where it is:

Depends how you deleted it. If you just deleted the persistent.sfs file, there are backups in your KSP/saves/saveName/Backup directory. However, if you deleted the save from the "Load Savegame" menu, then it's as far as I know gone for good.

Yep, it's a link to your home folder, not the shareable link.

I've spent today mostly trying to get my gamepad to work with 1.4.1. As you probably all have seen in the tech support forum, 1.4.1 has this nasty issue on Linux, that it doesn't allow joystick input at all, and for gamepads the analogue sticks can't be assigned. Anyhow, I was about to start hacking on a mod that just reads the system's joystick input and sets it as control input in KSP, when I remembered that such a mod actually already exists: Advanced Fly-By-Wire. So, instead of writing my own mod, I've started to mess with Advanced Fly-By-Wire. Getting it to compile for KSP 1.4.1 and Toolbar Continued didn't require any code changes at all. Everything seemed fine at first, until I realized that just recompiling the mod caused issues with KSP's own input system, which meanwhile also uses SDL. After a lot of guessing what could be the cause of those issues I finally figured out what happened: Advanced Fly-By-Wire was consuming input from SDL, stealing it away before KSP had a chance to use it. A google search and a bit of experimenting later I came up with this nifty patch , and now the whole thing seems to work perfectly fine. Long story short: I've got my gamepad working with KSP 1.4.1 and Linux, and it only took me 6 hours or so to get it to work...

I've found a way to get my input working! But first: The fact that there's a workaround should not stop the investigation of the original bug. Advanced Fly-ByWire to the rescue! While the plugin has not officially been updated to KSP 1.4 yet, it can be recompiled against the new game dlls and the updated Toolbar with nearly no changes to the source code. Edit 3: Scroll down to Edit 3 below, old text left for reference: I don't know if I can post the dll I just compiled, as some modders are not too happy if someone else just recompiles their mod and uploads the dll... So, instead I'll just post a step-by-step guide of how I got it to work. Install a C# compiler. I used Mono 4.4.1.0. Download and install the old version of Advanced Fly-By-Wire. Delete the Toolbar mod that comes with it. Download Toolbar Continued and install it. Clone the git repo for Advanced Fly-By-Wire In the Advanced Fly-By-Wire source tree edit the file ksp-advanced-flybywire-linux.csproj to have dependency hints point to the correct dll paths in your KSP 1.4 folder (don't worry about KSPUtil.dll, that one isn't needed any more). I've also added <DefineConstants>LINUX</DefineConstants> to all configurations, just to be sure, but I don't think it's required if you select the correct configuration when building. In the same file fix the <PostBuildEvent> stuff. It'd try to copy the generated dll to the game folder. Maybe just remove that part. Edit SDLController.cs: Replace the line SDL.SDL_PollEvent(out ev); with this: SDL.SDL_PumpEvents(); The reason is that recent Unity versions use SDL for input handling (at least on Linux), so advanced fly-by-wire mustn't consume the input event. The value given back by PollEvent() has not been used anyhow, so obviously the call was only there to cause population of the event queue. xbuild /property:Configuration=Release ksp-advanced-flybywire-linux.csproj That should create a subfolder "obj", which should contain the new Advanced Fly-By-Wire dll file. Replace the ksp-advanced-flybywire.dll in your GameData/ksp-advanced-flybywire with the newly built file. Use the toolbar in a flight scene to set up your input and enjoy joystick/gamepad support in KSP 1.4. Edit: I've just seen that @linuxgurugamer has forked the Advanced Fly-By-Wire repo with an additional patch so it does not require Toolbar. I haven't tried to build that one though. Edit2: I've also opened a pull request on Github containing this one line code change. Edit 3: I tried to reach out to the author of Advanced Fly-By Wire (Alexander Dzhoganov) if he minds if I upload an updated .dll for 1.4.x, but didn't get a reply. Therefore I just assumed he won't mind, and upload the dll here. Installation is simple: Download the latest Advanced Fly-By-Wire release from Github and install it. Delete the toolbar folder. Get Toolbar Continued and install it. Then download my Advanced Fly-By-Wire dll for 1.4 and replace the dll from the official release. Read on. Edit 4: I just found out that the .dll file I uploaded in Edit 3 does not work with libsdl2-2.0.8 (and probably other versions as well...). I've only tested it with libsdl2-2.0.4, for which it seems to be working fine. I'll try to fix it so it works with libsdl2-2.0.8 too. Edit 5: Okay, I've got my Advanced Fly-By-Wire dll from Edit 3 working with libsdl2-2.0.8. Not by changing the source code, but by setting an environment variable. Let me explain: Unity is using SDL internally, yet for reasons beyond my understanding it is not linked dynamically against the system installed libsdl2, but instead uses static linking for this lib. That's usually fine, but if mods try to load the system installed SDL2 version, incompatibilities might arise. Anyhow, luckily the SDL developers are aware of this problem, and offer a solution. So, all one has to do to get the mod working on systems with a newer libsdl2 version is to set the SDL_DYNAMIC_API=<Path_To_libsdl2.so> environment variable. In other words, I now run my KSP install with following command line: SDL_DYNAMIC_API=/usr/lib64/libSDL2.so LC_ALL=C ./KSP.x86_64

Well, there are two issues. Issue #1: If your input device is not a gamepad (or not recognized by SDL to be one), KSP will not recognize it at all. No buttons or axes work. Issue #2: If your input device is recognized by SDL as a gamepad (or you are using the environment variable that maps it to a gamepad layout), buttons work just fine. Axes however cannot be assigned. They are shown in the assignment dialogue, and are stored to settings.cfg for the respective control-axis (e.g. AXIS_YAW), but are not shown directly in the input settings UI and are not usable ingame. Furthermore, the INPUT_DEVICES block in settings.cfg remains emtpy.

I've been trying to get my Wiimote Classic Controller to work with KSP 1.4, to no avail. The PS4 controller works out of the box though... Edit: Well, the buttons on the PS4 controller work. The axis are shown in settings, but do not work ingame (and no, dead zone isn't set to 1).

I'll handle 1.4 the same as the last few updates. I'll give it a try, and stop playing when I finally get too annoyed by the lack of FAR (usually half an hour into the game). Once FAR is updated, I'll start a new carreer, and play like an addict.

Yep, most savegames get abandoned due to what players call "FPS death". In the Dwarf Fortress case FPS does not denote graphics frames, but simulation steps per second. Over time savegames tend to get more and more complex (mostly because the player creates a large number of items, more dwarfs move in, animals breed,...), causing the game to run slower and slower, until at some point it stops being fun, as the player has to wait longer for tasks to be fulfilled... Dwarf Fortress is not only CPU-bound though. Another limiting factor is memory speed, as the game needs to access more memory every frame than what fits into the CPU cache. On my new Ryzen machine the CPU does not even clock to XFR frequencies when playing Dwarf Fortress, as it spends a lot of time waiting for data from RAM...

KSP will run perfectly fine on an FX-whatever. Nevertheless, one can run into issues with modded installs, as KSP and most of its mods do the vast majority of their logic in the game thread, and current FX-processors are based on the Bulldozer (and derived) CPU architecture, which is optimized for multithreaded workloads (not that KSP wouldn't be multithreaded, but it's bottlenecked by one of the threads, so effectively the single-thread performance of the CPU counts). For workloads such as KSP probably even a $50 Skylake Pentium will show better performance than any current AMD FX CPU. KSP was one reason for me to retire my old FX-6350 system in favor of a new shiny Ryzen machine, as Ryzen offers far superior single-thread performance (though not as good as Coffee Lake, but that one wasn't out at the time I bought the new system). The other reason was Dwarf Fortress, which is also mostly bottlenecked by one thread.

I'm playing KSP on Gentoo Linux, using the Xfce desktop environment. Reasons for that choice: I enjoy running Gentoo, and like how (relatively) lightweight Xfce is.

Regarding the photosynthesis topic, there's a nice xkcd What If: https://what-if.xkcd.com/17/

I wouldn't speak of a bottleneck, as long as your timer stays green without physics warp. Most players will have a yellow/red timer during physics warp, also if no mods are installed. Your GPU is upper middle class nowadays, the HD 7870 GHz Edition is (nearly) identical to the R9 370X, and the HD 7870 XT is even slightly faster than that. From my experience EVE causes quite some CPU load (maybe, if I get extremely bored, I might profile it one day...), and most visual mods have EVE as a dependency. For that reason I would not automatically assume that upgrading your GPU will yield green time display during high physics warp when EVE is installed, though it will certainly help.

As always, the Wiki has you covered: http://wiki.kerbalspaceprogram.com/wiki/Tutorial:Creating_your_first_module

If you think mods in general aren't balanced, then you haven't yet looked at the right mods. There are plenty of them that actually increase the difficulty of the game. But back on topic: I'd happily pay for a different progression system. One that's still challenging, but doesn't require the player to do the same task over and over again ("grinding") to get funds.

My landers typically don't have any additional monopropellant. For landing I usually don't need any RCS, and for docking back to the orbit module, the 15 units monopropellant in the Mk1 lander can are just the right amount.

I also think this is not a good idea, at least not unless there is an option to automatically take care of it. One could imagine a button that enables "automatic decay correction burns", which will require your orbiting craft to be maneuverable (engines + fuel), and will then consume a tiny amount of fuel over time to keep the orbit stable. Also, there's a mod for that:

Nope. I mixed up something yesterday. Today, at work, I could look it up, and it's the ReSharper plugin "Heap Allocations Viewer".