steve_v

It was a mess when I tried it, but to be fair it was also in beta. Good to know it came out all right. I'm still not going to buy it though, due to the lack of a GNU/Linux native port. It would have to be an utterly incredible game for me to break that rule, especially as I already have the original. From what I saw in early versions of the remasters they're pretty true to the originals, and the originals were excellent.

Indeed. I keep thinking of ways to improve this, but all the good ones are complicated or require a game engine change. It does mildly annoy me that my modded install uses ~10GB of memory, but I guess that's not too onerous on modern(ish) hardware. Agreed, and not a moment too soon. If the Win64 Unity builds weren't such a crock at the time, I would have backed a move to 64bit only as early as 1.0.

I have pretty much the opposite point of view. A hobby is a labour of love that I am inclined to support and whose shortcomings I am inclined to forgive, while T2 is a faceless money-grubbing corporation that I can't get behind at all. T2 bought KSP right before 1.4, and 1.4 broke input support on GNU/Linux. All I have seen from them since is art improvement I don't really care about, and more DLC. Meanwhile, the game still doesn't recognise my joystick or gamepad (3 major releases later) - both of which worked perfectly before T2 got their grubby mitts on it.

It's been a long 6 years so far.

Cool DLC, shame I won't be buying it. Working joystick support doesn't seem to be included, what a pity. Oh well, guess I'll just go play something else while I wait for KSP to be out of beta.

Bugs happen, that's fine. It's bugs still not getting attention several releases on and improperly squashed bugs recurring repeatedly that pulls my chain. Likewise, and it probably still is to some extent. Last time I looked it was still silly expensive (for some cunningly shaped bits of plastic) too... But let me ask you, how many bugs did your crane kit have? Did it ever crash? I never saw any with my lego sets, even after the dog got a couple of pieces. Not a single CTD. Likewise, and likewise. Then again, my car is user-serviceable, reverse engineering is not prohibited by some silly licence, it doesn't report my use of it to it's manufacturer, and it has no noticeable bugs at all. A comparison to KSP is a bit of a stretch, IMO. If you're suggesting that ongoing costs like fuel and subscriptions are a more apt comparison, I have to disagree there as well. KSP is not a subscription, it's a packaged product sold for a one-off price - like my car, my toaster or that CAD software I bought 15 years ago which still works perfectly to this day. When buying something on that basis you naturally expect it to work properly from the moment you take possession, without hotfixes, mods or workarounds. When I have faith that the latest DLC will work properly (as shown by the core game working properly), I'll buy it. Not likewise. $900/year is ridiculous. I wouldn't pay that for any software, especially not an ongoing subscription. Perhaps this ridiculously expensive software is essential to you, but I would most certainly be looking for an alternative, were I in such a position. Frankly, I'd take paper and crayons over having to run Windows all the time. I have played the original, but last I checked the remaster was incredibly buggy and didn't run on GNU/Linux. Has it improved? Indeed it is, but for me price is not the issue. I would love to buy the DLC, but I'm simply not going to until SQUAD fix the GNU/Linux input support regressions they introduced in 1.4. Hell, I'll buy both DLCs at that point. Mine are 24 and 58, respectively I didn't have to pay Jaguar Land Rover Automotive PLC a cent for additional features on my landy though, that's the reverse-engineering bit again. Indeed Since 1.4 however, core input support has been locked behind a mod-wall, and SQUAD has done absolutely nothing to fix it properly. I'd do it myself, but there's that licence thing again.* I do try to avoid that in my grousing, with mixed success. On the other hand, I will extensively criticise failures to fix bugs that SQUAD or their associates and upstream suppliers introduce - those involve little speculation, and the longer they go unfixed the greater the criticism. This game is not in beta any more and I do expect it to work properly. *No, mods are not the answer, this should be fixed at the source. I can dismantle the engine in my car and make improvements, but with KSP all we are allowed to do is strap things to the outside. Our only recourse for internal fixes is to pester SQUAD. ----- Agreed. I have suggested that the DLC ought to be free for a select few though, namely those who bought the defective console port in good-faith. I don't own a console, so... Entitlement by proxy?

You did not have to remove Kerbal Atomics entirely, rather not install the hydrogenNTRsClusters.cfg patch. It's in the "Extras" directory because it is optional. There's a patch in there to convert the Kerbal Atomics engines to LF as well.

