Sethur

I don't know if anybody else noticed, but since 1.1, there is one more important reason to get Soundtrack Editor working again and that is the general state of the KSP background music after the big Unity 5 update: Apparently, something went terribly wrong with the way background music was compressed in 1.1 or alternatively the way it is played back in Unity 5, because since 1.1 (including 1.1.1 and 1.1.2), all tracks sound washed out and artifacted. It's especially noticeable in the theme music on the initial menu screen. My guess is that everything was compressed with a much too low bandwith, something around 64 kbps, but I can't be sure. Anyway, this drives me crazy during actual gameplay, because once you have heard it, you cannot unhear it and in its current state the music now just sounds broken to me. So this mod would be the perfect way of both getting rid of this issue and introducing an even nicer auditive backdrop. PS: I already tried to extract the old music from the sharedassets files and replace the music in the new version with the extracted one, but unfortunately, I didn't succeed.The above described issues have been reported here: http://bugs.kerbalspaceprogram.com/issues/7856 and again here (by me): http://bugs.kerbalspaceprogram.com/issues/9612

@GregroxMun: I think you're right with your suspicion that it's not only the music but the sound effects in general that are low quality, but I can't be sure there, could be nocebo. The music is definitely broken, though.

Since 1.1, the KSP theme song and most part of the background music seems to have been compressed to death, especially the theme songs sounds very washed out to me compared to 1.0.5. This has been reported on the bug tracker for the pre-release and I reported it again after the proper release here: http://bugs.kerbalspaceprogram.com/issues/9324 People also experiencing this issue should state so here and on the bug tracker to draw attention to this issue, otherwise a fix will be very low priority.

So I just found another weird issue that might stem from EVE 1.0.5-3. When I'm on the night side of Mun near my vessel and use the helmet lamp, I can't see the light on the ground any more. If I move away from the vessel sufficiently, it works. Not sure if this is connected with EVE, though. Screenshot below. Again, I'm on KSP 32bit, Windows, OpenGL EDIT: The light cone on the ground starts to reappear when I use the jet pack to hover over the ground (see second screenshot). It's not there at all when I'm standing directly on the ground, though. EDIT 2: Just tried this without EVE, still present, so it's definitely unrelated, sorry about that. [IMG]http://i.imgur.com/kLoDffs.png[/IMG] [IMG]http://i.imgur.com/m7PJzxH.png[/IMG]

[quote name='jlcarneiro']Hey, rbray89, your mod literally looks fantastic, thanks! I use 64-bit linux version (on nVidia) and no problems such the ocean on KSC. But the atmospheric planets show some kind of flickering. Firstly, I thought it was lightnings, but I decided to report it to you. I'm not sure what you need to report a glitch, but here are the log files and an animated gif. I used Duna, because I think its best viewed there... [SPOILER=The animated screenshot (let it load, please)][URL]http://i.imgur.com/Ird4LNm.gif[/URL][/SPOILER] [URL="http://www.filedropper.com/ksp"]The log file[/URL] Hope this is enough...[/QUOTE] This is exactly what I was seeing, but I was to lazy to generate a video. Thanks jlcarneiro. EDIT: I just checked: With 1.0.5-3 the flickering is gone on Kerbin, Duna and Laythe, but still present on Jool. It's also always at the intersection of the camera axis with the planet just as described by jlcarneiro.

Hi rbray, thanks for your great work. I'm on 1.0.5, 32bit, Windows with -force-opengl and -popupwindow and with the 1.0.5-2 release of EVE, I'm getting z-fighting/flickering issues when I'm in map view or in the tracking station view. Weirdly enough, I'm seeing clouds when I am in the tracking station, but only city lights when I am in the map view. The flickering issue is, however, present in both views. I'm using an NVIDIA Geforce with up-to-date drivers. I'll include some time series screenshots of the z-fighting. You have to zoom in on the original pictures to see it, the compression here in the forum will make the artifacts almost disappear. It's very clearly visible though when in-game. [IMG]https://www.dropbox.com/s/spurv5vtpr4i32s/screenshot1.jpg?dl=1[/IMG] [IMG]https://www.dropbox.com/s/spurv5vtpr4i32s/screenshot1.jpg?dl=1[/IMG]

Another update on this: Changing HKEY_CURRENT_USER\Software\SQUAD\Kerbal Space Program\"Screenmanager Is Fullscreen mode_h3981298716" from 0 to 1 had the effect that the KSP loading window was at least showing, but the crash still happened immediately after.

