steve_v

As someone who has spent some time digging around in the low-level code of (usually decrepit) CNC machines, I can assure you that it is. A CNC is a computer. It has an operating system, it runs user code. It usually has bugs. It has difficult to predict hardware issues to make finding the bugs more fun. That is ridiculous. Computers, and the code they run, are logical and deterministic systems. There is no voodoo, no astrology, and unless you try quite hard to create it, no true randomness. Sure, the code in a game like KSP is complex and there are many places bugs can creep in, but it's not magic, it's not alive, and it certainly doesn't react to the phase of the moon. One does need to test on a variety of hardware configurations, that's simply the nature of supporting the "PC compatible" architecture. It's annoying, but that's how it is. "It's complicated" does not excuse buggy code. It might make people more understanding of delays finding the bugs, but they're still bugs, and they still need to be fixed.

Today I tried to track down a bug that has randomly appeared when transferring crew, and failed even to identify the mod causing it. Then I gave up in disgust.

Indeed. To wit: "only using part of the API". I suppose this too. Frankly, I find the "open source needs to fix this" attitude I saw in the bug report to be somewhat pathetic. This entire situation is insane. @Unity3D: "Using the GameController API exclusively" is a moronic thing to do if you want anything other than (some) gamepads and steam controllers to work. Everyone else has figured this out already. The GameController API has problems with a lot of things that aren't gamepads, because it wasn't designed for things that aren't gamepads. Right now it's only viable purpose is to provide an easy way to make all the zillions of xbox controller clones work like xbox controllers. Using it for generic joysticks is madness.

This is all well-and-good (and also very M$ specific), but the thing is, my device is not a game-controller, it doesn't use XInput GameController*, and it works perfectly well like that. Except in KSP. SDL2 (which uses the new evdev driver) is reporting perfectly usable joystick events. So is SDL1, which uses the old joydev driver. I can hack together a little moving whatsit that uses SDL2 to access my joystick in about 10 minutes. So either the Unity build KSP uses isn't actually using SDL at all, or it's only using part of the API (i.e. ignoring devices that don't use GameController). If Unity is insisting on using some new M$ specific API and ignoring everything else, this is still Unity's problem, and we shouldn't have to work around it. And mapping the buttons ids to xbox-specific names is still ridiculous. Sure. Again, this is Unity's problem. If a ~20KB test application can detect and use my device, so can Unity. It's a big problem for Unity, if they want to support joystick devices on GNU/Linux. It's not the job of the OS or the input abstraction layers to pander to the vagaries of one game engine. If Squad has decided to use a game engine that lacks support for the most common joystick protocol on the market, and wants joysticks to work, then it becomes Squads problem too. I still don't see this being up to "the open source community" or Linux to fix in any way. It's not broken. DInput works fine. SDL works fine. Evdev and joydev work fine. If you don't want to use them, you get to provide the emulation layer. Much better. * Thanks Voidi, that's actually more accurate terminology WRT SDL2.

And. And is the word you seek. We've been there, with prerelease access only for Steam users. It wasn't pretty. Other than that little detail, hell yes.

I do (usually) try to avoid anything that resembles "the developers should do [x]". I have no problem calling Squad out on bad decisions though, and I do like a bit of gory shop-floor technical detail in my announcements. While I would sometimes like some names, so I can say "Gus the PR guy is clearly a moron, he orchestrated this whole debacle", it's probably best for everyone that we don't have those details.

My feeling also, and it's only the bit from "then someone above them told them" onward that annoys me. My vitriol is aimed squarely at whoever is making such decisions, but since I can't tell who is who from here, with the "stakeholder shield" and all, I can only direct it at "SQUAD" as a whole. Perhaps I should clarify: That depends. If the devs are the ones who decided not to do a prerelease, and to release 1.4.0 in the state it was in, then yes. But I doubt it was the dev team, more likely some meddling manager or marketing team.

True. Also true. Probably also true, but it wasn't aimed at @silverfox101. Squad did a prerelease, and it caught a lot of bugs*. Then they stopped doing that. Why, when 1.4.0 so clearly would have benefited from one, remains a mystery. *And also generated it's own arguments, due to a stupid decision to distribute it only on steam... I'm not concerned about mod compatibility, that always happens.

Probably because Steam, and the game industry at large, has conditioned you to accept DRM and arbitrary restrictions a matter of course. Resist. A beta release stream! Prereleases! What a capital idea! Who'd 'a thunk it? If we were discussing bugs in a prerelease, I bet you there would be no demanding, griping, or otherwise impatient comments here at all... But what we're discussing is a much-hyped full release, made out to be the most-awesome-thing-ever that everyone should get so that they can buy the DLC, and it arrived as a buggy mess. Two patches later, it's still a buggy mess. Uhh, that's very silly. People need to learn how to search.