Your problems may or may not be a sign of impending failure, looking at the SMART data for the drive (try Crystal Disk Info on windows) would be the place to start in making an educated guess. You should back up regardless, hard drives can and do fail without warning.

That's a sweet album too. As for my avatar, darkness and entropy will consume everything eventually. All things must fade to black.

In the simplest sense, copy everything to another (external as this is a laptop) drive. This will do for your personal files, but it does nothing to aid quickly restoring the system and installed software. Windows had a proper backup tool, but for some idiotic reason Microshaft decided to deprecate it. I think it's still available in 10 via: Control Panel - >System and Security -> Backup and Restore (Windows 7). It would do for now, but as MS has thrown their users to the wolves (i.e. third-party software providers), it's left as an exercise for the reader to find a replacement for windows backup before they remove it completely. Other options for imaging the complete system or copying to a new drive include using Macrium Reflect from within windows (there are others, but I'm not going into the cesspit of sort-of-free-but-not windows software to list them), or booting one of the aforementioned live GNU/Linux systems and using one of the many free tools therein, such as Clonezilla (my pick), ntfsclone, G4L, or plain-old dd . Imaging the drive this way will make a full copy of everything that can be restored to a new drive if the one you have decides to crap the bed completely, Windows and all your software included. If you're even slightly lazy, you want that. If you want something automatic (so you don't need to remember to re-do the image or copy over new files regularly), it's time to go in search of reviews of third-party solutions. People who actually use windows might chime in here with their picks, hint hint.

Run a filesystem check. And back up your data regardless. Failing hard drives do not magically get better - they can remap some percentage of sectors to cover for failing media, but any read error or data-loss is cause to be very suspicious of future reliability.

This is why we have backups. See if the BIOS detects the drive. Open machine, reseat HDD cables. Check for and correct any corrosion on drive electronics. (been there so I'll throw it in, but that was a pretty hostile environment). See if the BIOS detects the drive. If the drive is not detected by BIOS, try it in another machine. If that also fails to detect the drive, it's probably beyond (DIY) recovery. Replace drive and restore data from backup. If the drive is detected, boot a live environment such as PartedMagic* (an old but usable version is included with Ultimate Boot CD) or SystemRescueCD from USB / CDROM and use smartctl/gsmartctl to retrieve self-test and health data from the drive. At this point it is advisable to image the drive (or at least important data) before proceeding further, the sooner this is done on a failing drive the greater the chances of getting your data off. The live distros above have several tools for this, I like ddrescue. Any GNU/Linux distro will do in a pinch though, as they will all have dd. Once you have the data off the drive, decide with the help of the SMART data, SMART self-test routines, and potentially results of a badblocks run whether the drive is still usable. *Not free but very handy to have around, the best recovery distro I have seen. I can flick you a recent-ish copy if you can't spring the $11, or you can just look in the usual places. If by that you mean that single drive contains the only copy of your data, you have just learned a valuable lesson. There are two kinds of computer users: those who have backups, and those who have never experienced a disk failure. It happens, and it's happened to me many times. My record is 12TiB of (non-critical but very annoying to restore) data going poof when 2 drives failed within hours of each other. Now I run more redundancy. I heartily disagree. A distro designed for data recovery is almost certainly a better choice as it will have the tools you need preinstalled and readily accessible.

Right then, that'll be why nothing works here. So nice of Unity/Squad to target a framework so old that no sensible OS packages it any more.

Good to know. Unfortunately it also has far too much "built in" spyware for me to ever use it.

It's a pain in the ass on any OS, due to some rather old design decisions on how to get data to soundcards. Essentially, you need to hack the soundcard driver or insert a shim between the application and the driver. Or just use a cable. ALSA on GNU/Linux has a plugin that can do this (with some properly arcane configuration) and Soundflower on MacOS creates a virtual soundcard for the same purpose. I have no idea how to go about it on Windows, as that OS does indeed suck.

As far as I can see Unity 2017 (and thus KSP >=1.4) uses .NET 4.5, but I can't get anything to actually load in game when compiled with mono 5.16 / .NET 4.5 (Gentoo). Dunno whether it's my environment or me. I never had any issues in the past with U5 and mono 3.x / .NET 3.5 (Debian GNU/Linux), but I don't have the patience to write an ebuild for / compile / install a fossilised mono release to try it again. I hate .NET with a passion anyway, so for the little time I need to spend with it I just load up VS in a windoze VM. ¯\_(ツ)_/¯ Mono stopped packaging the .NET 3.5 assemblies with v4.0. You might try grabbing them from here, but YMMV. My patience expired long before I got that far. Granted I'm not talking about MacOS specifically here (as I don't own one), but mono is mono is mono, and *nix is *nix to a certain extent. Someone with Mac specific knowledge might yet emerge from the woodwork, I'm sure there are plenty here.

I can't make heads or tails of that sentence, or the rest of your post for that matter.

It varies with craft geometry, gear placement, tweakable settings and craft mass/body gravity vs. gear count. There are probably more. No matter which way you dice it though, nothing should ever lead to endless bouncing. Perpetual-motion is a physics simulation fail, there's no other explanation. Are you serious? That was sarcasm right? Realistic wheels do not bounce endlessly without energy input or launch craft violently into the air at the slightest provocation. The perpetual motion machines are the result of the janky new physics code, not added realism, wheels have been broken since 1.1. Are we even playing the same game? Part clipping has not been a problem for years, same-craft collisions were disabled. While it has nothing to do with clipping, craft flexibility does aggravate the suspension jank, hence the recent autostrut band-aid. Autostruts were created solely as an attempt to fix the horribly broken suspension system. Indeed. I would think anyone with a reasonable grasp of common-sense physics would see that from the video you linked. @GRS registered here after Squad borked wheels/landing gear, so I can only surmise that he thinks this janky behaviour is intentional.

Wait, what, delaying a releasee to deal with bugs? Bravo. Please do this whenever you feel a release needs more work. If only it happened more often for the PC release, think of all the stupid bugs and hotfixes we could have avoided.

Yes they do, I'd have given up on the game long ago without them. The only reason I update the game at all now is new mod releases. Mods adding missing functionality is awesome, it's been awesome since day-one. Mods fixing new idiotic regressions in the stock game 6+ years of development in is ridiculous. Regressions are Squads job. It's been shown repeatedly that fixing input support is quite possible, and there are now 3 mods that I am aware of which do so. The excuse that it is too difficult is long dead. The excuse that it would take longer than waiting for unity to fix it is long dead. All that remains is Squad being either too lazy or too incompetent - and I find the latter pretty unconvincing.

Community member develops cross-platform remote input layer, releases it for free and provides support. Professional game development company fails utterly to support even local input devices, blames third-party engine and calls it a day. This mod is indeed awesome. It's just a shame we need mods to work around Squad's ineptitude and/or apathy.

AFAIK any LS mod that has converters is open to changing the input/output of those converters with ModuleManager. IIRC USI uses the stock converter module and TACLS a custom one, both have inputs and outputs defined in the part configs. As for changing what kerbals consume, TACLS is configurable (resources and rates) in LifeSupport.cfg. I don't know about the others.

Everything here is an opinion. Mine happens to agree completely with Bac9's analysis. There were just too many things wrong with the images we were shown to take it seriously, reactions to the aesthetic were certainly subjective, but the technical problems were not. Some of his comments were things that only someone who understands modelling and design would notice, others were blindingly obvious to anyone at a casual glance - such as the texture on the tanks (complete with ludicrously large rivets), the completely out-of-place medieval barrel, and that doG-awful plank texture sunk into the grass on the path from the tracking station. You just don't do that in a professional commercial product. SQUAD are supposed to be professionals, and the barn was anything but. Unpaid modders regularly make far better assets. There's no mountain here, at least not from me. It was a concept that was shown to the community, and the community said hell-no, that's all. Why some people want to dig it up again every now and then and argue about it is a mystery to me, the barn is dead, let it lie.

The text in the spoiler is a windows crash dump, not a log file. Which log to upload is explained in the support post Jammer-TD linked. The mega link in encrypted, so I can't see what's in it.

There was, around 1.0. Spin-o-tron or something like that. The closest current mod I can think of is: Set the rotation step to zero for continuous rotation. You could also use it's NodeRotate module to make yourself a custom rotating part if you don't want to use docking ports.