Bellefon.1259

You can disable the special functions (like mute, volume, screen brightness, etc.) so that your functions keys act like true function keys without having to press the Fn key at the same time. For Mac: System Prefs > Keyboard > check: "Use F1, F2, etc. keys as standard function keys" For Windows 10: Press the Fn key + Fn Lock key to disable the special functions The tradeoff is that you'd then need to then press Fn + F1 to toggle mute while playing the game.

I don’t recommend Boot Camp. It’s going to run very hot (BIOS can’t switch between integrated and discrete graphics, so the fans will run constantly if you have two cards); it’s going to take up a good chunk of drive space; it’s going to require applying constant Windows updates and troubleshooting them; and it’s going to wall you off from all your usual other third-party programs unless you redownload the Windows versions. CrossOver had been working for me since the February removal of the Mac client. But it and other Wine compatibility layers seems to require setup using the 32-bit Windows installer, which will be going away end of August. I don’t have the knowledge to manually create, customize, & troubleshoot a CrossOver bottle using the 64-bit client. Now I’m trying out GFN for the past few days. I don’t think either ANet or NVIDIA is going to provide any guarantees, but short of a business decision or bad corporate relations, there’s no technical-capability reason that GW2 on GeForce NOW would go away. But since ANet doesn’t reassure on these issues, and usually doesn’t provide more than 6-8 weeks notice on technical matters, there’s no need, as a consumer, to pre-purchase any sooner than the day before EoD is released.

A few others, including myself, are getting stuck in a failing patch loop. It may be related to something going on with the 32-bit client. If that applies to you, see this post: Game Starts and Closes and Repeats Over and Over

Thanks for the tip. I'd never created a hard link before, but it saved me 50gb of space. (For anyone else interested who's also inexperienced doing this, the hard link has to share the same name of "Gw2.dat" or the client will begin a full download.) I had gotten Karabiner-Elements to change option-to-alt, but I prefer your idea to edit user.reg since it keeps the alt-key change localized to the bottle running GW2 rather than changing it everywhere. Thanks for the instructions.

Excellent. Thanks for confirming that it worked for more than just me. Maybe it will help others who try CrossOver. I was wondering if Gw2.dat was platform agnostic. I was afraid to copy it in case Windows created a different .dat file than the one Mac created. This will save those with lower bandwidth some time if they can re-use a 50gb file. Hopefully someone with more tech knowledge than me can confirm. My performance with CrossOver is definitely worse than the native Mac client. But it was at least playable in PvE and PvP. I haven't tried in WvW yet, but I'm a little worried by the way my fps can drop to 8 just by turning. My mounts load in, but the movement animations can take 10-30 seconds to load in however. Could this be a difference between Intel vs. M1 given that GW2 was coded using early 2010s technology?

I had the same CoherentUI error at step 4. What worked for me was to navigate to the C drive of the Guild Wars 2 bottle (which was created after steps 2 & 3) and manually open the Gw2Setup.exe instead of letting CrossOver attempt to automatically do it. Because I opened the Setup.exe from within the bottle, and not from some other location, it seemed to work. Two ways to get to the C drive within the bottle: Right-click the bottle in the CrossOver UI > select "Open C: Drive" > look in both Program Files folders for the Setup exe fileManually navigate to the folder: ~/Library/Application Support/CrossOver/Bottles//drive_c/Program Files (x86)/Gw2Setup.exeI'll admit I'm a little unsure after-the-fact how I was able to install the 64-bit version by clicking what appears to be the 32-bit Setup exe, but I just used whatever the CrossOver app placed in the C drive folder after having confronted the CoherentUI error. The end result for me is that using the Gw2Setup.exe within Program Files (x86) installed the Gw2-64.exe, along with the 50gb Gw2.dat file, within Program Files in the drive_c folder. One more thing: After I successfully installed the Guild Wars 2 bottle, launching the app from within CrossOver would give me the CoherentUI error again and fail to launch the game. CrossOver's launcher icons, whether created automatically or manually, aren't working for me. So the workaround is that I navigate to the C Drive folder by clicking the "Run Command…" icon > Browse button > navigate to and select Gw2-64.exe > Run button. Not convenient, but so far has successfully launched every time for me. *note 1: I'm running Catalina on an Intel MacBookPro 16, 2019 -- hopefully M1 w/ Rosetta 2 would behave similarly *note 2: I've only been testing CrossOver for a couple of days now. It's working ok. Biggest annoyance I've found is that the option key does not translate to the alt key, so any control keys I'd set to using opt/alt no longer work, and I had to remap them. However, using alt-drag to split stacks in inventory isn't working, and there's no way to remap it in the GW2 UI. This is not a problem using the native Mac client, and it wasn't a problem when I ran GW2 in Boot Camp three years ago, so I wonder if this is a coding issue in CrossOver's GW2 implementation. If anyone has experience with running CrossOver using other apps – any tips on getting the alt key recognized?

