soulsource

What's wrong with having a mouse cursor on the PS4? There's a touchpad on the controller, and it wouldn't make much sense imho to artificially disable mouse input even though the hardware is there. Edit: What's more interesting for me would be mod support. I'd really like to also buy the PS4 version, but playing without FAR is just not the same...

I'm doing this with my mining station on Minmus. It's pretty easy in low gravity environment, but I guess it's much more difficult on high gravity objects. My strategy is as follows: Try to get on top of your target already at high altitude (navball - target indicator is your friend) Stop your horizontal velocity wrt the surface already high up use both hands on the keyboard. WASDQE for rotation, IJKLHN for translation (RCS is a must...) Main throttle should be used to keep your craft hovering Beware of engine exhaust. That stuff is hot. I use radial engines mounted far away from the docking port for that reason.

The ideal gravity turn starts just above the pad and ends exactly at the altitude of your desired orbit. My strategy for a gravity turn is usually to have a TWR of 1.5 for the bottom stage at the launch pad, then go straight up until about 50 m/s (so that aerodynamic forces get strong enough to stabilize the craft), and then give the rocket a (very) slight push towards east. From that point on, aero should keep the rocket nearly prograde, with it slightly tilting towards the horizon by itself. Stages above the bottom stage tend to have an initial TWR of 1.0 in my craft designs, so the rocket should already have a decent angle when decoupling the bottom stage, so that the dV of the upper stages isn't wasted in gravity losses. This of course only works for aerodynamically stable rockets, meaning that their center of drag is behind the center of mass.

The thing you are missing is probably thread synchronization. Programmers typically code (at least) one management thread, that keeps track of which threads are running, and at certain predefined points waits for all threads to reach a predefined checkpoint. For games this would typically happen before a frame is being drawn. Programmers also have tools available to manage data access of threads, to make sure threads don't operate on the same data simultaneously (as that would be bad™ - it's called a race condition, or, in case thread A is waiting for thread B to finish working on data, while thread B is waiting for thread A to finish, it's called a deadlock). This is what should make threads work (be it multi-processor, or hyperthreading, or whatnot). I've intentionally written that programmers have the tools available, because, as always, there's the not too small chance of human error, and thread timing errors are particularly hard to find, as already reproducing them might be a huge pain. There's actually a pretty fun browser game, where the player has to try to cause deadlocks and/or race conditions by manually stepping through buggy multi-threaded code. It's called Deadlock Empire. That being said, the multi-threaded physics of KSP 1.1 is below the level that game developers (typically) work on. It's part of nVidia PhysX, which is pretty much a black-box that might work, or might not work (*cough* wheels *cough*). If the devs didn't invest a huge amount of time to work around Unity (which expects all scripts to be single-threaded), they probably don't have much self-written multi-threaded code in KSP.

I just have to post something in defence of the ant: This is what I've been using for most of my trips to Minmus in my current save. It costs altogether 31056 roots, of which 10879 are meant to return to and land on Kerbin, so if the landing isn't too far away from the KSC, the whole trip to Minmus including possible biome-hopping costs about 22000 roots. Scientific equipment includes one Mystery Goo container, a Science Jr., a seismo-, and a thermometer. And yes, the lander engines are ants.

Nothing wrong with that. it actually shows that people are smart enough to use the search function to check if there is already a thread about a certain topic before opening dozens of threads for the same topic.

They are in CIL, which is platform independent. I see a different challenge for modders: Building their mods against the console version of KSP might be difficult, as they'd need access to the dll files shipped with the console version, in order to build their plugins against them...

0.19.1a seems to work fine for me on KSP 1.1.3, but I haven't tested it much yet.

