Jump to content

steve_v

Members
  • Posts

    3,438
  • Joined

  • Last visited

Reputation

2,587 Excellent

Contact Methods

  • Skype
    Skype? Is that some kind of delicious biscuit?
  • Twitter
    I am not a twit.

Profile Information

  • About me
    Still waiting for that not-broken post-1.3.1 release...
  • Location
    /dev/chair

Recent Profile Visitors

8,563 profile views
  1. This is a known issue with scatterer's TAA implementation (and how TAA works in general). There's no need to roll back to an earlier version, just turn it off in scatterers config dialog if you don't like the jitter/jaggie tradeoff.
  2. I don't know about tufx, but IME some of scatterer's fancier optional features can be a proper GPU hog. They do look quite nice though, so experiment a bit and find a compromise you like. As for comparing to other games... Other games were designed with the graphical shiny in mind from the start, so things are bound to be better optimised. I'm also running a 6700xt (XFX QUIK 319), and TBH no matter what I do to it I can't get it above ~65C, or make it audible over my CPU cooler... That said, an OC'd 10900KF on air usually drowns out the rest of the system anyway. I'll not make any FPS comparisons here though, they'd be pointless as I'm running the GNU/Linux build and scatterer performs pretty poorly with the OpenGL renderer at the best of times.
  3. This I can agree with... With the minor caveat that even if KSP2 is all that, I'm still not going to buy it unless it runs natively on my system. Doubly so knowing how easy it is to do cross-platform in unity these days. That said, I have experienced the output of KSPs development cycle first hand, and given my fairly cynical outlook WRT big game industry players like Take Two I have zero faith that KSP2 will prioritise stable core systems and bugfixes over SNS either, or that they'll be reasonable with monetisation. Leopards, spots, etc. So yeah, I'll consider buying it when I can verify that "1.0" means it's actually ready, rather than someone just pulling a number out of their behind to drum up interest. Clearly all forms of monetisation aren't evil, but I can kind of understand this attitude considering the predatory behaviour that has become normalised in the game industry. The franchise being bought by Take Two (and the rather dubious happenings surrounding that acquisition) makes me pretty jumpy around the "m" word too. I've never understood that attitude TBH, I can kinda get people being liquidy if some players get free stuff and others don't (i.e. the DLC fiasco), but expecting people to work for free is pure fantasy. Me, I'm quite willing to pay people to work on the game, so long as the monetisation isn't exploitative (hence the hard no to loot boxes and other dross). I do however have some opinions on what parts they should work on, because IMO bugs and regressions, especially those that prevent paying customers from enjoying the game, should always take priority over new features.
  4. Obviously I can only speak for myself, but I'm pretty sure (without digging through my 3k+ post history) I have said before that I'd probably be willing to buy what amounts to a DLC containing nothing but bug and physics jank fixes. I also purchased both DLCs, despite neither of them containing anything of interest to me, just to fund development... After a couple of long ignored and pretty gamebreaking bugs in the GNU/Linux build were eventually fixed (only for later releases to introduce more of course ). Squads lack of forethought isn't really my problem though. I never made that claim and I never would, because it's clearly ridiculous. Ed. We should probably get back on topic now.
  5. Not at all, rather I'm disappointed and kinda annoyed that development ended with such a vast number of open bugs (not to mention the un-triaged mess that is the public bugtracker). Despite saying "please stop adding new stuff and copies of existing mods, and just fix the bugs in the core systems" for years, the last few releases were... wait for it... adding more stuff that perfectly good mods already had covered, and introducing regressions in core systems. The game getting bigger than originally planned is fine (assuming the resources exist to develop and maintain it), the game getting buggier in the process is not. My EA ride has gone something like this: Me: 1.0 already? That's got to be the shortest beta in history, what about all the bugs we found? Squad: Launch party hype! Launch party hype! Me: Uhh, performance still really sucks, and it's getting worse with each release... Squad: New parts, hype hype! Me: Well, performance is slightly better, but can we please get a fix for the wheels? They've been broken for like, 4 releases now. Squad: Look, shiny DLC! Me: What the hell happened this time? There's surface tile misalignment all over the place and my bases keep exploding. Squad: We're adding new kinds of rocks! Me: Wheels are more broken than ever guys, and now stuff is sliding around everywhere too. Also joysticks don't work at all, and haven't for 3 major releases. This is getting ridiculous. Squad: Tron suit! Tron suit! Isn't it awesome? Me: Uhh, hello? Wheels? Surface interaction in general? The rest of the bugs from 2+ years ago? Squad: Get hyped for KSP2! So yeah, I'm not so keen on this early access thing any more. I wonder why that might be? Well it's certainly more broken than it was ~4 years ago (1.3.1). More half-finished "features" too. Yes, yes you can. It happens all the time, but strangely enough, you do actually have to prioritise doing it. Fixing a 10 year old codebase while simultaneously adding a constant stream of frivolous new features technical debt, now that's hard.
  6. If you have steam installed. If you do not have the client and a login (and for many games pass steams DRM checks), it's third-party downloaders and hassle all the way down. Steam is only part of the conversation because Master brought up "Official Linux support through proton" and "I won't use any mahor release platform but I want something that isn't a PITA to instal on Linux" It's only a few small steps from "you need steam/proton for GNU/Linux support" to "we're only using steam as a CDN" to "we're converting store purchases to steam keys". Then comes the argument that "steam workshop is more convenient and everyone is using steam anyway". We've already tried the "beta access only for steam users" bit with KSP, and knowing what that feels like I'm not about to let them put the tip in again. The only reason we didn't end up with the KSP modding scene running on a proprietary platform like curse or steam workshop is the existence of better community developed alternatives... That and the massive community pushback over the spacedock vs curse thing. The outstanding bugs and regressions fixed (also the pervasive physics jank, e.g. wheels that work properly, landed vessels and bases not sliding around or randomly self-destructing), and at least a few of the features introduced years ago as barebones placeholders polished into a coherent experience. Perhaps, ya know, a progression mechanic a little deeper than "go place, click button, get points"... Or maybe using the part upgrade system for anything at all. There are plenty of other examples of stuff haphazardly chucked into the game with promises of fleshing them out later, then forgotten for the next shiny thing.
  7. I was talking not about KSP specifically, but steam in general. Frankly, a game launcher even supporting DRM functionality is enough for me to not want to use it, and this is only one of many reasons I don't use steam. Sure. Except that for most moddable games released on steam, the majority of mods end up on steam workshop and only on steam workshop... Which is intentionally difficult to access without the steam client. It would be utterly trivial for Valve to provide a direct download button on workshop pages, but they don't. I wonder why? KSP is different in this regard because it's not steam exclusive, and the modding community is awesome. IMO it's unwise to rely on that remaining the case for KSP2, particularly if it were to rely on proton for cross-platform support as in the suggestion that started all this. Thin end of the wedge and all that. Sure, that's why I bought KSP in alpha. Early access isn't a charity though, the idea is that you do actually get a finished thing at the end of the process. KSP is nowhere near finished IMO, and yet here we are calling it a day and moving on to a franchise backed by a multinational corporation.
  8. I won't use any distribution platform (major or otherwise) that creates walled-gardens (i.e. steam workshop), regularly behaves as DRM, often requires an internet connection and/or login to play offline single-player games, downloads 30% of a different operating system as a runtime even for native titles, and interferes with my ability to keep local backups. Most of the games I have purchased over the years came from GOG *looks pointedly at long list of indie titles*, and while GOG Galaxy exists (and is kinda terrible TBH, but whatever), I don't have to use it because they also offer direct, DRM-free downloads in a self-contained easy to install format. That's all totally fine by me, and when steam/epic/whatever does the same (and gives me a way to easily identify titles containing DRM and other such brokenness) I'll absolutely consider using it. The rest were purchased direct from the developer, at their own store, and that group includes KSP. If it was steam exclusive I wouldn't have bought it in the first place and we wouldn't be having this lovely argument discussion. I'm not suggesting that every game studio put up their own store store front and CDN of course, that would indeed be impossible for many indie developers... But there are alternatives, such as GOG or Humble, that don't try to lock people into their ecosystem or require a special client application. AFAICT most of them will even do the packaging/installer bit for you. KSP is leisure and entertainment. Trying to get non-native games working in WINE, rip them from steam so I can back them up properly, or and disarm their anti-features is not. Perhaps I should have said "limited patience for gratuitous screwing around when I could just go play something else instead". The TLDR here is really: "I use GNU/Linux, and that's non-negotiable. I also intensely dislike DRM and rental-disguised-as-purchase. If you want my money, make things easy for me, or at least not unnecessarily difficult... Oh, and since you never really finished the first game, I'll not be doing the EA bit again."
  9. Valve's proton, no. I do not and will not use steam, and valve makes using proton without steam obnoxiously annoying. Vanilla WINE (+DXVK)... Maybe, under protest, and only if that means: * Real official support, i.e. bug reports and/or support requests being taken seriously and actioned in a timely manner, and effective prerelease testing and QA being performed under wine. * Native performance. Not "near native", and not "close to windows". KSP2 is almost certainly going to be CPU intensive, and running things under wine is not without overhead. * Installation and configuration is not a PITA, e.g. no faffing about with winetricks or installation of multiple GB runtimes and other such trash. * Compatibility testing against the wine versions packaged by all major GNU/Linux distros, or provision of a custom, self-contained build that has received the same. Said build shall not be enormous, see runtime garbage above... And no, snap/flatpack/whatever idiotic "universal" package format is FotM is not the answer. * Support for, or at least clear acknowledgement of the WINE project. When a commercial entity directly profits from a FOSS project, I fully expect them to throw that project some bones in return. ** A properly amazing game, so amazing that I am willing to make an exception to my longstanding "no tux, no bux" rule. Very few games have so far cleared this bar, and not even KSP is on the list (at least not at its current price and in its current state). For a simple FPS or something, sure... So long as there is a mechanism to do so that isn't tied to steam. With a game as complex as KSP2 is supposed to be, I'm really not convinced 2 hours is long enough - especially as that includes the time taken to download, install and configure the thing (and screw about with wine/proton in the above scenario). If game studios are going to do the cheap and lazy offloading demo functionality to youtube reviewers and steam refunds thing, I'll usually just do the cheap and lazy walk-on-by one. There's always just [REDACTED] the thing in lieu of an official trial of course, but we'll not speak of that here. Correct. I have limited time and limited patience. I currently have more games to play than I have free time, so so wasting the latter making me jump through additional hoops is a non starter. I also have no desire to pay for the privilege of spending hours guessing which particular wine version or patches I need, how many 3GB .NET runtimes I have to install, and how to remove DRM and/or anticheat rootkits that gratuitously and intentionally break compatibility. Ergo, no native build no purchase. While we're here, I might as well add a few more (though these have already been discussed WRT KSP2 IIRC): No DRM or invasive anticheat. No pay-to-win, real-money gambling mechanics, microtransactions, lootboxes, in-game advertising, or NFT insanity. No forced account signup or online checks in single-player game modes, and no phone-homes or analytics (or the same being strictly opt-in). An offline installer or distribution archive for direct browser download, not tied to any particular game store or launcher frontend. I expect that's because what constitutes "common practice for games" these days is usually customers-as-beta-testers, execrable abuse of power, and extorting the playerbase at every possible turn. The mainstream "AAA" games industry is a revolting cesspit of corporate greed, and I expect many here really, really don't want KSP to go that way. Incidentally, my requirements are pretty well covered by the "Linux games" section on GOG... Indicating they are, at least outside the "AAA games" DRM and microtransaction garbage fire, not particularly unreasonable.
  10. 1. When it a) has a native GNU/Linux port, and b) is a finished, polished product and I can verify this with a comprehensive, up-to-date free demo. At this point that's pretty well equivalent to a flat "no". 2. I don't care, so long as the product is appropriate for the price tag. Again verifiable with demo, shareware or trial. 3. No. Hell no. All of my no in fact. I bought KSP based on promises of a finished product down the line, and years of horrible performance, untested .0 releases, ridiculous regressions and half-finished features later, development ended in favor of a new franchise money-grab. I'm still waiting for that finished, polished game I anticipated. Lesson learned. Perhaps KSP2 will be different, but this time around I will require proof before I even consider spending money on it. If my suspicions as to the development model are correct, that means If I do buy it it will be at a deeply discounted price long after final release.
  11. That's because two issues are in play. This has been a problem for years (there were prior reports too, but the tracker got "cleaned"). The new docking ports cause (even worse) joint deformation the same way other robotic parts do (this was a problem with IR as well, long before stock robotics were a thing), and the issues relating to craft pack/unpack saving the deformed state makes it permanent. It was band-aided for robotics by having autostruts disengage when robotic parts move, and re-engage when they're locked. Now we have the same on docking ports.
  12. That's a very old bug, and craft being permanently deformed on reload is a problem far deeper in the game architecture. It's not just docking ports either, all joints suffer from this. Yes, autostruts spanning docking ports makes it slightly less problematic... But it doesn't fix the underlying problem, it's just another quick band-aid on the large pile of quick band-aids for architectural and game-engine problems. Like most of the other quick-fixes, it comes with it's own problems. That's generally what happens when you use new features to plaster over old bugs... Hell, unfixed jank in the physics system is why autostruts exist in the first place.
  13. I'm not, not really. This is just an echo. With the end of updates and all the bugs and performance problems it left unsolved I kinda lost interest TBH. But seriously, spinlocks for thread synchronisation? What is this, 1995?
  14. Uhhh... Dunno if I would call "go watch someone else's tutorial" a tip TBH. Pitch 45° which way? Why? How slowly? Gradually pitch how much more? When? What kind of menuver [sic] in space? When? Nothing on how to build something that can get to orbit (or a "tip" to use a stock craft that can)? No mention of TWR? Required ΔV? How to plan a circularisation burn? I mean if this is supposed to be a "beginners guide", shouldn't you cover the basics first, like how to read the navball, create maneuver nodes, that kind of thing? [snip]
  15. If you're not adverse to mods, you might look into ReStock. IMO it's a vast improvement over the stock (even with the recent revamps) art style.
×
×
  • Create New...