For most gem store offerings, the bottom of their wiki page has a history of when they appeared in the store. The entry for the Istani Isles Mount Select License shows that it’s reappeared in times ranging from two to six months. It’s not predictive, but it seems due soon, if not during Wintersday, then maybe Jan/Feb.

Agree with replacing the mount ability 1 (not to be confused with engage skill 1) default “V” keybind with the “2” key. For anyone using their skyscale often, I’d add the suggestion to replace the mount ability 2 default “C” keybind with the “X” key. Reasons as relates to skyscale:X to descend is a natural fit with default X to swim down in water (and the keybinds won’t conflict/overwrite each other);X is as close to the spacebar as C, allowing your thumb to continue toggling between ascent/descent smoothly; andA bonus is that moving your thumb just above X to S allows you to move backwards to both unstick, or adjust your descent for precise landings, thus consolidating your up/down/back movements to your thumb along a truer diagonal alignment of spacebar/X/S. The “X” keybind logic is not as strong for griffon and beetle. For the griffon especially, the meaning of “rising” after “diving” is the opposite of “down”. Yet X is still not more arbitrary than C, so I see it as a nice refinement for heavy skyscale users. How odd. My 'X' key (default) mounts and unmounts my Mounts. So, overwriting it would surely mess me up, lol. You're right -- my bad. I've changed so many keybinds over the years that I forget Anet's original defaults. Looks like "swim down" is unassigned by default, and yes, X is mount/dismount.

Agree with replacing the mount ability 1 (not to be confused with engage skill 1) default “V” keybind with the “2” key. For anyone using their skyscale often, I’d add the suggestion to replace the mount ability 2 default “C” keybind with the “X” key. [EDIT: apologies — I’ve been reminded that X is Anet’s default for mount/dismount. I’d forgotten the original settings as I’ve been using X to swim down for several years now. Nonetheless, it still works for me.] Reasons as relates to skyscale: X to descend is a natural fit with default X to swim down in water (and the keybinds won’t conflict/overwrite each other);X is as close to the spacebar as C, allowing your thumb to continue toggling between ascent/descent smoothly; andA bonus is that moving your thumb just above X to S allows you to move backwards to both unstick, or adjust your descent for precise landings, thus consolidating your up/down/back movements to your thumb along a truer diagonal alignment of spacebar/X/S.The “X” keybind logic is not as strong for griffon and beetle. For the griffon especially, the meaning of “rising” after “diving” is the opposite of “down”. Yet X is still not more arbitrary than C, so I see it as a nice refinement for heavy skyscale users.

I’ve been trying this. I agree that casting shades makes little to no sense now, except maybe casual open world in specific cases where you can predict npc behavior. However, It’s hobbled and clunky to play as “melee” without melee capabilities. When adopting the no-F1-melee method, you don’t just lose the benefit of both Scourge minors. Two major traits aren’t worth taking as they depend on casting F1 (Desert Empowerment & Sadistic Searing.) And both one minor and one major are less effective as side effects (less Abrasive Grit barrier application, less Demonic Lore torment application.) Also kiss goodbye to the use-shroud-skill-1 in other trait lines. And in-shroud traits are blunted due to scourge-shroud’s short 3.5/6s set duration (e.g. less Shrouded Removal condition removal, less Unholy Sanctuary health regen, less effective Vampiric Presence). These in-shroud traits were true before the shroud change, they just seem more glaring now, and are worth pointing out as built-in trade-offs scourges had already. It was disingenuous of ANet to perform a major change on the mechanic, rather than just shaving numbers if a quick fix was direly needed before their future big balance, without also adjusting the Scourge trait line at the same time (while instead introducing a major update to Death Magic traits.) Yeah, we’re probably stuck with this now, but then they should have leaned into their concept. I’d rather we were all discussing a coherent change rather than a poorly conceived, unintegrated change that conflicts with it’s own elite line.

