steve_v

You didn't miss much. To answer your question: That would probably be a good idea. KSP (1.10.1) starts normally if I pass -single-instance from an interactive shell... But I still can't launch it from CKAN with that particular argument. No visible segfault, all I get is: $ mono ./ckan.exe Found path: /home/steve/Games/KSP_linux/./KSP.x86_64 That line is from KSP/Unity IIRC, but I get no window, no KSP.x86_64 process, and no further output. I can't launch it from a bash script with -single-instance either, but this time I do get an obvious segfault: $ cat ./ksp.sh #!/bin/bash ./KSP.x86_64 -single-instance $ ./ksp.sh Set current directory to /home/steve/Games/KSP_linux Found path: /home/steve/Games/KSP_linux/KSP.x86_64 ./ksp.sh: line 2: 32303 Segmentation fault ./KSP.x86_64 -single-instance I'm not sure if mono/CKAN is eating stderr somehow and I'm just not seeing the segfault, but either way it looks like launching KSP on GNU/Linux with that particular argument is still broken. Aside, if you are eating stderr, could you please, uh, not? It's kinda important information.

Bugger. I kinda suspected that limitation was from mono rather than something explicit in CKAN, oh well. And mono apparently doesn't include such platform-specific functionality, even when compiled on and for that platform... Mildly disappointing, but not surprising. I know, that's my current workaround. It's annoying to have to remember not to just click ckan.exe from the file manager is all, passing vars in the launch command would be convenient. Ed. @TranceaddicT From the CKAN source code: // -single-instance crashes KSP 1.8 to KSP 1.9 on Linux // https://issuetracker.unity3d.com/issues/linux-segmentation-fault-when-running-a-built-project-with-single-instance-argument

Like I said (me and many others in this thread), spectra works just fine. It looks better than sci-fi IMO too, with similar performance. Suit yourself though. If you aren't going to explain how you installed it or post any logs, there's not much anyone can do to help you.

[snip] What I do have a use for is launching KSP with environment variables set, as such variables are used extensively for a great many things on POSIX systems, and have been since the 1980s. These cannot be set by command-line options to KSP, because KSP knows nothing about them - they're environment variables, that is setting up the environment in which KSP is launched. In my case, I need to set variables for mangohud (overlay), as well as pass some antialiasing and anisotropic filtering overrides to the graphics driver. I'd like to set LC_COLLATE to "en_US" too, so that save names are not sorted based on capitalisation. I can probably think of others that I might want, and none of them are accepted in CKANs as part of a launch command. In fact it appears to reject anything that doesn't start with a (single) literal filename. I have a similar script that uses symlinks to provide switchable mod sets, compresses and restores backups, etc. etc. (actually it's more like ~300 lines of me playing with bash arrays and universal wrapper functions for dialog, kdialog and zenity because I got bor... Okay, I admit, it's 95% utility functions I should split out into a library ). This script's purpose is to set up the game files and directory structure for both KSP and ckan, and it is intentionally a standalone tool. What if I want to just lazy-click "ckan.exe" from my GUI file manager? I'd need yet another shellscript just as a wrapper. CKAN not supporting environment variables in it's launch command is clearly the result of a "file exists" check, and one that I would personally consider redundant (and a windoze-ism to boot). Every other application I have installed supports setting environment when launching external commands (and other shell syntax, as is intuitive on a posix system), why not this one?

@HebaruSan How do I set environment variables when launching KSP from CKAN? Setting them in the "KSP command-line arguments" dialog as I would with any other "launch command" setting (steam, lutris, etc. etc.), e.g. 'LC_ALL=C ./KSP.x86_64' results in "Couldn't start KSP. Cannot find the specified file". I could certainly launch it via a shell script I suppose, but that seems kinda redundant if it's only purpose is to set an env var...

It works perfectly, I'm using it right now. Repeating your posts won't achieve anything either, read the "how to get support" sticky if you want support. What "installation video"? I see no installation video in the OP. I do see a recommendation to install via CKAN though... Mint mod BTW, and it doesn't even eat all my VRAM like AVP does