If you want to get an idea of how complex it is to implement dV readout for an arbitrary vessel, feel free to have a look at the KER source code, more precisely at the VesselSimulator. Also, please consider, that while KER is pretty good at dV calculation, it still fails now and then for particularly convoluted craft designs (what's perfectly find for a mod, but would cause dozens of flame-threads in this forum if it were stock)... Sadly, this means that without mods you have to calculate dV manually using the mass readout of the VAB. For each stage, you can write down the mass with full, and empty fuel tanks (right click menu of the tanks...), and the input this, together with the Isp of the stage's engines in the rocket equation. Just don't forget to set the tanks to full afterwards, or you might have a nasty surprise...

Forget "patching" the crash bugs. If KSP crashes with the "has stopped working" message, it's quite a safe bet to say that it's caused by the Unity engine, not by KSP (of course also KSP could lead to such crashes, but those should be handled by the Mono runtime of Unity, not by Windows). And that's where the problems start... Unity support will likely tell the KSP developers to update to the latest Unity version, especially since a known crash bug of Unity 5.2.x (and 5.1.x) has been fixed with Unity 5.3... The other option would be to get the fix for that bug backported to a previous Unity version, but having the Unity developers do this is somewhere between "quite costly" and "we don't do custom builds of earlier versions"... Edit: There would of course be the tiny chance, that although it's very likely a Unity bug, it might eventually be worked around by not using the buggy functionality of Unity. But that depends on where exactly the bug is within Unity. If it's at an easy to find API maybe it can be avoided. If it's somewhere deep within Unity itself, then, well, see above.

The random crashes are probably caused by bugs in Unity. Unless KSP gets ported to Unity 5.3 chances are slim that it's possible to fix them...

My tourist trip to Duna and Ike finally arrived. I've gotten better at estimating fuel usage for landings on bodies with atmosphere: The lander was just barely able to reach orbit and synchronize it with the mothership.Anyhow, if main engine fuel would have run out, they would still have had more than enough fuel for thrusters left, as an emergency measure.

Ok, so we should likely stick to 1.1 until those hotfixes are out.

I've had a store-bought PC constantly reach 95°C CPU temperature. When I tried to replace the heatsink I figured that the person who assembled it forgot to peel off the plastic foil that protects the thermal pad of the heatsink from dust before mounting, so that there was a pretty good thermal insulation between CPU and heatsink... But back on topic: Modern mobile CPUs and GPUs have a so called thermal budget they will not exceed. Instead they will reduce clock rate in such a case. On the other hand the laptop manufacturers should design the cooling system of the laptop in such a way, that it can accommodate the thermal budget of the CPU/GPU. This means, that if your laptop isn't broken by design it shouldn't be possible to damage it by overheating as long as you don't block the ventilation slots and there is no dust inside. Even in such a case your CPU/GPU should still be save, as they have thermal sensors included that should also cause them to reduce clock rate in case dangerous temperatures are being detected. Again, this doesn't help on broken by design laptops, where instead of the CPU/GPU parts the mainboard, or even the laptop case might be damaged. A friend of me had a [brand censored] laptop once, where the back cover was literally melting when playing games - so he had to get an external cooling stand to make the "gaming" laptop usable.

There's a semi-working port of KAC available for 1.1, made by Fishbreath that you could use until the official version is released: The file can be found here: https://github.com/jslater89/KerbalAlarmClock/releases Back on topic: I'd like to have stock dV readouts, as given by KER, but KER itself is imho a little bit too heavy. Personally I prefer VOID (which is using the vessel simulator code of KER). What I'd also like to see in stock would be KAC (obviously), and hopefully at some point aerodynamics that are on par with FAR.

Update: I accidentally confirmed that it's easily possible to go sub-orbital on the sun without needing the infinite fuel cheat. Yesterday I tested if the cooling system of my Eeloo ship still works in 1.1 (it does), by just burning all its fuel in a random direction. The ship was already close to Eeloo when I did this, and as it was still on a Hohmann transfer from Kerbin, so it had an orbital velocity of approximately 3300 m/s. I didn't even think about the sun at that point, so you can imagine I was quite surprised when the camera suddenly started to move and I got a "World's First" message... I think I'll try to build a sun-diver in sandbox now, just to see how bad the heat is.

I discovered a workaround that makes KSP 1.1 playable with the screen's native resolution or in windowed mode on Linux (see the corresponding bug report), but causes graphics glitches if shadow cascades isn't set to zero (at least while the game starts - it can be increased in the pause menu later, but then also minor glitches appear, yet by far not as bad as those appearing if one has shadow cascades on when starting the game). Once I had 1.1 running at an acceptable resolution, I copied together development snapshots of various mods I've been using in 1.0.5 (all of them work more or less on 1.1 now, even those that aren't officially released yet), copied my savegame from 1.0.5, and realized that 1.1 is performing not only well, but amazingly well. With that realization I tried to get Scatterer and EnvironmentalVisualEnhancements running - the former with more or less success (the lines in the sky, that should have been fixed already are back with the new OpenGL renderer of Unity...), the latter with glitches all over - EVE's RGBA cube map reader obviously doesn't like the new OpenGL renderer of Unity and I'm too lazy to debug that right now... Anyhow, after messing with graphics enhancement mods for hours and hours, I finally gave up and am now back to the plain old stock look of the Kerbol system. Given that 1.0.5 wasn't performant enough to let me run EVE on my slightly old PC, I still count this as an improvement, as on 1.1 only my biggest station stutters, while all the rest of my crafts are now showing a green clock all the time. Funny enough, although I spent hours with KSP, I didn't really play it...