The terms “build” and “template”, as Anet is using them, aren’t matching common understandings. Many commenters have already caught on to this. Using the UI as a discussion point, Anet should have merged the “Build” tab with the “Equipment” tab to expand their current definition of build beyond just skills and traits, to also include equipment. (Rename a new tab for the nine other non-equipment categories sitting in the Equipment tab.) This enhanced build tab would now match most people’s idea of a complete build. On the right, three static game mode tabs that continue to dynamically adjust to your current mode (as before this update) —> PvE / WvW / PvP. These aren’t saved, as they aren’t now, thus not “templates,” which is tripping people up. Have something you like? Now save it to “Build templates” on the left (“Build template storage”), or apply saved build templates to your character’s mode tabs on the right. I’m aware this doesn’t address all the complexities (like legendaries, or the new equipment storage), but: it’s conceptually easier to understand;it would continue to automatically switch builds to modes (e.g., my most recent of my three PvP builds is loaded for me upon entering PvP lobby);it simplifies the hotkeys to include full build templates for the three modes; andit simplifies the monetization, thus lessening the cash-grab perception, by just selling extra template storage, instead of monetizing three (confusing) components, two of which aren’t actually templates.

Until then, for Mac users, adjust the cursor size:System Preferences > Accessibility > Display tab > adjust the “Cursor size” slider You can make it fairly large, much larger than the similar cursor-sizing option in Windows. And you’ll probably want to scale it down again when finished playing.

Try replacing the default skin with a custom skin -- worked for me, works for many, might work for you. I never have a problem with warclaw no matter how many people are around or how soon I've entered the map or waypointed. Here's more information from ten months ago --> About the Mount bug

Omg, thanks — confusing for veterans, too, lol. Good global change might be “Right-click tocustomize stats”.

Hadn't thought of that -- good idea, cause I keep accidentally casting shades. I propose if you cancel a shade that the time left on the shade goes towards its cool down. So you set a shade and let it sit for 10 seconds and then cancel it you would get a cool down reduction of the percentage left. In this case 33% cool down reduction. That way you could get another shade out more promptly. I think the ammo charge system already accounts for that by wrapping a CD (count recharge) around a CD (skill use). As long as all 3 manifest shade charges haven't been used up, a shade is always ready to be cast. If a scourge casts only one, but then removes it, they've lost the advantage of coverage (which is the problem Anet claims to want to solve?), but can cast a new shade quickly. If all three were cast, removal (of all shades) doesn't need to affect the count recharge -- the scourge has to wait for recharge to cast shades again, using the same system. So it's a tactical choice about where the dmg/support/defense happens, not about being stuck in range vs. melee mode for 15s.

And yet it’s still so easy for the enemy to see the defcon-level-10 solid-red circle on the ground. This really needs to revert to the previous animation now. The enemy shouldn’t have such a braindead way of spotting shades when they telegraph that the scourge is now defenseless or trapped. I’m experimenting with never casting shades again (sigh), basically a melee style of play, in order to maintain self-defense. Unfortunately, this basically nullifies all traits dependent on casting manifest and shroud skill 1. Which suggests a fourth solution — remove ground-targeted placeable shades. Let the necro always be the shade, and F1 triggers it’s same effects with charges. So scourges lose range, but maintain self-defence, and can still cast F1 (at close range) to keep all the shroud-skill-1 traits relevant. It’s sad when a class-defining ability has a harsh built-in disincentive to actually use it. Imagine, rangers lose half of their remaining health while their pet attacks! Imagine, thieves lose initiative for every second in stealth! (P.S. — I actually prefer a way remove shades, just thinking through options.)