Updating to the latest patch because it's claimed to fix bugs introduced in the previous one, to discover that the only fixes were the lowest-hanging fruit, and a bunch of new bugs have appeared. Repeating this cycle ad-nauseam, since beta. Seeing all the hype about features nobody asked for, while the patch notes make no mention of bugs that people have been complaining about for years. Watching the GNU/Linux build get progressively slower and more broken with every update. Every single .0 release being horribly broken in some blindingly obvious way. Hotfixes for the broken .0 release that don't address all, or even the most annoying of the new bugs. Then silence until the next major patch, which breaks something else. Consecutive releases alternately fixing and breaking the same systems in different ways, repeatedly. Every second release breaking fairings, cargobays or aero occlusion. Trying to use wheels for anything since 1.1. Landed craft sliding around for no apparent reason. Orbital precision problems that have plagued the game since beta still not being fixed, and new orbital drift problems being introduced. Returning to craft to find them rendered useless by joints have been permanently displaced, then seeing the relevant bug report closed with wontfix "acknowledged".

Most games that run on GNU/Linux (or MacOS for that matter) natively perform just fine. Using OpenGL. A couple of very recent games I could mention run better on GNU/Linux than they do on Windows, using Vulkan. A large percentage of non-native games games these days run at almost windows-native framerates using DXVK. In fact, I'd go as far as to say KSP is the only game I've ever played which suffers from this problem... And it only becomes a problem when scatterer is installed. Go figure. Indeed. 1) Don't try to run scatterer on OpenGL, it tanks performance. 2) Don't bother asking blackrack why, he doesn't know and doesn't care.

I could say the same about people who expect me to set aside a few hundred gig of SSD and install a (pirated, 'cause I 'm sure not going to buy it) operating system I haven't used for decades, absent all the other software I use regularly, just for a single game. But that would lead to pointless arguments, now wouldn't it. When someone asks me a windows-centric question, I either do my best or shut my mouth. I don't say "Just use GNU/Linux", because that's not a reasonable answer. I kinda expect similar treatment TBH.

Wait, you're serious? I haven't used Windows for nearly 20 years, I'm not about to now. Okay then. All clean installs, settings.cfg copied, same test scene & craft, averaged & rounded to nearest 5FPS: KSP 1.8.1 stock: 140FPS KSP 1.8.1 + scatterer (0.0550-0.0621): 95FPS KSP 1.9.1 stock: 140FPS KSP 1.9.1 + scatterer (0.0550-0.0621): 95FPS KSP 1.10.1 stock: 130FPS KSP 1.10.1 + scatterer (0.0550-0.0621): 65FPS Conclusion: A performance regression occurred somewhere in the KSP 1.9.1-1.10.1 window. This is compounded (and not in a small way) by scatterer, regardless of scatterer version (or as far as 0.0550 - 0.0621 anyway). This is frankly not at all what I expected, and pretty much exonerates you as far as the cause of the regression. It's most likely Squads fault, somebody must have got all s/degraded/improved/g on the patch notes again. Nevertheless it makes scatterer nearly unusable on OpenGL, particularly in combination with other graphically intensive mods such as EVE. Given that a great many other applications perform just as well rendering with OpenGL as DirectX, I find this somewhat baffling - particularly as it does not appear to be using the full potential of the GPU. Regressions aside, and as cool as the mod is, a 50-60FPS performance tax for what scatter brings isn't a real great trade IMO. As for what version I was coming from, that would be 1.8.1 + 0.550. So the performance I was expecting was in the 90-100FPS range. That I can just about live with. 60 on the runway with a 15-part craft is a bit underwhelming to say the least. Ed. (scrolled up): That would indeed make sense, if KSP/Unity is doing all the render calls on the main thread it could well be CPU bound... Though why anyone would write a game engine that way in this day and age is beyond me. We did that kind of stuff in the '90s when GPUs were slow and polys few, but now? Why Unity, WHY?

And what exactly would you suggest I use then, considering that DirectX is Windows-only and Vulkan is not available in KSP? A great many other things, including KSP itself and scatterer up until a few releases ago, work just swimmingly with OpenGL. Something has clearly changed, and I'm pretty sure it's not the graphics API on my system.

FTFY. Option 2 of course. Wait, that was a trick question, right? Any "clever" anti-piracy "punishment" that looks like a bug will be assumed to be a bug, and while there might be some satisfaction for the easily amused when it gets reported as such, the vast majority of people (especially those who pirated the game) don't report bugs - they just go play something else. Anyone who does realise what's going on simply becomes a better pirate - they look at who uploaded the dodgy release and learn who to avoid. The cracking scene is very particular about quality, moreso than some game publishers. By including "anti-piracy" bugs in your game, you are helping them to release a superior product.