Hi Shadowmage. So you are suggesting that inverting the value of: HKEY_CURRENT_USER\Software\SQUAD\Kerbal Space Program\"Screenmanager Is Fullscreen mode_h3981298716" will fix this problem? That would be a very strange fix, but I'll try as soon as I fire up my projector the next time. - - - Updated - - - KSP might not officially support OpenGL, but since it also doesn't provide/support x64-builds for Windows any longer (and never ones that actually worked), a large part of the more ambitious player base is practically forced to use OpenGL or at least ATM in aggressive mode to get around the 3.5G RAM limitation. My current modded 1.0.4. install doesn't even have a lot of expensive mods installed, Astronomers Pack with a decent SkyBox is enough to push you over the limit. So what I'm saying is that SQUAD cannot just ignore OpenGL not working properly any more in 1.0.x and blame everything on Unity, since a lot of Windows players (which are definitely the majority) have no real alternative if they want to use mods, and KSP is all about using mods. It was also working flawlessly with previous Unity versions, and it still does when your display is connected via DVI, so it's probably not very hard to get this working again. SQUAD and the Unity devs could easily collaborate on fixing the issue. - - - Updated - - - Update: I found somebody mentioning this very bug on the Unity forums. Apparently it has been around for longer and in this case it only happened when you switch resolution right away. http://forum.unity3d.com/threads/couldnt-switch-to-requested-monitor-resolution.150771/

Has there been any update on this? I am also suffering from this issue, which prevents me from playing KSP 1.0.4 (or any other version >= 1.0) on my HDMI connected projector with -force-opengl and a resolution (native) of 1920x1080. With 0.90 and previous versions, everything was working fine. The above mentioned "-force-glcore" CLI switches don't work for me, OpenGL is not enabled and thus I am crashing at the 3.5 GB limit. This needs to get more attention, as it is cleary a bug introduced with a Unity update in KSP >1.0. As others have reported, I can play the game just fined with -force-opengl -popupwindow and max resolution (1920x1200) on my main monitor, which is connected via DVI.

Have the same problem, running with -force-opengl. Trying to role back, also opened up new issue on the github repo.

Thanks for the effort you put into this mod, it was high time that somebody tackled the reaction wheel issue!

I am very much in support of this idea, even the first option without the magical AM dissipation, but then again, I would also be in support of adding FAR-like aerodynamics to Stock, and this will probably never happen. Sure, going towards more realism would make KSP more difficult in most cases, but what's wrong about adding multiple levels of realism/difficulty between which players could easily switch. Don't like Newtonian Saturating Reaction Wheels? Well just go back to medium difficulty. Don't like flat spins with your fancy new hypersonic plane? Medium difficulty. Wanna work for SpaceX or NASA in the future? Go to legendary mode and turn everything on. This would also increase the challenge of doing many of the standard KSP achievements (first Mun landing, first successful docking, etc.) and as such the reward would be so much nicer. I don't get how people here are claiming that KSP is just a game, which shouldn't be too realistic. For me, KSP is as much about fun as it is about education (which is also fun, at least for me), and successfully completing a mission with maneuvers and crafts that are at least close to reality gives me so much more satisfaction than doing it in an environment where you could have won by operating your X-Box controller with one hand while slouching on the couch and eating chips with the other. I actually enjoy finding out how orbital mechanics work, how momentum preservation works, etc. For me, that's what makes KSP unique, what makes it standout before other space games. And yes, I would totally count it towards the simulation genre, although Squad tries to hide this between the cute green Kerbal environment, but it still is, and there is nothing wrong with that.

Thanks Vereox, I updated the tracker with my latest findings. Turns out I had another issue with clipping and missing ground on the old airfield island near the KSC, which made me suspicious. After long testing and uninstalling tons of mods (without the issue disappearing), it finally dawned on me that I was using an old settings.cfg from pre-0.90 times and did a comparison with the current stock config. Turns out that they apparently changed a line in the High Terrain Details preset that somehow determines how the ground is rendered. The clipping issue went away after I changed this and there is a good chance that this was also somehow connected with the Kraken, at least it's worth a try. Could anybody who was experiencing the Kraken report if they had the wrong entry in their respective settings.cfg? See below for a description and also see http://bugs.kerbalspaceprogram.com/issues/4128 and http://bugs.kerbalspaceprogram.com/issues/4134 The relevant part of my old (and apparently wrong) settings.cfg: PRESET { name = High PLANET { name = Kerbin minDistance = 8 minSubdivision = 1 maxSubdivision = 14 <--- This is 10 now for the High preset.

Did someone file this on the official squad bugtracker, yet? I did not take any screenshots, but Vereox could post it on: http://bugs.kerbalspaceprogram.com/projects/ksp/issues

