Renegrade

Members
  • Content Count

    2,419
  • Joined

  • Last visited

Community Reputation

1,152 Excellent

About Renegrade

  • Rank
    Sir Wingsalot

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It might, but C++ itself isn't particularly fast unless you really know what you're doing (and that ends up looking like plain ol' C, strangely enough, only it takes six weeks to compile vs forty-five seconds). And mixing a GC and manual-memory-management language sounds like one of those 'worst of both worlds' things. I disagree with the memory thing - I have 32GiB and I still get GC stutters. The only way to avoid such stutters is to not do dynamic allocation at all. All the "disadvantages" of manual memory allocation with none of the benefits. (note that these stutters don't really matter if you're doing some batch-style processing, but it's very obnoxious in a realtime application like a game) Anyhow I think I'm getting too offtopic. I definitely agree that Unity<>Java is a strange comparison. Apples and machine screws.
  2. Ditto. And Civ 4. Lots of Civ 4, even though it needed a better "huge stack of units" management UI. And sometimes Civ 1/2/3 (although they feel kinda same-y to me). I'll still play KSP1. Heck, I kept backups of all of my Squad Store downloads, just in case I want to say play 0.22 again. Heh.
  3. I suspect it is over-ambitious, and I worry about the consequences for future space-y games if they do faceplant....but on the other hand, you must have some sort of ambition to accomplish something big. Like the original Moon landing.
  4. Do you understand Amdahl's Law? The need for critical sections and mutexes? Order-dependent operations? I'm a professional programmer. Are you? Ironic that you should mention the 90s - most of the crap you're using today is just tired old rehashes of 90s stuff anyhow. You're running GameSDK on Windows NT (or OpenGL on Linux). All of the 'advanced' stuff (SMP, SIMD, 64-bit, PIC, cache, etc) of your CPU was invented by Westinghouse and Cray and Burroughs and IBM and DEC and such before you were born, and saw their first iterations in the 80s and 90s on PCs and home computers. None of the underlying laws of physics has changed since that time. "When I look at KSP, I see a bunch of things that could be separated onto different cores" -- Like this isn't some overblown statement, peppered with your own personal sentiment. By the way, everything I said can be backed up with simple web searches with the sole exception of SupCom stuff. It appears that Gas Powered Games went under at some point in the past, and the forums with thousands of posts detailing the crash and burn which was the "muh multicore/SMP" programming paradigm bit it with them. Oh wait, I suppose that actually counts as evidence too! Maybe they'd still be here if SupCom wasn't such a pig... Still, I'd prefer the actual direct evidence remained. Effing internet is such fail. Maybe I'll dig it out of the wayback machine at some point... You know KSP already runs separate vessel physics instances in separate threads, right? (introduced in ... uhhh.. 1.2? 1.3? I forget) That's likely 80% of the potential speedup right there. Even if you could find other places to be concurrent in, you'd also find that the opportunity cost in terms of data locality / cache misses would override any possible gain. Anyhow, I have Kerbals that need to explore the newly retextured worlds. Oh and they're using 57 threads to do so already, of which about ten are sharing the CPUs aggressively. TL;DR: It's a complex problem that you can't just throw cores at and expect it to work (this applies to almost any program). See Amdahl's Law. Plus what Brikoleur just said.
  5. What the eff? Comparing Unity and Java is .. not really right (as in apples and oranges.. or maybe like.. apples and machine screws), but if you consider the underlying language when in a .NET/mono build, there's an element of truth here. People don't seem to get that .NET/mono is not native, and runs as bytecode on a VM. Does that sound even remotely familiar? Anyone? Bueller? Anyhow, I'm kinda sick of Unity cropping up everywhere. I understand Squad's reasons (it's a lot easier than rolling your own engine or using one of the big names, and cheaper to boot, especially back then) for selecting it, plus a lot of the other indie developers (same reasons as Squad), and maybe even for KSP2 (I don't know much about these new guys - just because it's a Take Two product doesn't mean it has TT's entire budget at it's disposal), but it is in no way an optimized, high-performance engine. Garbage-collected language will always have trouble in realtime: It really is Java-like: https://en.wikipedia.org/wiki/Common_Language_Runtime ..and I have a real hard time trusting anything from Microsoft. You know that old expression, "fool me once, shame on you, fool me five thousand, six hundred and eighty two times, I'm deeply effing idiotic and should really, REALLY stop trusting you!". Quite funny that Disco Elysium was held up as a graphically intense game. I think someone is confusing artistic talent with powerful graphics engines. Anyhow, I have kerbals to land on the newly textured planets...
  6. DStaal covered the explanation perfectly fine, but I'm going to add another thing: the limitations of parallel computing have been known since the sixties and seventies. "Get with the times" indeed. By the way, a slavish devotion to parallel computing can end up with a program that is not only NOT faster than the equivalent single threaded/serial processing equivalent, but also has the added bonus of requiring vastly more resources. Hooray! I'd also point out that Windows is egregiously bad at thread scheduling. I remember back in the SupCom days, when we'd manually assign threads to CPUs using CPU affinity to gain massive improvements in performance. So you could very well end up with some fat, bloated program that barely runs, which then gets scheduled to CPU #3 exclusively for no reason (well, except perhaps cache coherency, but you've just negated any advantage to being multithreaded in the first place)...
  7. Given that they've chosen Unity again, it should be fairly trivial to produce a Linux version. Unity only has two good points: Linux support. Relative paths for movable installations.
  8. Hey man, Thank you! I'd been going nuts trying to figure out how to re-enable the transparency since the 1.5.x thing. I had thought it was something I had done wrong, heh.
  9. Sorry for the "massive" necro, but I felt it important to add this to the discussion here, as this thread is the top link in my google results about "KSP .loadmeta". To expand on Snarks' point about reasons-not-apparent-to-the-consumer, I'd like to say it's likely that the way Unity (or the KSP codebase...or whatever is reading the save files) handles these .sfs files probably involves automatically parsing the whole thing on open in a manner that isn't easy to override. Putting the data in a separate file could very well then be a simple addition to the existing code, rather than having to rewrite a (potentially) large percentage of the load system. Furthermore, keep in mind that older versions of KSP won't expect the .sfs to start with a metadata stanza. It might be possible to embed it in comments at the start, etc, but that is considered poor form as comments aren't supposed to be machine-readable... BTW, the hash is what brought me here (it's a binary md5sum if anybody else is curious). I wonder why they didn't use mtimes though instead of a hash. Wouldn't have to read the whole .sfs file at all then
  10. I do believe we skipped the pre-release phase this time. Maybe it's showing? No amount of internal playtesting can even remotely come close to a pre-release...
  11. My earliest copy was bought in October of that year (and a second one in Nov or Dec, I forget). There are people who can't afford $15 though. Not many (most who can't, don't have a computer anyhow, especially not a KSP-ready one), but they do exist. For the vast majority though, yeah, it shouldn't be a major stumbling block.
  12. That's only in the states - in a lot of places (including Canada), incorrect police procedure only results in punishment for the officers involved/responsible, and does NOT invalidate the case. And you might find the current administration down there is less interested in procedure and more about results... By the way, since what you said does not constitute legal advice from an attorney (that's why I asked), it's also 'conjecture'. Heck actual legal advice is also conjecture too, although a degree of responsibility occurs in that case. I am indeed not an attorney either, nor offering legal advice, just some friendly conjecture based on my reading of the rules and situation. I'd have to say though, conjecture vs conjecture, I'm saying, "be super cautious with this, it could land you in hot water" and you're saying, "everything's fine, there's nothing to worry about". I dunno, but one of these sounds prudent and the other a bit reckless. Okay, here's the thing: 1. Fair use prevents you from infringing copyright when you have an unauthorized copy (and unless Take Two specifically authorizes it, it's unauthorized). 2. Without fair use's protection, all you're left with is..an unauthorized copy, which is copyright infringement. Which is a felony. 3. The law you quoted states that an agreement can nullify the protection of fair use. No more protection -> infringement -> felony. Again this isn't legal advice, but my conjecture, based on the reading presented and my knowledge of the law. And again, I'll point out that you're offering nothing but conjecture either. You can read about Fair Use and it's erosion at the hands of nasty things like the DMCA at the Electronic Freedom Foundation. They have dozens of articles about it. https://www.eff.org/deeplinks/2017/02/fair-use-consumer-protection Anyhow, enough of this crap, I have an expansion to play (which thankfully didn't present me with any sort of EULA. I'm taking people's word that the EULA they saw is the same one that appears on Take Two's site, as the application itself has never shown it to me, and the only thing I found in the installation directory was basically Creative Commons Attribution credits), and as much as I like teasing our hardworking moderators, they're probably getting seriously annoyed at this endless EULA talk by now, so good day sir. (or ma'am. or whatever you prefer).
  13. Indeed. Science badly needs an overhaul and the tech tree is .. still basically a placeholder. Even today, with the larger, heavier science tree, I think you can still fill it completely with the science from Kerbin's SOI. I actually liked it better when scientists couldn't reset experiments, and that you had to use the lab for that. Made it rather worthwhile without a huge science boost.
  14. Pretty much, yeah. The "game" has some serious balance and progression issues. Sandbox is basically fine in that respect (it's sandbox, it's supposed to be entirely user-driven goals, that's the whole point of a sandbox), but the career mode should be bringing challenge and progression to the table. And it's not. The rover thing is just a tiny piece of that issue. I'm hoping the DLC can change that, as I imagine the more skilled of the forum people are better at this than Squad ever was.