steve_v

Wow, that looks horrible. Surely having no shadows on the trees can't be any worse. I for one would rather have no shadows at all than that ugly mess.

Like the message says, your Video card is out of memory. Try using your Nvidia chip rather than the on-die intel GPU. Because OpenGL uses less video RAM than DirectX. Again, see about setting KSP to use the Nvidia GPU.

A: Buy an off the shelf IP PBX box. B: Set up a server yourself, for which you will want to learn Asterisk. If you only need local calls, and no integration with existing phone lines, there are many LAN chat applications that can do voice+video.

It works with the last version of SVE on CKAN (1.1.6), and this solves my problem. Guess I''l be sticking with 1.1.6 until it's fixed. Why the latest is not on CKAN is another interesting question...

Far preferable to ugly artifacts IMO. A more comprehensive search of this (and the SVE) thread reveals that this has been around for quite some time... Any ETA on fixing it properly? Failing that, a "known issues" entry with a link to a "no cloud shadows" config would be nice. I found the dropbox link, but it did take some finding.

These ugly blocks of "shadow" on my landing gear, are they yours or scatterer?

If you're planning on modifying any Squad (or other mod) configs, MM is the only way to fly. Otherwise your mod will be incompatible with any other mod that uses those files, and a right pain to install. ModuleManager documentation is here, it mostly references part configs, but the same syntax applies to the tech tree. One can always ask Sarbian about anything not found in the docs.

I find this pretty immersion breaking, and frankly somewhat cheaty . How do I turn it off?

The solution to this problem is more practice (or mechjeb ). Docking with inline ports is exactly the same as standard ports, just set the port as the control point. Either use the classic two pairs of ports (perfectly aligned in the editor) method, or a little ModuleManager magic to make the ports angle snap, like so: This is, IIRC, the same stock mechanism that RDs konstruction ports use. Personally, I tend to put the docking port on the tail of my spaceplanes, between a pair of rapiers. My inteplanetary (nuke) engines go on the mothership, IMO they're too heavy to send down to the surface and back. It would be interesting to work out which approach is more efficient though, I like your concept.

You and everyone else that bought this disaster of a console port. Feel free to express you anger at this unacceptably buggy release, and ridiculous ~8 month (and counting) wait for a patch. Everyone else sure has. Hopefully this will teach Squad why engaging a cheap and nasty porting house like Flying Tiger is a bad idea. These guys are utterly hopeless, and even a cursory glance at their portfolio reveals as much. Clearly price was more important than quality. Squad has since engaged a different outfit, hopefully one that actually has a clue. Patches sometime SoonTM. Current discussion can be found here.

Having some issue or other with my Mun rover - having completed a journey with BV (without issue), I re-docked used KAS to connect to a base to transfer supplies, un-docked and attempted to set a new course for the north pole. BV seems to be happy with my wheels and EC production, and it builds a path ok, but when I click "Bon Voyage" I get a "Bon Voyage!" in green on the screen but no "Control lock active" message, and the rover shows as "idle" in the BV control panel. Am I missing something in the latest version? I don't recall having this issue in the previous one... Inspecting the log reveals this output from BV: Exception handling event onNewGameLevelLoadRequestWasSanctionedAndActioned in class BonVoyage:System.IndexOutOfRangeException: Array index is out of range. at BonVoyage.LZString.decompressFromBase64 (System.String input) [0x00000] in <filename unknown>:0 (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) IndexOutOfRangeException: Array index is out of range. at BonVoyage.LZString.decompressFromBase64 (System.String input) [0x00000] in <filename unknown>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(GameScenes) :MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) I have a fair few other mods installed, and many of them have new, untested (by me) updates as I haven't played KSP in a while. Thoughts? Ed: If I go back to the Tracking Station, this rover doesn't show up in the BV control panel at all - the vehicle in question is a fairly basic Malemute, if it matters. Ed.2: The error mentioned occurs at game load, on entering the space centre scene. Mods: Log: (post loading vessel & attempting to start BV) https://www.dropbox.com/s/9u7qpv5jpt8gt2d/Player.log.gz Ed.3: I had Jeb EVA from the vessel, then switched back to it, and now the "Control lock active" message appears and BV works normally... even after Jeb re-boards. Most curious. Guess we could call it a "transient anomaly"?