I've been playing 1.0.* for quite a while with quickloading disabled. That didn't stop me from quicksaving regularly though, what really came in handy when bugs in KSP's thermal system started to cause random explosions, especially in combination with FAR... On the other hand it's then really, really tempting to just load the last quicksave if something goes wrong, and I did exactly that after I managed to crash on Duna due to a particularly stupid mistake during landing... In my opinion KSP without mods is also too hardimpossible to play, as there is a severe lack of information regarding aerodynamic stability before you actually launch a craft. FAR is imho a must have if one tries to play without quickoading and reverting.

@sal_vager I've found out something else about the shadow issues with -force-glcore: If I have shadow cascades set to zero when I launch KSP, I can later increase that value to two or even four using the pause-menu with only minor glitches appearing. However I have to set it back to zero before exiting KSP, as, if KSP loads with shadow cascades set to two or four and -force-glcore enabled, quite severe glitches occur. I do have the impression though, that shadows are of a lower quality if one enables shadow cascades after game launch, than if one loads the game with shadow cascades enabled already. The perceived resolution of the closest shadow map seems to be rather low in that case, but still far better than if using no shadow cascades at all. While I don't know if this is possible with Unity, I'd guess that KSP sets a custom distance at which the engine should switch between shadow maps at game load (if cascades are enabled), but doesn't set it when changing the shadow cascades setting using the pause menu.

