The feature is there to improve the look of the textures that are affected by said feature. And like every other feature in the game, it can be turned off if you don’t want it or your system can’t handle it. For OS X it’s currently moot anyway since no supported GPU has RT hardware on it thanks to Apple blocking nVidia from making drivers. AMD hasn’t released its RDNA2 cards yet, so no support for RT with Team Red yet.
And even if RT is just shadows currently, that isn’t the only aspect intended in the future, I can assure you. Just like a lot of other bleeding edge features, it’ll likely be enabled bit by bit as the patches roll in. WoW isn’t in a vaccuum all by itself and does evolve over time. It’s a double edged sword actually, since even though it gives the platform team more knobs to turn, on the OS X side it also means it makes it that much harder for them to maintain prior OS support for folks like myself that currently need such to play.
I’m glad WoW is evolving still. Stagnation leads to lack of innovation. Despite the hiccups the Mac side has face over the last few years, nobody can say Blizzard’s platform team hasn’t done their best to make things work for as many people as possible. Sure, my problem didn’t get real attention until just recently, but outside of the forced reliance on Apple to fix bugs submitted via Radar, I can’t say I haven’t seen Blizzard really attempt to keep things moving.
I wish nVidia could still put out drivers for OS X. I’d sell my kidney to get that 3090 ASAP (as long as it’s from EVGA of course) just so I could try out the new features and give feedback on them. But hey, at least I’m getting a chance to potentially return to the game and get to playing it again and other players are getting new shinies to try out. Someone else getting to try out ray tracing isn’t going to hurt me one bit. That’s the beauty of WoW - so many knobs and switches to play with that you can almost always make it into what you want.
It could be worse - WoW could take up nearly 200 GB of space like a fully installed modern Call of Duty game.
So if I took my WoW folder, threw it on an external drive, and told that drive to ignore ownership on this volume, would I expect to still see this error (without running the chmod stuff)? Cuz I do.
I’ve literlaly unhid all hidden files and checked permissions on everything in folder. buildinfo is 777 as it should be, i even set all addons to 777 and have not installed any new ones. I can literally click update, then once it’s done check for updates and it’ll immediately think there is a new patch.
It’s very clear there is no mac support left outside of rommax which tries his best but ultimately is just one guy in a company that stopped being blizzard years ago. It’s a tragic shame.
I think you are overstating the lack of Mac support. Blizzard is obviously watching this thread. Here is the status as I see it as of Oct. 1:
I uninstalled War III to simplify the testing.
The Twitch client does trigger un-needed updates, but as Twitch will no longer be handling updates in a couple of months, I don’t see any need for Blizzard to work around this issue. I’ll be personally testing alternate mod updaters in the next few weeks to see if they also cause issues.
I’m using the Beta version of the Battle.net Laucher and here is what I see -
All current WoW clients still delete and re-create the .build.info with 666 permissions. However, the Live and Beta clients now chmod 777 the file after patching. The PTR does not (yet).
Here is a log of me watching that file during and update today:
iMac:World of Warcraft me$ ls -la .build.info
-rwxrwxrwx 1 me admin 1764 Oct 1 01:59 .build.info
iMac:World of Warcraft me$ ls -la .build.info
ls: .build.info: No such file or directory
iMac:World of Warcraft me$ ls -la .build.info
-rw-rw-rw- 1 me admin 1764 Oct 1 13:50 .build.info
iMac:World of Warcraft me$ ls -la .build.info
-rwxrwxrwx 1 me admin 1764 Oct 1 13:50 .build.info
This is new behavior and proof that Blizzard is watching/fixing - even if they are quiet about it. And no, I didn’t impliment a cron task to fix it.
I literally wasn’t running twitch, i didn’t even update addons. I verified buildinfo wasn’t broken, hit update, when it was done updating, checked for updates and it was like “I NEED TO UPDATE AGAIN” no files touched by any 3rd parties, EVERY permission in directory as it should be.
Also, if you didn’t know, they did in fact completely discolve the mac team 2 years ago. there isn’t one. At all. Mac support is in maintenance mode at best now, not full active development like it used to be… Why do you think it takes months to fix issues like this in first place (when they only affect mac)
I don’t think you are understanding what I’m saying. A PTR update will trigger Live and Beta Updates. Until recently, a Beta or Live update would trigger Live, Beta, and PTR updates. It became a cascading issue. 3rd party stuff isn’t needed to trigger it. Its been partially fixed - at least with the beta Battle.net client.
I’d love to see some evidence of the Mac team being dissolved. I can’t find any.
In fact, Shadowlands includes an ARM64_BUILD string, almost certainly so they can support the Apple Silicon machines releasing later this year.
As far as why it takes months, I would imagine that this bug would be considered pretty low priority just because it is only causing extra updates to occur and not actually breaking the game or causing crashes. Its a subtle bug - is it the launcher thats is broken? the agent? the CDN? the build system? It takes time to figure it out.
Even on Windows, I wouldn’t give it top priority. Annoying? Sure. Hair-on-fire and developers being called on a Sunday? Hardly.
I use the beta client. It isn’t fixed. Any update from any of the branches (Live, PTR, Beta) will trigger the fake update without fail.
At this point, I can only surmise that if the files the Battle.net app looks at don’t have a later touch timestamp than the last timestamp it checks internally, it also triggers the fake update. That’s the only reason I can think of as to why even with everything correctly done it still does the fake update the moment it finishes a previous fake update. I’m wondering if this could be solved by simply having the Battle.net app automatically do a recursive touch on everything in side the WoW folder as its final step in patches and updates. That way the files would always have an equal to or later touch timestamp than the Battle.net app expects. I suppose one way to test this theory would be to set everything up correctly, then touch every file in every folder in the WoW nested heirarchy, but doing so manually is…tedious and it’d be better to just automate it from within the Battle.net app itself.
You won’t see any “evidence” in the sense you’re talking about. But I guarantee you Omegal knows more than you and more than me. If there was still a dedicated Mac platform team, Diablo 3 would have been moved to Metal already instead of left to languish and be damn near unplayable on modern macOS versions in many cases (it’s still using OpenGL, and OpenGL support is spotty at best for AMD hardware in 10.14+).
As for the ARM64 strings, apparently conversion to that architecture from x64 is moderately painless. Barring specific instructions such as AVX2, AVX512, or AMD’s 3D Now!, nearly all of the code is capable of being compiled for Apple’s ARM machines. Now, whether it can run decently is another story, but getting there isn’t death defying like it was going from PPC to x86/x64.
I been having the same problem for months now. I’ve tried a lot of the suggested fixes here but what finally seems to have killed the issue is blowing away the /Users/Shared/Battle.net folder. Next time the Launcher started the directory was recreated. I had to go and tell the Launcher where WoW and Diablo 3 were installed, but other than that, things seem to be back to normal. We’ll see if it lasts.
I followed Aunin’s instructions with some minor modifications:
Go to Terminal
Type ‘crontab -e’
The Crontab will open. Press ‘i’ to insert a new line.
Copy and paste ‘*/1 * * * * chmod 777 /Applications/World\ of\ Warcraft/.build.info’ (not including the quotes) onto the first line
Press ‘esc’ (Escape)
Press ‘:’ (colon)
type ‘wq’ to save the Crontab
This will run a script in the background every 1 minute that resets the permissions on the ‘.build.info’ file from 666 (read-write) to 777 (read-write-execute). The reason you want to use the Cron is because every time you install a Battle.net update, or install a new add-on, the permissions get reset to 666, which is the issue.
No. You just set it and leave it. If Blizzard ever fixes the bug, you can use ‘crontab -r’ to remove it and ‘crontab -l’ to list all crons to ensure it was removed.
They managed to make it even worse. with 9.0 now it’s downloading 8Mb and 20MB manifests/indices just to fake patch. I literally reinstalled game data 2 months ago and already seeing popin and slower loading, on an ultra fast NVMe drive. the literal worst thing you can do on an APFS volume, is touch files over and over and over again, on top of fact CASC is a severely fragmented format too. add in fake patching and you have a trifecta that makes even the fastest 2000+ MB p/s ssd storage have slow loading
only fix, reinstall wow. used to need it every 3 months, now it’s more like every 1-2 to keep game speed. now blizz can’t fix how much APFS sucks, but casc and fake patching are two issues they could fix if they cared, but they don’t.
Heh. My manifests are 100-120 MB. On a fresh install that somehow had to update the instant it finished patching. It does get a bit frustrating after a while.
