EagleDelta.4726

More likely the option is still a part of the CLI launch options and just either is ignored or redirects to DX11. Pretty common practice in all of tech... usually as a way to roll back changes if necessary until they are sure they don't need the option at all anymore. Also usually done so that a deprecated/discontinued option doesn't break someone's launcher/scripts/Steam launch options/etc when the option is removed

I am also a Software Engineer and most of the software I work on can't just be "Turn it off, turn it back on." Additionally, the reality is on the backend, we aren't looking for the "next new thing" most of the time. In most cases, it comes down to "Customers have requested X problem be fixed, so we will task you with finding the solution." That is exactly part of the problem here. Players have complained for years about performance and the upgrading the engine from a 20-year old GFX API to a newer one like DX11, DX12, or Vulkan would help. ANet finally does that, but it has caveats/requirements for being able to complete that work. There are realities that go beyond just ANET. 1. Software companies are bound by Hardware companies' decisions. If GFX vendors are starting to remove or simply not include DX9 support, then it's probably better for games to start migrating away if they are still in development. Sure, DXVK works, but it wasn't designed for Windows. 2. Older software always has very real security and stability risks. Many of these are not usually visible to a user of the software and tend to HAVE to be fixed. Sometimes, especially in older software (like games using a 20-year old GFX API), the likelihood of those fixes breaking something goes up dramatically. It's also why in many newer tech companies, the design is to move much faster, with smaller changes, "fail fast", and so many other simple techniques. To try and balance the need for staying ahead of bugs and vulnerabilities while limiting impact of new bugs and issues in the process. 3. They are also bound by any vendor they use for their tooling. For example, if Microsoft takes their IIS product to End of Life, then ANET would eventually have to replace it with something else, like NGINX or Apache2. That doesn't just apply to corporation-maintained software either, Open Source projects regularly take versions of their software to End of Life and end support for anything running on it. All of these come in the form of what we call "Risk" and it has to be managed or risk something really bad happening to the company or to the customer. I do understand the tongue-in-cheek mention of "Turn it off and back on again", but I'll also note that generally works best for issues related to Operating System problems that mess with the ability to launch/run/manage running applications. Rarely does "Turn it off and back on again" work for my apps, dev environment, services, etc. It's usually a core problem with something interacting with the OS or with the system's hardware (or some combination of both), be it in "User Space" or at the Kernel level (not going to get into my rant about how bad and dangerous Kernel-level anti-cheat is). My point is that most Software Engineers I've worked with over the last 15 years have not tried moving to new things just for the sake of moving or chasing something "shiny", but to solve very real problems. And most of the time that means tradeoffs that will make some users happy and others really angry. IT Crowd is a hilarious show!

I imagine they will remove the option at some point. DX9 is 20 years old, which in "tech years" is about 90-100+ years old. It's likely that nothing on your computer, except DX9 games, is running software that old (that hasn't been modernized in some way). Adding that some newer video card drivers are removing support for DX9 entirely (they maintain compatibility by using tools like DXVK, which while it can be used with Windows, was designed for converting DX9/10/11 calls to Vulkan on Linux).

Whatever you think suites you best. I, personally, like the Ubuntu-based Pop!_OS. Primarily because it is maintained by a Laptop/Desktop OEM (System76) and has a hefty focus on desktop users. That or Manjaro is pretty user-friendly as well

Never used Lutris so no idea how it actually works. I did check the game's page though and apparently someone wrote an install script (click - show unpublished installers) which configures Wine in a similar way to my package. Seem to be a job well done too I must say :) That was me, though I haven't messed with it in a while

@ArmoredVehicle.2849 Are you ok with me re-hosting your tarballs in a Github releases page so that I can have my lutris installer just download your, unpack, and run the installer for super easy setup. If there's anything (I.E. the GW2 install binary) that needs to be removed, I can remove and repack the tarball

I can see why this is annoying, but isn't this the very purpose of the spec? To prevent/strip boons?

Software Dev here - you can't get brand new things every release. It would leave no time for anything else and would create the content and feature wastelands that most MMOs have today (WoW Garrisons, Class Halls, Ancient Weapons, etc). A ton of dev work is also never, ever seen by the users/players themselves as it's things behind the scenes: Critical Bug fixes that they identify during development and fix before players have to run into them.Testing to try and find more bugs that they don't know about yet.Foundation for future content, features, mechanics.Non-functional changes (I.E. changes that don't actually change anything, but just clean up or simplify existing code)And much more..... in addition to the content itself (Instances, Achievement "Quests", Map content, etc).What I see people wanting all the time: New RaidsNew + Longer Story/Map contentNew unique MasteriesNew MechanicsNew FractalsExisting content to not be made obsolete by new contentProfession Changes/Elite SpecsStabilization of Engine/move to DX12/VulkanProblem is that 4 conflicts with both #6 and #73 conflicts with #61 and #5 don't conflict but aren't necessarily in tandem with #28 is such a monumental task that it conflicts with them all.Basically there are 8 things up there (no counting WvW and PvP)..... pick 3 of them and compare them with the other thousands to millions of active players.... how many of us share the same content priorities. (This is a common saying in Software Dev/Systems Admin: "You want faster, cheaper, and secure? You can only have 2") Point is, they prioritize work based on the data they have about players combined with the direction they want to take the game. They have far more data about what players want/do than any of us ever will. Just because there's a vocal group online, doesn't mean the entire game is falling over. As an aside, I'm not too keen on brand new mechanics anyway. Why would I want to NOT play my profession just to mess with some shiny mechanic that will only be around for a 1-2 maps.

I will take a look at any changes you made and work on updating the Lutris installers of necessary

What coming here to say the same thing. @ArmoredVehicle.2849 - D9VK is no longer a standalone project. It has been merged into DXVK as of DXVK 1.5

The wine build in my package is a straight off Wine + Staging patches applied, my own stuff are the various scripts and the pre-configured prefix, hope that clears it up :) That's what I figured. I will be updating the installers I have with your arcdps and radial script(s) for post installation runs, but other than that, it's mostly the same just with the play.sh replaced by the traditional execing wine + game exe since Lutris can handle the env vars.

@ArmoredVehicle.2849 is there anyway to get the wine fork you build for this available as a tarball or on Github? I want to create a Lutris installer for your version and want to submit your build as a Lutris wine version NEVERMIND: Looks like most of the patches you use are included in the lutris-4.21 build of WINE.

So looks like with the latest build the crashing when changing dynamic HUD settings has stopped. When you say the latest build, are you referring to a game update or the Linux package update I've recently released? :)Yes ;)

So looks like with the latest build the crashing when changing dynamic HUD settings has stopped.

@ArmoredVehicle.2849 Anyone note the issue where the game will crash if you try and modify dynamic HUD settings while logged into a Character? It works fine when on the character select, but crashes if changes are made after selecting a character