Maybe the problem is caused by Unity3D trying to figure out the desktop's size and failing to do so. If that's the case, it might help to un-maximize the KSP window and give it a fixed size in the settings menu. How to do that is a bit arcane currently, as Unity3D disables all window resizing controls of the window manager... Maybe the following procedure works for you though: KSP stores the state of the program window in "~/.config/unity3d/Squad/Kerbal Space Program/prefs" (or similar, I'm not at home right now, so I cannot check). The default values are obviously not usable (as: maximized KSP window with no way to change it), but once one gets windowed mode working properly, I think it will stay working until that file is changed. So, what I'd suggest would be to either: ask someone who has a working windowed mode prefs file to send you a copy of it (if I don't forget, I'll update this post later with a link to mine), or switch (temporarily) to another window manager (Xfce with disabled compositing works for me), delete said file, delete settings.cfg (or rename it - just let KSP run once with the default settings) and launch KSP (if you get empty menus, use -force-glcore). At least for me KSP then started in maximized window state, with no option to resize the window and the resolution option in the settings being ineffective. In order to get some control over the window size (and maybe get KSP working on KDE), start or load a game, open the pause menu, go to settings, change the value for anti-aliasing, and press apply. I think changing anti-aliasing forces Unity to request a new GL context, but I'm not certain. Anyhow, after changing anti-aliasing, the window should be redrawn, and (at least for me) this caused Unity to resize the window from maximized to normal. I'm not sure if now the resolution controls in the settings menu work immediately, or if you have to restart KSP to get them working, but as soon as you changed resolution in the settings once and restarted KSP twice, it should always open a window of exactly the specified size - hopefully also on KDE.

Would you mind to elaborate what exactly is the issue? Does KSP crash when it reaches 4GB of RAM? Are you stuck on the loading screen?

While there still are some glitches, launching KSP with the "-force-glcore" command line option makes the UI work regardless of resolution and also in windowed mode. This command line switch enables the "New OpenGL Renderer" of unity, as described in the "So, how can I use it?" section of http://blogs.unity3d.com/2015/05/26/dx11-features-on-mobile/ and the "Other Improvements" section of https://unity3d.com/unity/whats-new/unity-5.2 At least with my graphics drivers, radeonsi, the new renderer has issues with shadows, but setting shadow cascades to zero improves the situation quite a bit.

May I ask: Which AMD driver? The recommended open source drivers, the workstation AMD GPU Pro driver, or the outdated, no longer maintained fglrx?

This is a known bug. There are currently two known workarounds, both with their own ugliness: You can edit settings.cfg in a text editor. Enable fullscreen mode and set a resolution lower than the native resolution of your screen. You can launch KSP with the -force-glcore command line parameter. This will allow KSP to run in your screen's native resolution with working menus, but this option will cause graphics glitches regarding shadows and in some menus. In Steam this can be done by right clicking the entry in the Steam library, open properties, and pressing the "set launch options" button. In the dialogue that pops up, you can enter "%command% -force-glcore" (without the quotation marks, of course). Edit: It seems that the worst shadow-glitches that appear with -force-glcore can be made invisible by setting shadow cascades to zero. I'm aware that this makes shadows pretty rough, but I prefer rough shadows over shadows of things that aren't even there.

I time warped until a transfer window to Jool opened, and sent off two probes and a crewed ship. The probes are for Tylo and Jool, the ship is going to Laythe. The probe for Jool is meant to dive into its atmosphere, send back some science data (not that I'd need it any more...), and then explode at some point. Maybe I'll even install some visuals mods especially for this occasion, although my PC has a hard time handling those... The probe for Tylo is my first attempt to land there. I was thinking about a crewed mission, but in the end I didn't want to risk my Kerbals' lifes in a mission with such uncertain outcome. Anyhow, it was really fun to design the Laythe mission. First, I realized that my calculation of the dV requirements for going directly into a moon's SOI without circularizing around its parent body first was quite a bit off, so I fixed the formulas, and now going to the Joolian moons doesn't look as frightening as it did before. The single-launch ship including lander became quite a behemoth still, so I (again) switched difficulty options to allow reverting. I needed it, as the craft had a horrible tendency to spontaneously disassemble when the physics engine kicks in, until I added more launch clamps, and took care to make my ship not only have a four-fold rotation symmetry, but also to have two mirror planes... Now all three crafts are on their way to Jool. Ah, and KSP nearly ruined my mission to Eeloo. After sending off my crafts to Jool I realized that there was a ship in Jool's SOI though the only craft I had sent there up to now was orbiting Pol. It turned out to be my crewed ship heading for Eeloo. KSP didn't show the Jool encounter on the map when I last had that vessel active, so obviously, now that it indeed did have an encounter, the unplanned "gravity assist" of Jool messed up my carefully planned trajectory... Good though, that a burn of just about 50 m/s will fix this again, but if I hadn't realized, the ship would have missed Eeloo by quite a bit...