So, uh, about that performance thing... I mean, I get that improved graphics costing frames bit and all... But ~60FPS? Seriously? With no change in GPU load? Something fishy is going on here... No, I haven't changed any settings, that's a clean (1.10.1) install with only scatterer (v0.0621) and it's default config. Log. Thoughts?

How then do you propose to have creative anti-piracy measures without a way of detecting said piracy? Perhaps you intend that everyone would be subjected to craft "immediately exploding" or the rest of the suspiciously bug-like features you suggest? We have those already, they're called bugs. You posted this in the suggestions & development discussion forum, not the lounge, so one can only assume that it's intended as a potential feature in the game as opposed to just random theorycrafting. Such a feature would require some kind of DRM to implement, so it's pretty pointless to discuss one without the other.

A "fun thought exercise" is proposed on how to introduce something many here are strongly opposed to in the first place, and you expected a positive reaction? Really? Whatever the original intent, "anti-piracy methods" cannot be discussed without considering implementation, and that leads unavoidably to DRM. DRM, being the antithesis of "fun", leads to where we are now. The very first sentence in the OP is "Any good game needs anti-piracy measures". I for one consider that borderline flame-bait, and am not at all willing to engage in "fun" discussion on such a fundamentally flawed premise.

I can't imagine anyone who has been burned by StarForce or XCP would have much tolerance of any kind of DRM, yet the industry just keeps poisoning the well. Surely it must be obvious by now that consumers don't like rootkits and kernel-mode drivers, and yet we have Denuvo. Any faith I might have once had in software DRM is long gone, the bridge is ash. Vendors cannot be trusted, and I simply will not put up with it any more. I've been burned by online activation as well - if the use of goods (not services) that you paid for is later revoked by a licence server going down, that's flat-out fraud. You bought it, the seller relinquished control at point of sale, they don't get to remote-brick it. I might be inclined to tolerate physical media or dongle checks, assuming such media doesn't equate to planned obsolescence through wear and tear, or serial keys, assuming such can be recovered when inevitably lost... But nobody is using those. The game industry is still using is rootkits and online-only activation. So I'm still vehemently anti-DRM. For anyone claiming that software is rented rather than sold, and so always-online remote bricking is acceptable, you might benefit from reading this.

Unless you're talking about official first-party patches, which are IME rather rare, the problem is that in many jurisdictions (i.e. US Code 1201 and the infamous "anti circumvention clause" ), removing DRM or enabling others to do so is radioactively illegal. It's insane, it's morally indefensible, but that's how screwed up copyright law is. To add insult to injury, the only way to get many defective "AAA" titles to run in WINE on GNU/Linux is to circumvent the DRM...

Many developers and publishers (CD Projekt springs to mind) would disagree. The ~150 DRM free games I have purchased on GOG.com in the last few years would disagree. While considerably less obnoxious than most modern DRM, that's still punishing legitimate owners. Should legit customer have to rummage around looking for a manual whenever they want to play? They may have lost their hardcopy, what then? A pirate on the other hand will simply open that .nfo file they got with the download, or crack the game to remove the check altogether. Annoying and ineffective. Just like all DRM. Trying to make digital goods un-copyable or un-shareable is like trying to make water not-wet. Stop already, it's futile. The only anti-piracy measure I will accept is making a game worth buying. Treat me like a customer rather than an adversary, show me your real product instead of hype and trailers, and I'll quite probably give you money for it. Fail to release a demo or shareware version and I have no way to assess the product before purchase, so I'll probably assume the worst. Include spyware or malware and treat me like a criminal from day one, I'll go out of my way to not give you a cent. Whatever I refuse to spend on DRM infested games will go to the FSF and Defective By Design instead. WRT the game discussed here: If KSP had DRM, I would definitely not have bought it. If KSP was released by Take Two, with all their predatory behaviour and spyware, I almost certainly would not have bought it. If KSP had not released a demo, I probably would not have bought it. Squad, whatever their other faults, did at least release an honest game, and they treated their customers like human beings rather than presuming we're all a bunch of thieves. So I bought their game. Between the analytics, the EULA changes, and Take Two's massacre of Star Theory, my buying KSP2 is looking very unlikely at this point.