It's not buffed in WvW. Its damage at a range is... sorta buffed because it hits more people. However, what made scourge truly bad in WvW was the fact that it was able to support its sub squad with barrier pulses from sand shade at the same time as dealing all of its damage. It did all the DPS with absolutely zero sacrifice in utility. I specifically ran a power burst blood/barrier scourge that did easily 20-30k aoe damage bursts while still applying barrier to my entire havoc. THIS is what made them broken in WvW... HOWEVER... most of that barrier came from sand shade pulses of some kind. By making the necro pulse zero of the sand shade skills on itself once a shade is placed, it forces you to choose between support and damage rather than getting both at once all the time with no effort. At BEST you can place two small shades away and one next to you but it still won't provide near the damage or support that big shade bombs did in WvW previously. And for the condi builds, you have to invest pretty heavily in to condi damage, which means you're not taking the barrier skills. This is a definite step in the right direction. The choice isn’t so much between support OR damage, since a ranged shade can still do both. The choice is between personal sustain/defense or ranged support/damage. The lack of mobility, blocks, and invulns for necro is justified by the second health bar, which scourge lacks. Barrier’s the crucial compensation for scourge, yet now unavailable when playing ranged? (Imagine rangers losing 50% of their armor rating and being immune to protection while using a bow.) Your “at best” scenario means that a shade next to or on the scourge is a 15-second prison, over and over again. Step out of it and lose access to reliable self-barrier and cleanse, so an already low-mobility class has to stand still to hardly survive while becoming as juicy of a target as any downed player. Get knocked out of shade and lose self-shade skills. While the scourge is not also the shade, it’s highly vulnerable to both melee and ranged attacks. The more plausible scenario is scourges will need to become extremely stingy about casting their shades in order to survive, perhaps not casting, or maybe creating a personal path of shades during melee combat, which is possible only by saving them up and not casting them ranged. But that’s still basically telegraphing positioning, and only making the prison slightly larger. (Generally speaking, not including that one specific WvW zerg build you mention, which could have been dealt with, specifically.) Also, less use of shades basically nullifies three traits explicitly triggered by placing shades (F1). Anet did not clarify the details of exactly how the 22 other shroud-based traits (not counting the reaper trait line) interact with scourge now, but if “shade skills will only fire around them when they do NOT have a shade up”, it’s unclear how that will work. How will Path of Corruption work if a shade is 600u away and F2 doesn’t fire? If F5 doesn’t fire around the necro, will it fail to trigger Spiteful Spirit or Weakening Shroud? Or is the scourge in a quasi-trait-granting shroudness which is not shroud? It’s unclear.

This change seems to punish scourges for using their unique elite specialization mechanic. It discourages using shade skills at range, and seems to favor scourges as melee fighters without having good melee skills. Fighting that ranger? — don’t shade them or lose significant defense from arrows and pets. Chain stunned by warrior/engi? — won’t be able to activate shade on yourself due to cast time, therefore locked out of all F shade skills until other shades disappear. Shroud is the infamous "second health bar" that compensates necros for their lack of mobility/blocks/evades. Scourges don't have shroud, but rely on barrier, the 5-second health bar topper. Placing a shade anywhere but on top of the scourge is a 15-second lockout from having any local use of shade skills = less barrier = less defense. Hoping this gets a harder look before release, but if not, then please also consider: removing the 1/2 sec cast time to Manifest Sand Shade (F1), allowing faster re-positioning, making the choice one of "here or there but not multiple locations";removing the 1/2 sec activation delay that was later added to shade skills (F2-F5) to compensate for time needed to reposition shades; andmaybe modifing Manifest Sand Shade (F1) to be a single-shade toggle (eliminating 3 shades): press once to place, and while shade still exists, press again to remove shade, thus making necro act as the shade — thus giving a controlled choice about where shades activate.One more thing: I have to assume, without testing, that since Garrish Pillar (F4) won’t activate near the scourge if they are not on an active shade, or have no shades active, (edit: double-negative usage error) seems like traited Transfusion won’t activate either? Experimentation is fine. I can’t judge Death Magic yet, so I'm open to exploring. Maybe it will be awesome, maybe a one week experiment to experience baseline leather-class armor. Rather than have to think about sitting in my shades, thus limiting mobility further, sadly, I’ve already begun to train myself to never press F1 again.