Title Correction: "... catapults it into a random direction, often upwards, into the vacuum". Using "air" was just a manner of speech. KSP: 0.90.0 Windows 32bit with -popupwindow and -force-opengl Problem: Pondering wether I had the great honor to discover a completely new type of Kraken. I call it: The (Terrible) Underground Kraken On several occasions during my first 0.90 career run, crafts landed on the Mün would be violently tossed into the vacuum above, rapidly spinning and often immediately colliding with nearby rocky surfaces, causing catastrophic mission failures, rapid unplanned disassembles, frustration and sometimes hysterical laughter. The catapult action happens either when you switch to the landed craft or when you walk towards it with a Kerbal on EVA and come to a certain distance where the physics engine for the approached craft kicks in. The first time I witnessed this was on such an EVA mission, and it was truly a sight to behold for unsuspecting Jeb Kermin to see his only return vehicle rapidly taking of, spinning violently and seconds later exploding on the ground. One you have identified a vessel that struck the fancy of the Underground Kraken, the issue is reproducible every time. On the same EVA, I tried not walking back with Jeb but instead switching to the problematic vessel. When you do this, the physics engine is working heavily for a short while during loading (I think the timer is red, too), then the craft gets the same "donkey kick" as previously described, only this time one has a chance to safe the rapidly spinning craft if has not already exploded (the ejection angle seems to be quite random, sometimes you immediately explode, sometimes you get launched straight into the air). Mods are all on the current version. I uninstalled everything that I didn't need for the reproduction but the landers in the affected quicksaves kept on getting attacked by the Kraken. I even tried uninstalling some suspicious mods and playing out the same landing trajectory while my craft was still approaching the surface of Mün (height >= 15 km) and the issue would still persist. When you land and exit for EVA, nothing happens until you are out of physics range (few hundred meters). Then, when you walk back or switch to the craft: bäm! As far as I remember, I even tried putting the lander on its side, but to no avail. I initially though Mechjeb was the culprit because I was using Smart S.A.S. on the affected craft with KILL ROT enabled and I think I went out of electricity, but that wasn't it. Once I gave up on the such affected crafts, though, further mun landings went well until a certain point where it happened again, and so on. Now the most interesting thing: The logs show a negative height of you vessel just before the Kraken strikes (i.e. the physics engine goes crazy). I had with four different vessels now, all lite-weight and with relatively few parts, i.e. standard Mun landers with only one fuel tank and an LV-909 engine. I think I used the medium lander legs on all of those. Mods installed: Kerbal Engineer Redux Deadly Reentry Continued Quick Search Quick Scroll Ferram Aerospace Research (tried uninstalling) Mechjeb (tried uninstalling) Kerbal Joint Reinforcement Procedural Dynamics Procedural Fairings Active Texture Management Chatterer (tried uninstalling) Kerbal Attachment System (tried uninstalling) Reproduction steps: Hard to reproduce. Build a simple Mün lander with the medium stock landing legs, land, go on EVA, switch to your craft when you are far enough away. But I think the Kraken is quite insidious and intelligent, it only strikes when you don't expect him to do so and when you didn't quicksave before the deorbit burn Log: I don't have the exact logs here right now, but it show something of a negative height when the Kraken strikes.

Since I spent a few hours now trying to get this to work, I thought I'll try my luck with the forum: I'm currently attempting to rebuilt the FASA Saturn V with all required and recommended RO mods installed, but the order of modules around the CSM is very much different from the stock FASA Saturn V and I can't seem to figure out how to do this. In Stock KSP, the assembled LM is only (via a small decoupler) attached to the FairingPlateApollo375m, but this part does not exist in RO, instead you seem to need two parts, a Lunar Module Adapter Base and (below that) a Gemini 260" Payload Fairing (or similar). The problem is that there never seem to be enough nodes to attach everything correctly without the LM clipping into the CSM engine on top of it. Could somebody tell me the correct order of parts here? Or even better, point me to a finished craft file working in RO?

Hey fellow RO-players, since I spent a few hours now trying to get this to work, I thought I'll try my luck with the forum: I'm currently attempting to rebuilt the FASA Saturn V with all required and recommended RO mods installed, but the order of modules around the CSM is very much different from the stock FASA Saturn V and I can't seem to figure out how to do this. In Stock, the assembled LM is only (via a small decoupler) attached to the FairingPlateApollo375m, but this part does not exist in RO, instead you seem to need two parts, a Lunar Module Adapter Base and (below that) a Gemini 260" Payload Fairing (or similar). The problem is that there never seem to be enough nodes to attach everything correctly without the LM clipping into the CSM engine on top of it. Could somebody tell me the correct order of parts here? Or even better, point me to a finished craft file working in RO?