That one's not even maintenance, it's a flat-out entry-level regression introduced in 1.8. Not fixing these is either gross incompetence or a-grade apathy. It's not the usual "parachutes don't work" epic-level level QA fail either, basement-level functionality like settings actually being applied when the game starts up are things that should not break. I knew how to load settings from disk reliably when I was 12, how can this possibly be broken? Better yet, how can anyone think it's reasonable to leave it broken? I can only conclude that the official release procedure at SQUAD is to select 3 checkboxes, click "build", then shoot yourself in the head. I give up. I'm done. I've been waiting seven years and this amateurish garbage is still being shipped.

Awesome. Yay. Thanks for the half-resolution textures and unfixed 8 month old bug SQUAD. Good work, this is only the third update in a row (this time around) where you've failed to get the most basic features working. *Slow clap* Thought I'd check in on the latest update, but it's just more of the same not actually fixing things crap. Another .0 release, another bunch of new bugs, another 6 months waiting for the old ones to be completely ignored. Is it really so hard to save application settings these days or what? Oh, wait, it's SQUAD. They're just [snip] completely incapable of any engine-related programming. I'm going to go play something else now.

Then the problem is that your graphics card cooler is not working properly. For "This game overheats my <whatever>" support requests, the answer is always the same: Correctly functioning hardware should not overheat. Period. Regardless of what you try to play on it. It's not the game's fault if it does. Well it does meet the minimum system requirements, just, so it should run. It's not going to make for a particularly good experience though.

Fair enough, and quite correct. So much so that I quoted you just to make it clear that I was addressing getting steam installed as the main problem. I know, I know. I really should do the same. I've just wasted so much time on people in the past only to discover that they've been running franken-Kali the whole time... It kinda tweaks my brain every time I see a question like this. The language in the OP screams noob, I can't help but treat steering them away from Kali Linux as a service to the general sanity of the GNU/Linux community. Ed. Do you go by @soulsource over on the Gentoo forum too? Just curious...

Wrong on so very many levels... From the horse's mouth: Kali is not Debian. Kali is most certainly not a "skin of Ubuntu". Kali is not a general purpose desktop distribution, and you will have problems if you try to use it as one. Running Kali does not make you cool. Do yourself a favour, if you are not a professional penetration tester, use a different distro. If you are a professional pen-tester, run Kali from live media when you need it, not as your primary OS. When I was active over on FDN, we regularly laughed at the wannabe 1337 haxx0rs running Kali desktops. You won't get support there, you won't get support on the Ubuntu forums. You will get laughed at on the Kali forum as soon as they realise you're trying to play games on it, and they'll figure that out very quickly. KSP might run on Kali. Steam might run on Kali. Trying either is an ill-considered experiment at best, and a shortcut to a completely borked install at worst. Installing any kind of game or third-party application is both completely unsupported and actively discouraged by the Kali Linux developers. So am I... But this dude "needs steam". KSP itself will likely run, sure, but installing Steam on Kali is a completely different kettle of fish. If he already has Steam installed, then chances are good that he added external repos and that install will break horribly, sooner rather than later. Kali makes zero effort to stay compatible with upstream Debian.