Necromancers' minions don't generally inherit necromancers' stats. "A minion has a fixed amount of health, damage, and armor…" -- wiki. The few stats they do inherit (condi dmg, condi duration, and boon duration) are basically useless unless traited in Death Magic by a condi necro. The reference in the notes: "Fixed an issue that caused this trait to use the minion's stats instead of the necromancer's." only pertains to a trait bug, and even then I'm not really sure what the issue was, unless minions only inherit a percentage of the necro's condi dmg/dur.

From the link, this was my case --> "If you were using the current Guild Wars 2 client for Mac, but haven’t upgraded to MacOS Catalina, simply launch your client and it will update automatically to the 64-bit client!" Also, the old 32-bit client, as well as old transgaming preference and cache files, were deleted from my computer. Yet I'm still getting fairly frequent crashes since the patch: some with the "Send report to Anet" overlay that subsequently closes the client, some with black-screen or psychedelic magic-eye screens that require me to force-quit the client. My first step was to confirm that I'm using the updated client. Using "Get Info" on Guild Wars 2 64-bit.app displays a March 2017 creation date, and a June 2017 modified date. Since my 64-bit Mac client was freshly downloaded from Anet on Nov. 2018, it's evident that the 2017 version was Anet's previous most recent version of the client at the time that I'd downloaded in 2018. So do the dates indicate that my client failed to auto-update? Or is this just a case of old metadata associated with the newest client? How do I verify that this auto-update occurred and that I'm actually using the new 64-bit Mac client? Our engine programmer James Fulop wanted to share this with you, let us know what you see based on these instructions: “Get Info” on the .app isn’t going to provide an accurate date of the last patch time. All of the patching happens on files within the .app.If you are using the 64-bit client, and can see the launcher page with the Play button, then you have patched forward successfully and have done everything you need to regarding Apple’s 32-bit deprecation. Guild Wars 2 does not allow people with an outdated client to play. If you want to be absolutely sure, you can run the following command in the terminal. (note that your installation path may be slightly different from mine) file /Applications/Guild\ Wars\ 2\ 64-bit.app/Contents/MacOS/bin64/CoherentUI_Host The output should look like /Applications/Guild\ Wars\ 2\ 64-bit.app/Contents/MacOS/bin64/CoherentUI_Host: Mach-0 64-bit executable x86_64 if it says i386 instead of x86_64, then something is going wrong ? We have also replaced the download for the 64-bit client build available on our website this week, so I recommend people try to re-install from that if they can’t get up to the Play button launcher screen. Regarding the graphical problems, please report in screenshots when your client has the black screen or psychedelic eye-magic. A current workaround that often fixes these graphical problems, without restarting the client, is to resize the window if in windowed mode, or change resolutions in Graphics Options if you are in full screen. Just wanna throw this out for people... You can click your Apple Button, goto About This Mac, click on System Report, and then scroll down and click on Applications under the Software heading. This will bring up a list of all your applications and has a column showing whether or not they are 64 bit.I (and many of us) had already been using 64-bit Mac client (available since June 2017), so the System Report method wasn't going to tell me which 64-bit client I had. I asked how to double-check that I'd received the upgraded 64-bit Mac client that was part of the "Bound by Blood" patch. However, the System Report is a great way to get an overview of all your 32-bit apps that you can't use with Catalina OS.