"Oh, my God! Another patch delay? So I will have to play 1.4.1 1.3.1 KSP for another week?" FTFY. 1.4.0 & 1.4.1 also have serious regressions WRT 1.3.1. So that they can blissfully beaver away at anything but what the customers actually want, presumably. Besides, do you really believe a developer penned that update? If they did, it's a gratuitous misdirection of effort.

Copying files and executing executables is "using a computer" 101. "I don't know how" is just ridiculous.

Yes, it would be nice, wouldn't it. Almost as nice as a .0 release that didn't need a bunch of "hotfixes" in the first place. If the news was along the lines of "We're going to delay this patch a bit to make sure we squash all the bugs you guys are lamenting", I'd be ecstatic. But no, it's the new last-minute launchpad that's holding things up, and there are still outstanding 1.4.0 bugs that aren't being addressed at all in this patch.

I have done this, because Squelch asks for more info, and I keep the following out of the bugtracker because it doesn't really belong there... My joystick is not a gamepad. SDL is correctly identifying the device and assigning it an ID, and it is correctly determining that it is not a gamepad. The comment re. "helping the effort" by adding your device to the GameControllerDB, complete with mappings to inputs like "leftshoulder" "start", "x" and "y" that do not exist on this device, is utterly ridiculous. As is the implication that these mappings not existing for a majority of devices is a problem the "Open Source Community" needs to fix. My device is a generic USB-HID joystick, not a bloody xbox controller. SDL is working as intended. The problem here is that the game engine doesn't support anything but console-controllers, and things that pretend to be console-controllers. Additionally, even when a device does pretend to be a console-controller, most of the time the game still doesn't identify axes properly. None of this stupidity has anything to do with SDL, it's a bug that Unity introduced by switching to SDL2 input exclusively, then failing to implement it properly on their side. How about let's stop faffing about with client-side workarounds and fix the real problem.

Welcome to 1.4.2?

Went to the Jool system: Lobbed some stuff at Laythe, for later: And landed on Tylo, for the first time in ages... Manually, (MJ can't fly this thing with no engine gimbal) and with 11m/s to spare in the descent stage. Too close, way too close.

If I had ever seen either of those "r/" things (meaning reddit?), I might know what you're talking about. OTOH, it's probably about time to forget about p1t1o's strange off topic intrusion and get back on topic... I'll leave you to it.

True, however they are now 1000% more hideous and cause obviously buggy rendering behaviour into the bargain.

I suspect that is the point Then again, how long does anyone spend looking at him anyway? If you hadn't said: I wouldn't have known which one you were talking about.

No. Shock and horror, no new FAR release in 18 days, what will we do?

1.3.1 runs fine (for KSP) here, both on Debian and Gentoo. It does still crash occasionally, but nothing like what we had with 1.1.x. My input devices all work fine, planes and rovers work fine (FAR, no comment on stock aero), and I have never seen any of the contract issues you mention, in any version since career was introduced. I have 2 sentinel contracts and "explore duna" active right now. 1.4.2, on the other hand, makes my joystick a paperweight, adds unsightly overlapping part icons in the VAB and hideous, framerate tanking aero / reentry effects, and it causes landing legs to spontaneously explode. Thankfully I won't ever see the fairing drag bugs, because FAR. So far it appears to crash about as often as 1.3.1, which is to say not very.

I'll take your word on that, as I don't have enough personal experience with it to say otherwise. My information here is mostly second-hand, and probably coloured by those low-quality games.

It's a scientifically and logically correct word, carries no negative connotations (or any at all for that matter), and it's a part of the english language. As such, I intend to use it exactly the same way I would use the counterpart "male". If a female human asks that I not refer to her with those specific words (or any others for that matter), I will gladly respect her preferences. But you're not that, I'm not referring to you, and you are in no position to dictate my vocabulary, be it 2018 or 1908. This^. Enough with the carpet of eggshells PC nonsense already. A spade is a spade.

I try... I'm told there are sane and reasonable females out there somewhere... I think maybe I even met one once, but like most people I actually begin to get along with, she got married and buggered off to another corner of the world. Maybe I'm just twisted, or just old. It's hard to tell these days. For all the drama in here, you young ones have it easier than you know.

My strategy is to always be one major release behind. By the time all the bugs in 1.4.x are sorted (if the game engine problems ever are), 1.5 will be announced, complete with a new batch of bugs. Like a low-budget indie game, still in early access. I'd hoped this kind of thing would stop when KSP got the big 1.0. Then I hoped it'd stop when we hit the first major after that, thinking perhaps 1.0 was just a bit rushed. Then a big name, Take Two, bought the game and an expansion was announced... I hoped... Maybe this is just what happens when you decide to build a game on top of a cheap-and-cheerful, perpetual-alpha, users-as-QA game engine. Then again, other games built on Unity3D have got polish... many of them even have stable releases that don't add serious bugs.

Sounds reasonable to me. ¯\_(ツ)_/¯ One could even pick the names... I think I will take three: "Rapid", "Unplanned", and "Disassembly".