angelatthetomb

I have a Master's degree in Workspace Operating Mode Bewilderment Attenuation Technology, and I have no idea what workspaces are for or how to use them.

What's needed is threefold: -Ability to see orbits propagating into different SoIs as they are adjusted (I'm 100% sure they'll fix this). -A way to observe orbital parameters changing live as you adjust the node, with numbers and not just visuals. A popup "orbital parameters after maneuver" window would be best, so that you don't have to look at the actual location of whatever parameter you're interested in. Bonus points if it includes parameters after an SoI change (i.e., shows you Mun periapsis even though the node is in Kerbin periapsis - KSP 1 never got this). Less confident this will happen. -A method to adjust the maneuver node without looking at it. Best solution: a "maneuver node editor" that is not as ugly and finicky as KSP 1. It should appear near the lower-center of the screen (where there's some convenient dead space) and should have a large-scale maneuver node widget as part of the UI. This gives you a duplicate of the maneuver node widget that exists in the world, but is in a fixed location, easily accessible, and always available whenever you're in map mode with a maneuver node. The layout of the SAS hold axes widget provides a useful analogue. Above or to the right should be numerical input options.

Even camera people don't use those terms (source: am a professional camera operator). We don't "dolly" in or out, we "track" in or out or left or right (because dollies run on tracks, see?) "Pan" to track annoys me as a pedant, but I know a lot of software uses it that way, and especially in a game aimed at kids it's fine. As far as units, I'm all for getting the units as correct as possible. km, Wh (I know engineers prefer Ah, but since there's no voltages in KSP but there is power, Wh makes more sense at some magical hidden voltage), Gs or m/s^2 but not both in the same context. I'd even go so far as to say kg instead of t (it's easier to think about a probe at 239kg and a rocket at 239,000kg than a probe at .239t and a rocket at 239t). I also really, really wish that, since we've named "Methane" we could name "Oxidizer." Why should the fuel be named but not the oxidizer? It's so weird.

This drives me insane too, anyone who has ever been around a military aircraft will see that and just say, "Uhhh something's not right here." It's very possible it's placeholder since there's no nozzle adjustment for throttle (which even stock KSP1 has). Practically, as well, the afterburner should be a "boost" to normal throttle (100-150% per cent or something), instead of a separate mode with a full range of throttle (why would you be at 5% afterburner? That just wastes fuel for less thrust than normal mode).

They'll figure it out. Noodly rockets were absolutely atrocious in pre-.2 KSP1 (ten years ago...Jesus I'm getting old...). These days I've forgotten entirely about that, don't even use autostrut, and my rockets don't wobble. Remember the part where it's an Alpha?

The tutorials are Very Kerbal. What would a tutorial look and sound like if it were made by Kerbals? Exactly like the example in Manley's video. It feels entirely authentic to the game world. OP is taking KSP too seriously. It's a game where you can do serious things, yes - I play with RealFuels and Kerbalism and DR and 2.7x OPM and all of the good stuff. Very science. Much hard. I still chuckle like an idiot when I screw up and everything explodes. I also keep an unmodded install to play with my 5-year old. We build some monstrous contraption and he tries to make the Kerbals take their helmets off in space or jump out in the middle of reentry. We both chuckle like idiots when we screw up and everything explodes. The audience for KSP 2 is both of these experiences. One needs a tutorial. The other probably doesn't. It's a fun game. Let it be fun.

These additions look great, Lil_Bread. I'll be testing them out later tonight.

I'm 99% sure it's the Wenchang Launch Site by Icecovery: That's the only one I've ever seen with those pyramid towers like that.

In my experience, all the stock engines work fine. In my very heavily modded install, about 90% of the engines behave as expected. Most of the issues seem to be with BDB SRBs, some of which work fine, some of which behave very strangely. Some of the tanks don't work, either, especially tanks that use some sort of fuel switch - they usually override RF and you're left with a weird LH2/Oxidizer tank. I have a real Frankenstein install of custom fixes for engines I use a lot. I should really send them to Github, but I am too stupid for Github.

Thanks for making us aware, too bad. Another question: I'm having an issue with the HDD size increase unlocks in a heavily modded install. The "special" unlocks, contained in ScienceRework/Tweakables/StockHardDrives, work - these cores have expanded sizes after unlocking the requisite tech nodes. But nothing else does - it's all still at 2MB even after unlocking experimental electrics. Any advice for narrowing in on what might be causing this issue?

Does anyone know a way to get Strategia's "Science from New Biome" reward strategy, To Boldy Go, to work with Kerbalism? Because Kerbalism seems to intercept the science, Strategia never gives the reward, whether it's auto-science done through the Kerbalism window or the old-style science popup you get on some experiments.

It's not only possible but likely that I'm just an idiot, and have missed a setting or config somewhere.... But since updating to today's patch my antennas are consuming EC at baffling rates, even when not transmitting. Most of the starting probes go dead a few seconds after liftoff with even one antenna attached. The VAB also now shows two EC values, one for Idle and one for Transmitting. The Idle values are lower than the Transmit values, but still, kind of ridiculously high.

I'd love to try out the new version, Drakenex!

English isn't Hraban's first language, so he can come off a bit brusque sometimes. Contares really is amazing in its breadth, though. The quality is all over the place, but I have so many weird little gubbins and monstrosities fostered entirely by that *one* perfect Contares part found in a flash of inspiration. Put away the cattle prod. Give in.

Ha. I would NEVER suggest that the problem cannot be with KSP. I neglected to mention that after further tinkering around, the problem is not restricted to KSP. It seems to happen in any 3D OpenGL game I've tested under Linux, which so far is Cities: Skylines and Half-Life 2. Another wrinkle: last night I installed SteamOS since it has native GTX970 driver support, and lo and behold KSP (and the above games) now run flawlessly on SteamOS 64, even with enough mods to push 8GB of RAM usage. The stutter is gone completely. For me that sells it that there is some sort of issue between the nVidia drivers and some flavors of Linux. I have not tested any other Debian-based distros besides SteamOS, so it may be a Debian thing. Everything else I tried was Red Hat- or Ubuntu-derived. Who knows. Too bad SteamOS' desktop is so clunky...I am going to try LDME and see how that goes.

Well, that about sells it for me. It's definitely an nVidia issue (I find it almost impossible to believe it's the CPU, especially since there are no problems with the iGPU). I contacted nVidia support again. We'll see if I ever hear back.

