Bellefon.1259

> @"Lord Warfin.1209" said:

> I still have the Mac client installed and created a hard link to the Gw2.dat file from the Mac version in the Windows version so they share the same 50GB database.

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.)

> There is a way to get the option keys to work as alt. I've run into this same issue before with Wine and it's a matter of figuring out where to put the options. In this case the file is: ~/Library/Application Support/Crossover/Bottles/your GW2 bottle name/user.reg

>

> Add the following lines:

>

> [software\\\Wine\\\Mac Driver]

> "LeftOptionIsAlt"="y"

> "RightOptionIsAlt"="y"

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.

> @"Qida.5648" said:

> I tried your suggestion and it works on the M1 Mac! Thank you.

Excellent. Thanks for confirming that it worked for more than just me. Maybe it will help others who try CrossOver.

> Although I still ran into issue when downloading the GW2.dat file.. It still crashes after downloading 5% - 10%, then have to restart, but at least the progress is not loss.

> So instead of downloading, I open my MacOS GW2 version (view package content, copy the GW2.dat into the bottle) And it works.

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.

> In terms of performance. crossover seems to be bad. My mount would disappear and suddenly load in, (Something I always encounter when I used to play on a surface go tablet).

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?

> @"Qida.5648" said:

> I tried CrossOver. Does not work IMO. Maybe someone here have a suggestion on how to get it to work?

> 1. I install CrossOver (20)

> 2. Select Application (Guildwars2)

> 3. They auto select Windows 7 64bit bottle.. install 64bit GW2 client.

> 4. Then i hit the CoherentUI error issue.

> 5. So i set command run -32 (32bit)

> 6. The download for the client begins.. but keep crashing after a short download.. So i give up there.

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:

1. Right-click the bottle in the CrossOver UI > select "Open C: Drive" > look in both Program Files folders for the Setup exe file

2. Manually navigate to the folder: ~/Library/Application Support/CrossOver/Bottles//drive_c/Program Files (x86)/Gw2Setup.exe

I'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](https://wiki.guildwars2.com/wiki/Istani_Isles_Mount_Select_License#Gem_Store_history) 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.

> @"Inculpatus cedo.9234" said:

> > @"Bellefon.1259" said:

> > > @"LucianDK.8615" said:

> > > Its mount ability 1 you want to bind to a better key to use dash, ive set it to button 2 and 3. And button 1 will always be the firebreath/dive button. Much better access than to have it on V.

> >

> > 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; and

> > - A 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.

> @"LucianDK.8615" said:

> Its mount ability 1 you want to bind to a better key to use dash, ive set it to button 2 and 3. And button 1 will always be the firebreath/dive button. Much better access than to have it on V.

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; and

- A 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.

> @"Dadnir.5038" said:

> For PvE, I can only give you a tip which is the "lesser evil": Don't use F1, play at melee range.

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.

> ANet seldom go back on change they've made, so I wouln't have my hopes high if I were you, just adapt your PvE gameplay like I suggest if you really want to stick to the scourge there. You totally lose the power of your minor traits but it's a "viable" casual gameplay.

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; and

- it 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](https://en-forum.guildwars2.com/discussion/66904/about-the-mount-bug-not-loading-and-character-stuck-sitting-in-the-ground-a-band-aid-solution "https://en-forum.guildwars2.com/discussion/66904/about-the-mount-bug-not-loading-and-character-stuck-sitting-in-the-ground-a-band-aid-solution")

> @"Kunzaito.8169" said:

> Could be very confusing for new players who don't realize you have to right click the item and choose "customize" now.

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

customize stats”.

> @"Excursion.9752" said:

> > @"Bellefon.1259" said:

> > 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.

> I actually started contemplating that myself. Or moving it to an off key that I can use when need be.

Hadn't thought of that -- good idea, cause I keep accidentally casting shades.

> > (P.S. — I actually prefer a way remove shades, just thinking through options.)

> I guess it all depends on how it could be fixed. On one hand you would be able to remove the shade and enable to use your character. But on the other hand you would have the long cool down for the next charge.

>

> 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.

> @"Excursion.9752" said:

> Its no mystery I was in a Zerg and when two or three servers meet up it is very hard to keep track of where you placed your last Sand Shade after you have evaded a few times. There is so much on screen clutter it gets lost in the mess.

>

> Not to mention now we are locked into 15 seconds in one spot that no one will be standing in.

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.

> Without having a way to remove the shade it basically makes our F-Skills temporarily useless until the shade either goes away or we get charge to drop another.

>

> So if this is the way its going to be one of three things need to occur. A way to remove the shade, greatly decrease the cool down timer on manifest sand shade, or decrease the duration for WvW & PvP of a shade to 5 seconds.

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.)

