Jump to content
  • Sign Up

tails.4209

Members
  • Posts

    35
  • Joined

  • Last visited

Posts posted by tails.4209

  1. Account: tails.4209

    From: Sorrow's Furnace 

    Current Team: First Haven

    Expected Team: Seven Pines

    WvW Guild: MODE

    I had to leave my regular WvW guild JADE to join our guild's alliance guild (for the love of God, give us a guild slot). Selected MODE as my WvW guild last night before the deadline but it still showed pending. Today, didn't seem like it put me with guildies in the MODE alliance guild.

     

    Edit: Forgot to update. Not sure if was moved manually, but I logged on on Saturday to check and I was moved to the right team!

  2. It seems like the WvW Guild selection was reset or not remembered at some point during the first week of the beta. It was selected prior to the start of the first week of the beta. Guildie mentioned it in our Discord but I didn't see the message until today. The UI on the WvW window to select WvW guild doesn't work and the UI in the Guild window to set WvW guild also doesn't work. It seems guild selection is already locked for the second week of the beta. Praying that it's just a UI bug so I can still be in the same team as my guild. It seems like we can't trust GW2 to remember our guild selection week to week even though the guild selection from previous betas seem to be retained. This is like pre-Alpha quality...

    • Like 3
  3. I finally bit the bullet and installed lutris and its dependencies instead of running my system wine natively. I used the lutris install script from lutris.net, interrupted the install and in the wine prefix, symlinked my already installed and fully patched GW2 (I dual-booted into Windows briefly to run raids). Things seem to be working well so far...Even trading post and guild panel seems to work...

    Lutris: lutris-0.5.10.1

    Wine Version: lutris-GE-Proton7-1-x86_64

    Video drivers: nvidia-drivers-510.73.05-r1

    Using DX11

  4. Had a working setup with wine-staging-6.16 and dxvk-1.10.1. However, with the latest patch, the game crashes on login screen. I see this in the console window when this happens:

    Quote

    031c:fixme:vulkan:X11DRV_vkCreateWin32SurfaceKHR Application requires child window rendering, which is not implemented yet!

    Not sure if this is what's causing the crash with CoherentUI, but maybe something along the lines of CoherentUI change causing the Vulkan translation in dxvk to use an unimplemented rendering feature in wine. CoherentUI didn't like that it failed and crashes, maybe? I found a reference to this wine bug but can't try the patch at the moment: https://bugs.winehq.org/show_bug.cgi?id=45277

     

    Without dxvk, I was able to log in and play. It's not using the dxvk vulkan translation, so it doesn't require child window rendering. Obviously performance took a nosedive without dxvk.

    Edit: Looks like a patch to implement child window rendering was included in wine-ge-custom. So that probably addresses one of the issues...

  5. I've had pretty good performance with DX9, wine-staging, and dxvk even in huge WvW zerg fights. However. when I moved from wine-staging-6.9 to wine-staging-7.2, performance takes a huge dive during the same fights. I've seen FPS drop to 1fps. This aligns with a huge ping spike. It's probably a long shot, but does anyone know what might affect performance between the 2 wine versions? Is there an option I can try?

  6. It's more than that just Dragonstorm. There's been more occurrences of inconsistent rendering since EoD launch even with DX9. Some AoEs (e.g. vomit under giants in Harvest Temple and field underneath Ankaa in Junkyard) and telegraph circles (e.g. slam/wave attack during Dragon's End meta) won't render the first time they hit. I have a feeling it's probably to do with asset loading performance. Is your gw2.dat file on an SSD? I'm still running into the same issues with an SSD but I feel the frequency is less compared to my mechanical drive friends.

  7. For some maps like Queensdale, there are many places where the skiff can easily run aground when following water. I don't know if it's worth making those areas deeper, but it's pretty annoying trying to go down certain rivers. For example, sailing from Western Divinity Dam to Lake Delavan to Eastern Divinity Dam in Queensdale is difficult if not impossible.

  8. Quote

    We can deduce this because 1) some players unaffected in beta 2 got affected in beta 3 and 2) they told us what happened in beta 2 and if it was the same cause in beta 3 don't you think they would have told us that already?

    1) It is entirely possible that it's the same issue but some were lucky to not get hit by it in beta 2 but unlucky in beta 3.

    2) We're not entitled to any explanation, though I would be very interested in a postmortem. It could very well be the same cause but they are now embarrassed to admit it. I'm concerned if they are just shooting off betas to meet some schedule set by management for betas instead of actually taking the time to develop a beta worth testing. Releasing a known buggy beta to the masses just wastes developer time. 

     

    Quote

    I'm just not seeing any real reason to get aggravated by the bugs of the beta tests.  I don't know if anyone recalls, even if Anet recalls, back when server links were implemented there was some forum post putting the entire WvW game mode into a "beta status" and I can't recall an announcement ever taking it out of that status.

    I wouldn't be annoyed if it was opt-in and there's an option for users to go back to the old system. Maybe they don't want to invest in parallel WvW infrastructure for beta testing. However, if WvW is in long-term beta status like you implied, then it would be a pretty easy cost to justify.

  9. 22 hours ago, Custodio.6134 said:

    just as i said multiple times in similar or related threads: 

    1. a beta is made to test things, find bugs, and to find out if an attempt to fix an already known bug results in the desired effect. Additionally, it doesn´t matter if a bug repeatedly appears in a beta, as long as it gets fixed before the final release. 
    2. especially the "wrong team assignment-bug" is kind of a tricky one. It requires a big sample size to reproduce, and (because of that) is most likely hard to reproduce in a simulated environment (which as a result makes it harder to fix)

    1. Considering the wrong team bug affects the experience of users for a core feature without any sort of workaround, I would argue it's high severity. And it does affect some number of users. A high severity bug affecting a fair number of users should be a release blocker for betas. They had a chance in beta 2 to fix it and add enough debug info to verify it's been fixed. Most of the issues were found in beta 1. We're at beta 3 and the same bugs are still showing up.

     

    2. That reasoning is acceptable for beta 1. Probably acceptable for beta 2. By beta 3, they should have identified the gaps in their test coverage. Space out the time between beta more if more time and investment is needed to get test coverage in place.

  10. 1 minute ago, Chaba.5410 said:

    What do you propose should happen if the use of such a tool makes the problem worse?  Then you end up having to fix not only the cause of the problem, but any secondary problems.  My point only is that it isn't always a simple thing.

    I think the same logic that excuses issues with the beta can excuse any issues caused by attempted fixes with a tool. It's a beta.

×
×
  • Create New...