It would be between 14-15 tiers loss of damage.
Sounds like the perfect amount to chase 150 from…
Season 25 : Attrition
All damage dealt by players is reduced by 25%, and Area Damage is removed. Players start with 2.5 Attack Speed, their Movement Speed is increased by 20%, and Movement Speed is uncapped.
Echo of Ethereals introduced. Rares can now become corrupted into Ethereals with no special abilities and can now drop for any piece of equipment and they have no limit on the number equipped. Legacy of Dreams/Nightmares updated to include Ethereals.
Let er rip!
Whether the numbers affect the lag or not, they are simply too big. I would support the reduction of damage numbers to something more legible.
Everyone has wanted the number crunch for many years, Blizz doesn’t care.
The TLDR version of this thread?
Number sizes involved in the calculations doesn’t matter much.
The amount of calculations per second does. The more you have to calculate, the more it impacts the performance.
And there you have it.
Another couple of things to keep in mind:
Multi-core CPUs. D3 does not really take advantage of more than 2. In fact it might be best to change the affinity to use no more than 2 discreet cores.
Amount of RAM. With the 64 bit engine, use no less than 8GB. Or run the 32 bit engine instead if you have 8 or less, or a less powerful CPU/Video card, or have multiple programs/monitors, etc.
Video card: Cap your FPS to 60. Or at best, match it to your monitor refresh. You don’t need high FPS for D3. Lowering it reduces overhead, power consumption, heat generation and makes the computer work easier. For some, using full screen exclusive worst best. For others full screen windowed works best.
Game on.
1 Like
Yes and no. Yes, 64-bit CPUs can handle large calculations. But there are two rather important “no” issues to contend with.
The first is that there is still a 32-bit Diablo 3, and you can bet that a lot of players are still using it. This in itself brings up two problems. One is that you’re running in a configuration that maxes out and even crashes at 3.5 GB RAM used. That’s the literal breaking point for the 32-bit D3 client. The other problem is that you’re then dealing with 32-bit userspace code in a 64-bit environment.
In the typical use scenario this isn’t even noticeable. Even some modern games run fine as 32-bit clients. However, D3 is a rather extreme outlier in the sheer number of calculations going on at the same time. It’s that last part that does us in.
The second big problem lies in the possibility that the server side code is using 32-bit code for calculations instead of 64-bit code, or at the very least, shorter operations than the singular larger operations might be, which would then require two calculations on the server side per hit. That isn’t an issue when the end result is within the threshold for the shorter calculation size, but once you get into higher GRs the end result is so large that it would exceed anything that FP16/FP32 could generate in a single calculation. At that point, when you combine the mixture of 32-bit userspace code with this issue, you get inherently massive slowdown.
Damage is not done client side. Otherwise the client would be hacked to do max damage per hit and boom, game broken. Damage calculations are done server side precisely to prevent client side shenanigans. The calculations done on the client side are primarily graphics related. However, referencing the above issues I mentioned earlier in the post, if the server is also sending those calculations to the client piecemeal and letting the client assemble them, that too would cause slowdown.
So we either have poorly optimized code, an unfortunate circumstance resulting from mixture of 32-bit and 64-bit operations, or both. WoW never suffered this even before its squish because it has far fewer calculations to do per second than D3 does. There are more calculations in a typical 30-45 second GR run in multiplayer than there is for the duration of a full length ten minute raid boss fight in WoW.
Of course this is really easy to figure out on the dev side. All they have to do is drop all numbers to 1/1000th their current value, which leaves them the same relative to each other, and then run several high GR scenarios. We already know when it starts to become an issue on the live side, so starting there and working their way up the GR chain would be something they could do in short order. Naturally they’d need to simulate hundreds or thousands of simultaneous loads on the server, because any singular group in a vaccuum is still going to fail to trigger the scenarios we see in the live environment. But it’d be doable on their part.
Of course, it’s entirely possible that it’s merely the sheer number of calculations in and of itself that is the issue. I’m leaning toward this myself seeing as taking area damage out of the equation pretty much kills the problem. Same thing with the Hydra wizard. Too many simulataneous attacks going on and when that is not part of a group, neither is the slowdown.
Number size can be important if the code isn’t entirely 64-bit, and we know D3’s is not since it has split 32 and 64-bit clients. But we also know that groups have reported entirely or almost entirely eliminating the slowdown issue by nixing area damage and/or Hydra wizards. Ultimately, the bottom line is that there are too many things going on at once. I could have a supercharged HEDT or Xeon/EPYC system and still get hit with slowdowns if the client and/or server can’t keep up.
FWIW, I know for a fact the servers are straining, because even in solo games I’ve seen countless situations where I’d see the blue or yellow drop graphic, but not see the icon and/or item name appear for several seconds. That’s because the client is waiting on the server to send the relevant data, which appears to be in a queue of some sort.
I’m with Joat in that I don’t believe squishing the numbers itself will reduce the latency issues present, but it would most certainly help in both development and readability areas.
Oh, and just in case anyone wonders, a single attack is not one calculation in D3. It’s multiple calculations, thanks to our friends the multipliers. Yep. Those things that keep giving us power creep are responsible for what should be a quick and easy calculation taking longer to do because they have to compound the calculations, and do so in the correct order using the computer algebra system (CAS). Now multiply that by the sheer number of attacks we land at any given time in say, multishot or any other AoE situation, and well, there ya go.
If anything needs to be squished, it’s the number of attacks we land simultaneously. And we can start by getting rid of area damage and finding other ways to retain equal power.
2 Likes
They def need to do something about procs and dots. Maybe get rid of main culprits (e.g. Firebird dot) and replace with a commensurate dmg buff. Boring, I know. But better than lags.
i keep telling them this but they think they know more and wont listen
The only single thing that is still entertaining about D3 is you doing detective work on forums.
You’re not reading very well if you think I’m telling them what I think you think I’m telling them. A squish won’t really help the issue. It’s primarily for human readability and the ability for devs to better do math in their heads as opposed to constantly having a calculator out.
My post, if you really boil it down, come down to this: ditch Area Damage and give us something else to regain the loss in power. Oh, and seriously adjust Hydra Wizard builds. It’s nifty to see all the attacks going off, that is until you lag out because of it.
3 Likes
Oh, that wasn’t detective work. The thread I linked was an absolute gold-mine of hilarity for weeks with him digging himself further and further into a hole of Baron Munchausen level nonsense, so I kept a link to it. 
If they were to add a small, GPU executed blockchain node to the D3 client, they could offload 100% of all calculations to the players machines, and remove battle.net workload by 99%.
At the end of the day, a server is just a state machine, and state machines can be verified by peers (IE: Thats what a Blockchain DOES). I mean, code like Nethereum can run C# on the Ethereum blockchain (or a custom variant). I’m gob-smacked why companies like Blizzard are not all over this as the future of their online worlds.
Well keep in mind this game was released in 2012. They’re using tech from that era, and updating it probably costs money the execs don’t want to commit.
The fact that it could literally be added to the Blizzard Launcher itself, and run the entire Battle.Net load would seem to be a very cost-effective, forward thinking, paradigm shifting tech that would cover their entire catalog.
I’d honestly be surprised if there isn’t someone working on this at BlizzardHQ, as web 3.0 is inevitable.
Then you’d be forced to run your client non-stop and sacrifice your GPU power for a game even though you don’t play it. When people leave season, whole system loses calculation power. There’s not enough incentive to keep people with client active unless they play other Blizzard games. It may look nice on paper but on practice it’s unreliable.
Also the numbers you mine for Ethereum or BtC are wildly different than 19 digit number series you see as damage in game if that’s what you had in mind. I thought about mining crypto with damage number strings but it didn’t take long to realize it’s rather impractical and hard to implement as it will require a new infrastructure.
There are similar systems for crypto currency uses in games but none of them offers calculation power but NFT-alike (see; enjin) content. Perhaps it’d be somewhat relevant to a mobile or subscription-based games, but not any casual game without any planned monetization model.
1 Like
A few things from my research on this subject.
Ethereum IS a computer, BitCoin is NOT. ETH does work(calculations), BTC just validates transactions.
Blockchain speed is determined by difficulty settings. This can be reduced for non-monetary things like game servers to exponentially increase throughput.
Only 3 active nodes are necessary for a “server” to be available. Blizzard would run Authoritarian nodes on Battle.net to catch any “mass disconnect” scenario.
If it was part of the Blizzard launcher, you could shut it down when you are not personally using it, OR Blizzard could incentivize you to let it run non-stop, and pay out Blizzard Tokens. Those tokens can then be used across games for transactions.
Its just synchronized state machines, with 2 (random) nodes constantly double checking your nodes’ math.
How are 100M, 100B, 100T not legible?
Lots of nonsense is legible.
And then they’d get a seriously high load of complaints from nVidia users that have GPUs that had “reduced hash rates”. Yes, nVidia’s doing that to try and thwart cryptominers, despite the fact that a growing number of games are in fact using blockchain tech internally.
Problem with using this strategy though, is that it takes resources away from the gaming system, and quite a bit in fact. Players are going to go apeslag insane when they find that gaming companies are using their systems’ resources to cheap out on server usage. It would basically be trading cryptojacking in malware/browsers for corporate sponsored equivalents. I’d drop a game like a hot potato if it did that to me.
One of the first things tech support specialists like myself tell players to do is kill the Battle.net app because its use of Chromium interferes with most of Blizzard’s games to some degree, and the fact that when it tries to download in the background (yes, it does this even when you tell it not to) it can and usually will, corrupt your game files and force you to use scan and repair to fix it or in some cases flat out reinstall the game.
Nobody likes losing resources, stability, and/or both.
Our brains usually have to do on the fly translations for the less commonly used ones (anything about K and M the brain usually has to think about for at least a split second because it isn’t common outside of a game world).
You are literally making my point for me in your first two quotes. The blockchain solves those issues.