Just let go of the key/mouse you use for forward movement all together and you will be unstuck. Alternatively, you can hold the space bar for a short time then let go to jump up and with some refilled flight juice. That uses Endurance just like dodge on an unmounted character. tl:dr Stop pressing whatever key/mouse button you use to move forward and you will release from the wall instantly. I'd prefer stick to wall not be bound to a key as I like it the way it is. Just stop pressing the forward key and unstuck. That said, I can live with it either way. Usually you have to hold (W) forward to cling, and in those cases, the suggestion to either let go of keys/mouse or perform a wall launch are fine. But if persistently stuck to walls or thin trees, best to (S) move backward in order to un-stick. No wasted flight juice, and no lost altitude. Was very frustrating at first because my initial impulse was to try to steer away, and that wasn’t working. Second thing, when you’re trying to get to something fast, or get away from something fast (hydras), resist the urge to immediately go forward again and re-stick.

Same issue with Mac users not seeing the marks on the table discussed in this thread: Malice's Code Bug As it's becoming clear that this is not related to completing the story, at this point, probably the best two things to do: Report using the in-game bug report feature (/bug) while standing at the table, giving Mac model, OS X version, and GW2 client version; andJoin LFG, usually named something like "tree code" or "last POI", to complete the map/daily.

On Mac, same issue. In addition to the terrain, I also fiddled with the environmental settings, but still can't see the markings at all.

For me, the earlier mounts aren't "fixed" -- I can recreate the half-buried-in-ground-and-stuck effect just by switching back to the default skins on any of them. So I have to agree with perilisk. However, there's still disagreement about whether the issue is actually internet bandwidth, latency, map-loading priority, or player population. So test it to see if this applies to your situation. Pick a mount(s) with a custom skin that you use often, revert back to the default skin. If you bug out again on that mount (~20% of the time for me), a custom skyscale skin is your solution. PS -- When I use custom skins, I mount successfully every time, though I might still see the default skin for about 1-5 seconds before the custom skin is viewable.

From the link, this was my case --> "If you were using the current Guild Wars 2 client for Mac, but haven’t upgraded to MacOS Catalina, simply launch your client and it will update automatically to the 64-bit client!" Also, the old 32-bit client, as well as old transgaming preference and cache files, were deleted from my computer. Yet I'm still getting fairly frequent crashes since the patch: some with the "Send report to Anet" overlay that subsequently closes the client, some with black-screen or psychedelic magic-eye screens that require me to force-quit the client. My first step was to confirm that I'm using the updated client. Using "Get Info" on Guild Wars 2 64-bit.app displays a March 2017 creation date, and a June 2017 modified date. Since my 64-bit Mac client was freshly downloaded from Anet on Nov. 2018, it's evident that the 2017 version was Anet's previous most recent version of the client at the time that I'd downloaded in 2018. So do the dates indicate that my client failed to auto-update? Or is this just a case of old metadata associated with the newest client? How do I verify that this auto-update occurred and that I'm actually using the new 64-bit Mac client? Our engine programmer James Fulop wanted to share this with you, let us know what you see based on these instructions: “Get Info” on the .app isn’t going to provide an accurate date of the last patch time. All of the patching happens on files within the .app.If you are using the 64-bit client, and can see the launcher page with the Play button, then you have patched forward successfully and have done everything you need to regarding Apple’s 32-bit deprecation. Guild Wars 2 does not allow people with an outdated client to play. If you want to be absolutely sure, you can run the following command in the terminal. (note that your installation path may be slightly different from mine) file /Applications/Guild\ Wars\ 2\ 64-bit.app/Contents/MacOS/bin64/CoherentUI_Host The output should look like /Applications/Guild\ Wars\ 2\ 64-bit.app/Contents/MacOS/bin64/CoherentUI_Host: Mach-0 64-bit executable x86_64 if it says i386 instead of x86_64, then something is going wrong ? We have also replaced the download for the 64-bit client build available on our website this week, so I recommend people try to re-install from that if they can’t get up to the Play button launcher screen. Regarding the graphical problems, please report in screenshots when your client has the black screen or psychedelic eye-magic. A current workaround that often fixes these graphical problems, without restarting the client, is to resize the window if in windowed mode, or change resolutions in Graphics Options if you are in full screen.Thanks, that helped confirm that I’m running the updated client, as I’m both getting to the Play button on the launcher, and the Terminal command returned that exact result: Mach-O 64-bit executable x86_64. So I can rule out an outdated client as the problem. I’ll try to make screenshots of the crazy screens as they occur.