All your problems stem from broken (read incompatible) mods. Interstellar: IndexOutOfRangeException: Index was outside the bounds of the array. at FNPlugin.FNHabitat.AssumeDragCubePosition (System.String name) [0x00011] in <087942052b85401fbd144dda5b37f047>:0 at DragCubeSystem+<RenderDragCubes>d__33.MoveNext () [0x000ed] in <55ba45dc3a43403382024deac8dcd0be>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00027] in <5aeafee3fea24f37abd1315553f2cfa6>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <RenderDragCubesCoroutine>d__30:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <SetupDragCubeCoroutine>d__45:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) DeepFreeze: Exception loading ScenarioModule DeepFreeze: System.NullReferenceException: Object reference not set to an instance of an object at DF.DFSettings.Load (ConfigNode node) [0x00001] in <73ccc08214f94d89a7b8fcc236736202>:0 at DF.DeepFreeze.OnLoad (ConfigNode gameNode) [0x0003a] in <73ccc08214f94d89a7b8fcc236736202>:0 at ScenarioModule.Load (ConfigNode node) [0x0000e] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.AddModule (ConfigNode node) [0x0005e] in <55ba45dc3a43403382024deac8dcd0be>:0 And: Exception handling event onGUIRnDComplexDespawn in class RDSceneSpawner:System.NullReferenceException: Object reference not set to an instance of an object at DF.DFSettings.Save (ConfigNode node) [0x00001] in <73ccc08214f94d89a7b8fcc236736202>:0 at DF.DeepFreeze.OnSave (ConfigNode gameNode) [0x00079] in <73ccc08214f94d89a7b8fcc236736202>:0 at ScenarioModule.Save (ConfigNode node) [0x000a6] in <55ba45dc3a43403382024deac8dcd0be>:0 at ProtoScenarioModule..ctor (ScenarioModule module) [0x0003c] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.UpdateModules () [0x00055] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00005] in <55ba45dc3a43403382024deac8dcd0be>:0 at Game.Updated (GameScenes startSceneOverride) [0x000a7] in <55ba45dc3a43403382024deac8dcd0be>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode, GameScenes startScene) [0x00045] in <55ba45dc3a43403382024deac8dcd0be>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at KSP.UI.Screens.RDSceneSpawner.onRDDespawn () [0x0000a] in <55ba45dc3a43403382024deac8dcd0be>:0 at EventVoid.Fire () [0x00127] in <55ba45dc3a43403382024deac8dcd0be>:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Uploading Crash Report NullReferenceException: Object reference not set to an instance of an object at DF.DFSettings.Save (ConfigNode node) [0x00001] in <73ccc08214f94d89a7b8fcc236736202>:0 at DF.DeepFreeze.OnSave (ConfigNode gameNode) [0x00079] in <73ccc08214f94d89a7b8fcc236736202>:0 at ScenarioModule.Save (ConfigNode node) [0x000a6] in <55ba45dc3a43403382024deac8dcd0be>:0 at ProtoScenarioModule..ctor (ScenarioModule module) [0x0003c] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.UpdateModules () [0x00055] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00005] in <55ba45dc3a43403382024deac8dcd0be>:0 at Game.Updated (GameScenes startSceneOverride) [0x000a7] in <55ba45dc3a43403382024deac8dcd0be>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode, GameScenes startScene) [0x00045] in <55ba45dc3a43403382024deac8dcd0be>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at KSP.UI.Screens.RDSceneSpawner.onRDDespawn () [0x0000a] in <55ba45dc3a43403382024deac8dcd0be>:0 at EventVoid.Fire () [0x00127] in <55ba45dc3a43403382024deac8dcd0be>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventVoid:Fire() KSP.UI.Screens.RDSceneDespawner:BtnExit() UnityEngine.Events.InvokableCall:Invoke() UnityEngine.Events.UnityEvent:Invoke() UnityEngine.UI.Button:Press() UnityEngine.UI.Button:OnPointerClick(PointerEventData) UnityEngine.EventSystems.ExecuteEvents:Execute(IPointerClickHandler, BaseEventData) UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1) UnityEngine.EventSystems.StandaloneInputModule:ReleaseMouse(PointerEventData, GameObject) UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData) UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32) UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent() UnityEngine.EventSystems.StandaloneInputModule:Process() UnityEngine.EventSystems.EventSystem:Update() That last one may well trap you in buildings. Note the exception happened near 'KSP.UI.Screens.RDSceneDespawner:BtnExit()' If you insist on running outdated or incompatible mods, please learn to read the logs yourself. These obvious problems are not hard to find, if your mods are working properly a quick search for 'NullReferenceException' in your log file should return nothing.

1) MiniAVC is borking. Kill it with fire. MiniAVC -> System.NullReferenceException: Object reference not set to an instance of an object at MiniAVC.AddonInfo.get_IsKspExcludedVersion () [0x00000] in <946c68c810554a77bc35cab54adcb678>:0 at MiniAVC.IssueGui.DrawNotCompatible () [0x00030] in <946c68c810554a77bc35cab54adcb678>:0 at MiniAVC.IssueGui.Window (System.Int32 id) [0x00006] in <946c68c810554a77bc35cab54adcb678>:0 2) Any mods which are up to date for KSP >=1.8.0 should have removed or fixed this already, which indicates rather strongly that you are running outdated/incompatible mods. 3) This is also why your log is ~65MB and so full of errors it's difficult to see what else might be going on.