Currently studying CS and some other stuff. Best known for previously being top 50 (OCE) in LoL, expert RoN modder, and creator of RoN:EE’s community patch (CBP).

(header photo by Brian Maffitt)

  • 2 Posts
  • 52 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle


  • Thanks for so politely and cordially sharing that information


    edit: I would be even more appreciative if it were true: https://www.rockpapershotgun.com/rocket-league-ending-mac-and-linux-support-because-they-represent-less-than-0-3-of-active-players

    Quoting their statement:

    Regarding our decision to end support for macOS and Linux:

    Rocket League is an evolving game, and part of that evolution is keeping our game client up to date with modern features. As part of that evolution, we’ll be updating our Windows version from 32-bit to 64-bit later this year, as well as updating to DirectX 11 from DirectX 9.

    There are multiple reasons for this change, but the primary one is that there are new types of content and features we’d like to develop, but cannot support on DirectX 9. This means when we fully release DX11 on Windows, we’ll no longer support DX9 as it will be incompatible with future content.

    Unfortunately, our macOS and Linux native clients depend on our DX9 implementation for their OpenGL renderer to function. When we stop supporting DX9, those clients stop working. To keep these versions functional, we would need to invest significant additional time and resources in a replacement rendering pipeline such as Metal on macOS or Vulkan/OpenGL4 on Linux. We’d also need to invest perpetual support to ensure new content and releases work as intended on those replacement pipelines.

    The number of active players on macOS and Linux combined represents less than 0.3% of our active player base. Given that, we cannot justify the additional and ongoing investment in developing native clients for those platforms, especially when viable workarounds exist like Bootcamp or Wine to keep those users playing.









  • Intel fumbled hard with some of their recent NICs including the I225-V,[1][2] which took them multiple hardware revisions in addition to software updates to fix.

    AMD also had to be dragged kicking and screaming to support earlier AM4 motherboard buyers to upgrade to Ryzen 5000 chips,[3][4] and basically lied to buyers about support for sTRX4, requiring an upgrade from the earlier TR4 to support third-gen Threadripper but at least committing to “long-term” longevity in return.[5][6] They then turned around and released no new CPUs for the chipset platform, leaving people stranded on it despite the earlier promises.[7]

    I know it’s appealing to blindly trust one company’s products (or specific lineup of products) because it simplifies buying decisions, but no company or person is infallible (and companies in particular are generally going to profit-max even at your expense). Blindly trusting one unfortunately does not reliably lead to good outcomes for end-users.


    edit: “chipset” (incorrectly implying TRX40) changed to “platform” (correctly implying sTRX4); added explicit mention of “AM4” in the context of the early motherboard buyers.








  • Rise of Nations (originally released back in 2003) had/has some interesting ideas to reduce some of the busywork:

    • Worker units will automatically try to gather/build nearby after a short (configurable) delay if they’re not doing anything.
    • Cities (the main worker-producing structure) has a rally point option that’s essentially “all nearby empty resource gathering”, so you can queue a dozen workers and they’ll distribute themselves as they’re created.
    • Production buildings can be set to loop over their current queue, letting you build continually without intervention as long as you maintain enough resources each time the queue “restocks”.
    • Units that engage in combat without being given an explicit target will try (with modest success) to aim for nearby units which they counter.

    For the most part, none of the implemented options are strictly better than micromanaging them yourself:

    • You will always spend less time idling workers if you micromanage them yourself.
    • The auto-rally-point doesn’t always prioritize the resources that you would if you did it yourself.
    • Queueing additional units is slightly less resource-efficient than only building one thing at a time.
    • Total DPS is higher if you manually micro effectively.

    But the options are there when you need them, which I think is a a nice design. It doesn’t completely remove best-in-class players being rewarded for their speed as a player, but does raise the “speed floor”, allowing slower players to get more bang for their buck APM-wise, and compete a bit more on the strategy/tactics side of the game instead.





  • My quote is not the only content of the video; I’ve just included most of the introduction. The 13:23 long video has the following chapter markers:

    00:00 Introduction 00:50 How was DOOM originally described? 02:20 DOOM clones 04:33 Quake Killers 6:06 A hypothetical question 12:05 Conclusion

    Only the first half of the video is accurately described by your suggested title. The video as a whole is described by the existing title with reasonable accuracy. It’s not a bait-and-switch: the video also discusses what genre DOOM is, not only what genre DOOM was.

    It seems that you (and many others) have used a heuristic of “clickbait-y sounding titles don’t accurately describe the contents of videos” and left corresponding comments. Although often accurate, that heuristic has failed in this instance.