> @"Sojourner.4621" said:

> > @"Jasonbdj.4021" said:

> > RIP scourge, ANet did the opposite that people asked for nerfing it in PvE and PvP more but buffed in WvW.

>

> 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.

> @"Irenio CalmonHuang.2048" said:

> ### Necromancer

>

> The scourge elite specialization has also undergone a significant change such that its shade skills will only fire around them when they do NOT have a shade up.

> This change creates a choice between whether scourges expose themselves to some melee risk but charge in to affect foes around them, or whether they hang back and summon a shade near their foe and are unable to affect themselves with shade abilities (unless they also place one on their own location). We'll be keeping a close eye on the results of this change and making adjustments accordingly.

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:

1. 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";

2. removing the 1/2 sec activation delay that was later added to shade skills (F2-F5) to compensate for time needed to reposition shades; and

3. maybe 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.

> @"Naxos.2503" said:

> 4. If Necromancer minions can use necromancer stats, I move that turrets be allowed to use atleast a portion of engineer stats.

Necromancers' minions don't generally inherit necromancers' stats. "A minion has a fixed amount of health, damage, and armor…" -- [wiki](https://wiki.guildwars2.com/wiki/Minion "https://wiki.guildwars2.com/wiki/Minion"). 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.

> @"narcx.3570" said:

> > @"Stephane Lo Presti.7258" said:

> > > @"Bellefon.1259" said:

> > > > @"Stephane Lo Presti.7258" said:

> > > > We noticed that some Mac players are still using the old, unsupported Transgaming client and some crashes seem to originate from that. If you're in this case, please follow the instructions shown here: https://en-forum.guildwars2.com/discussion/87651/macos-client-update#latest

> > >

> > > 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.

> @"JustTrogdor.7892" said:

> > @"Knighthonor.4061" said:

> > My question is how do you let go of the wall? I was eliminated once already because mount accidentally stuck to the wall and wouldn't let go and aggro a hydra that blasted me with no way to move.

>

> 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](https://wiki.guildwars2.com/wiki/Endurance " 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.

> @"Sanus.3502" said:

> For the Carved Path achievement and subsequent daily... Using the Mac 64-bit client, the runes do not show up on the table no matter my settings.

Same issue with Mac users not seeing the marks on the table discussed in this thread: [Malice's Code Bug](https://en-forum.guildwars2.com/discussion/comment/1048269/#Comment_1048269 "https://en-forum.guildwars2.com/discussion/comment/1048269/#Comment_1048269")

As it's becoming clear that this is not related to completing the story, at this point, probably the best two things to do:

1. Report using the in-game bug report feature (/bug) while standing at the table, giving Mac model, OS X version, and GW2 client version; and

2. Join 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.

> @"SoulGuardian.6203" said:

> Every new mount that is released has the same bug.

> The older ones eventually get fixed, but the new one inherits the same bug.

> At times, for some unknown reason, It takes a long time to spawn, and your character gets half berried on the ground, unable to move, until the > server recognises that you in fact unlocked it and finally spawns it.

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.

> @"perilisk.1874" said:

> If it's like other mounts, for some reason it only happens if you have the default mount skin. Otherwise, the mount spawns with the default skin until the proper mount skin loads. So, it technically has a solution, but it's a pretty pricey one.

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.

> @"Stephane Lo Presti.7258" said:

> > @"Bellefon.1259" said:

> > > @"Stephane Lo Presti.7258" said:

> > > We noticed that some Mac players are still using the old, unsupported Transgaming client and some crashes seem to originate from that. If you're in this case, please follow the instructions shown here: https://en-forum.guildwars2.com/discussion/87651/macos-client-update#latest

> >

> > 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.

> @"Stephane Lo Presti.7258" said:

> We noticed that some Mac players are still using the old, unsupported Transgaming client and some crashes seem to originate from that. If you're in this case, please follow the instructions shown here: https://en-forum.guildwars2.com/discussion/87651/macos-client-update#latest

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?

> @"Linken.6345" said:

> They are not the same some a similar sure, might be time for glasses if you think they are the same mate.

Yep, on day 2 the first 3 symbols were the same, 4th was different triple-angled lines on closer look -- my mistake. Appears the symbols vary as well. I was going by best inf. at the time on reddit, as the symbols don't seem to appear on the table until completing a story step.

> @"Locce.8405" said:

> That sounds a bit roundabout with all the tree-touching when you can see the correct order on that small table next to Malice and you only have to find the matching trees.

> I'm _very_ happy that the initial claims of players saying there was an event for it proved to be wrong. The way they did this is actually pretty fun.

Same symbol appears on multiple trees, so it’s a bit more than find the matching tree — it’s find the right tree/symbol combo that works. Still, true, not bad.