Daverovski, what are your specs? I have been having awful Linux performance (stutters, as described, which get progressively worse the longer a ship is in-scene regardless of complexity, until it is ultimately unplayable). Mine IS a top-of-the-line system; 4790K, GTX970, 16GB, SSD. This happens in 64-bit and 32-bit, mods or no mods, but only in Linux. Windows performance is silky, silky smooth, until the inevitable memory-leak crash. My resources monitor shows the same dip you're seeing whenever the stutters hits. It seems to have approximately the same frequency, 5-8s, gradually becoming more frequent until after half an hour or so of flight it's hitting every 1-2 seconds. Not sure if this is significant or not, but on my multi-core system the resource dip/stutter also results in the process switching cores (i.e., if it's on core 3 before the dip, it will come back up after the dip on core 5 or 7, etc.) I have tried a million different things and none have worked. Different drivers (Nouveau vs nVidia proprietary), every single power management setting imaginable, all sorts of OpenGL force-driver hacks (including GPU_yield, which makes no difference), low-latency Kernels, three different Linux flavors, five or six different X servers. The X servers make a small difference in frequency of stutter, and these dips do not occur under any X server variant when running off the iGPU, leading me to believe it's related to the Nvidia driver talking to the X server. Of course, no response from Squad or Nvidia to official help requests and bug reports. If I ever hear back I'll let you know. If you hear anything, please let me know! Good luck.

Yeah, my quick ugly fix for that was just to copy EnrichedUranium and DepletedUranium at the end of the CRP .cfg and rename them U235rods and DepU235rods. Other than that it works great! RealFuels is so rad I started a new career now that it's usable.

FireFaced, I've been using it since yesterday. It seems to work rather well with the old .9 Stockalike engine packs. No major problems so far.

Thanks for the tip Peder, tried the oldest available Nvidia drivers that support the 970, issue still there. I've figured out the noise is "coil noise" from the capacitors, which occurs when the GPU is under extreme load. That gave me the idea to check my GPU temps and lo and behold, they're spiked too. GPU usage is at 100%. So is CPU. Something is making KSP use maximum available resources on a system that shouldn't shrug at it (and performs well under the iGPU at nowhere near maximum loads.) What could do that?

Here's a weird one.... Trying to run KSP on Linux Mint 17. Specs are GTX 970, i7 4790k 4.0ghz, 16gb RAM. The problem below occurs with three different nVidia-proprietary drivers (the Nouveau drivers don't support the 970). The first indication of something going wrong is randomly alternating pegged CPUs as soon as KSP starts loading. Watching in a CPU graph first CPU 1 will peg to 100%, then CPU 4, then CPU 7, or whatever, randomly. Seems to switch every three or four seconds. This continues through the loading process and in the game itself (main screen, menus, in flight, everywhere). This comes with pretty poor performance for this machine (random stutters and jitters even with a 3-part craft). It occurs at all graphics settings, with or without mods, x86 or x86_64, whatever. The same machine in Windows never gets CPU pegged from KSP; usually only using 20-25% of one core. What's scarier though is the sound the GPU starts to make as soon as the main screen loads. It's a high-pitched modulated whine or buzz. It's definitely not the fans; it cuts in and out and it sounds synthesized. It reminds me a little of old 56K modem noises. It's definitely coming from the GPU. Once I pull the 970 and switch to integrated graphics (and deinstall all the nVidia drivers), everything works great. I can load big ships with no lag at all, load it up with mods, no problems. As soon as I switch back to the 970 the CPU pegging and noise come back. I've never had problems with the card and never heard this sound anywhere but in KSP (including in Windows or in OS X). Other games run fine in Linux. Any ideas?