You are activating the (EC eating) habitats on those cupolas and hitchhikers, right?

Indeed, I purchased it as soon as a GNU/Linux build was available, and I've been waiting 3+ years for respectable performance. If I knew it would still be stalling every 10 seconds and struggling to maintain two-digit FPS at 250 parts by version 1.2, I would have spent my money on something else. I don't want to pay for it either, but if a paid DLC is the incentive needed for Squad to fix the game, so be it. Patches and updates clearly aren't cutting it, as the game still runs like slapped-together proof-of-concept tech demo. Enough with the pathetic framerates and constant GC stutter already. I don't want to see any more content until the game runs properly. But this is obviously straying off-topic, so I'll leave it at that.

Well, I'd happily pay for a better game engine as a DLC.

Indeed, quality/quantity.

You are running the 1.2.2 compatible version of KER, which suggests you are running KSP 1.2.x, for which there is no FAR release. If you are, as I suspect, running the unreleased development build, bug reports belong on github. And what we have here is a properly useless bug report anyway.

That's a long list, with some pretty concerning items. I have considered Microsoft Windows malware/spyware for some time... Now I'm completely sure. More detailed reading suggests you're probably ok on "Basic"... If you trust Microsoft. Then again, IMO "trust Microsoft" is an oxymoron. BTW, those two links point at the same URL.

Squad appears to be utterly disinterested in getting their hands dirty in (or swapping out) the physics engine, or anything else that's not "out of the box" Unity. They also appear to be committed to this "part based" rigid-body physics, which runs like ..... in unity's "out of the box" physics engine. Therefore we are stuck with this shoddy performance until Unity sorts out their game engine, if they ever do. Don't hold your breath for a Unity fix either, Unity was designed to be cheap and easy to work with, and most games that use it are FPS or RPGs with minimal physics requirements. Abusing the physics engine like KSP does is not a priority.

My sole idea for EP[x]: Better performance (physics + runtime GC). Everything else is secondary (except bugs of course).

Almost certainly. If it continues, you may be able to get your carrier to block the number.

The problem is the ancient (and lacking GPU acceleration) physx in Unity. As usual. Changing graphics settings (or running the x64 player) will make little to no difference. CPU speed is everything, but you have a 6850K already, so you're pretty much SOL there unless you want to play with liquid nitrogen and insane overclocking. KSP performance scales extremely poorly with part count, due to the physics engine. There's pretty much nothing you can do about it except reduce part count (or the same through part-welding mods). Once you've been playing for a while, part-count minimisation becomes the primary design criteria for any craft. Forget about mass efficiency, redundancy or price. Reduce part count at all costs. Fun isn't it? This game starts running like a gut-shot pig, even on a top-of-the-line PC, once you get over 250 or so parts on a single vessel. IMO this makes the 255 -> unlimited parts upgrade for the VAB/SPH something of a bad joke. GPU physx please Squad, or more intelligence in the "part centric" physics model. Rigid joints, for example, don't need to be calculated every frame and could be considered a single part below a set force threshold. Something needs to be done here, horrible framerates are too high a price to pay for rockets that bend like wet noodles. Even after the "turbo charged" (yeah, right) update, performance is still appallingly bad.

This sounds a whole lot like the repulsors in KerbalFoundries2, using KSPWheel rather than the stock module. Might be worth looking at adapting this code, and/or asking @Shadowmage re. tweaking it for your idea. Could save reinventing the wheel, so to speak.

That's not nearly enough information to troubleshoot a toaster remotely, let alone a PC... If you really want help, and can provide more details, you may want to open your own thread as your request is likely to get swamped in here.

It's a secret, to keep the noise down. I'll give you one hint: github. If you do find it, and you know what to do with it, please don't post bugs here - instead use the github bugtracker.

I don't see anything obvious there, but then I see you are running MS Windows... I'm not particularly familiar with Windows stack traces as I don't use it. Some thoughts: It's crashing when you try to enter the editor, or right at the end of the loading process, no? Does a clean (unmodded) KSP crash? (copy your install to some other location, re-install, test.) It doesn't look like an out-of-memory situation, but just to be sure: Are you running the 64bit executable? How much physical RAM do you have?