[Solution] No hard limit of GR150

General Discussion
1

The easiest (and the most optional) way how to remove the technical max of GR if it is due to reaching the 64-bit integer limit.
At first, the example of the C-code (with the demonstration of the outcome of its work), based on the idea below, that was written by one programmer:
https://i.imgur.com/uWc8cqc.jpg

Idea itself
Let we know that on the certain level of GR (at the certain value of our damage) we will obtain overflow of int64 (and we know exactly when we will obtain such outcome). We will add new variable = coefficient, which we will use to compensate this overflow. Of course, it will be always fixed for the certaion levels of GR (yes, it can be dynamic, but we need the optimal variant of the code). Now - in the process of calculating of HP of enemies and our damage - we just divide (at the needed moment) these 2 parameters on this coefficient and hence - we avoid overflowing of int64 and keep max possible accuracy for our parameters (near to max of int64).

Example of code
To make this idea more clear, I provide below the part of the code for realization something like this in runtime (it is not optimal way, just for example, with suggestion that we do all multiplying in runtime; k is the current coefficient of multiplying; m is the our new coefficient we are talked above):
if (HP >> 62){ HP >>= 1; m++; }; HP *= k; // k = 1.17
DMG >>= m; // modification of our damage to enemy
That’s all.

Conclusion
It is enougn to increase the technical limit of GR at least from 150 to 200. For the GR > 300 and without any further limitations (I am about adequate limitations - i.e. we still will have limitation, but we do not have it at least for the GR of level 1m):
we need the same coefficient as we have for HP of enemies (m), but now - for our damage (let we denote this coefficient as n). After that we just make the difference (m-n) and shifting to the right our damage on this value (of course, in the suggestion that m >= n; if we have n >= m - i.e. extra-damage on the low levels of GR - we just need to subtract (n-m) and to shift to the right HP of enemy, not our damage).

1 Like
2

Proc coefficients on damage calculations now?

I think they have ruined this game enough already…

3

The end game for Diablo has died for a while now. We either need an overhaul cut/nerf to all classes and relative builds which is not popular and quite frankly not fun or a GR cap increase in order to provide a reward mechanic aka endgame to Diablo again.

1 Like
4

I gotta ask: “why?”. If you need to go through all those hoops just accept that it’s a flawed system to begin with and lay it to rest.
Demand and request another endgame model instead. The one that doesn’t require you to be a victim of randomization. Sadly, I believe no one in this forums have that sorta gall or imagination for it.

Developers felt stuck and implemented a hamster wheel by fan feedback, it was a move that lacked foresight yet you still want to run the same treadmill years later by bypassing 64-bit integer limits. Have you people ever asked “how did we get here?”? Ain’t that the epitome of beating a dead horse already?

2 Likes
5

Why do you think D3 uses Integer variables for damage calculation? With all these non-integer damage modifiers (like, 34.5% more damage) it would make much more sense using floating point variables for it.

These are also limited in some way, but their maximum is way bigger than the max value of Int64.

Anyway: The better solution for this “problem” would be a general rework of all these numbers, bringing them back to a reasonable amount. Damage modifiers like “10,000% more damage” just doesn’t make any sense.

6

Above Achilles already gave good answer.

So we have a choice - either to wait for full reworking of the game system (with the chance of about 0%) or to increase “Hard Limit of GR” just because now groups are fast-farming GR150. And for the last case I suggested very simple solution for the case of overflow of int64.

As conclusion - you can either do nothing and do not support idea (solution) by likes (to show this to developers) in your dreams about full reworking of the game or to help to fix “Hard Limit” if it is due to overflow.

Just because with floating numbers or even with scientific format of numbers can’t be any limitations on the values.
Moreover, initially I suggested slightly another ideas and (powerfull) programmers said that operations with floats require much more power than ones with integers.

Numbers in scientific format have no limitations at all, they have just different accuracy - say: two int32 for keeping numbers (mantissa and exponent in scientific format; of course, one do need int32 for exponent, but it was the way to replace int64 by the structure of 2 int32 to have the minimal changes in the code) instead of keeping one integer as int64.

1 Like
7

Why would you want to do that from a competitive pov?

The game makes more sense now than before, because there is pure efficiency contest when pushing is not involved. It just needs to integrate time invested into the LB so botting and account sharing of the rats does not offer advantage at the top of the LB.

From a non-competitive pov there is no “problem” to be solved, because the regular players don’t care that there is a GR cap in question.

If you want to create a proper competition based on pushing however you have to improve the Challenge Rifts mode, not something else.

Don’t get me wrong, what you wrote is not wrong and could be implemented, there is just no need for that to happen. The GR cap atm serves more good than bad.

1 Like
8

I read the OP, and from what I can tell you are simply adding more bits. Once you reach the 64 bit limit, just store how many times you go over (like winding a clock) to a new variable.

While good intentioned, this will have a performance impact since all calculations involving damage and life will now have a new set of steps that must be done EVERY time.

An alternate way to alleviate the issue might be to introduce player damage reduction after GR150 in that players will do 1/1.17 times as much damage with each GR level higher (the damage numbers would just need to be rounded).

9

That would only make sense, if the current cap of 150 is actually caused by technical limitations. Afaik this is not the case, it is just a “random number” from which the Devs thought noone would ever reach it. Just like they thought that “Torment 10” is something difficult to farm on.

And I found a quote from a Q&A session some time ago:
https://eu.diablo3.com/en/blog/19889980/patch-230-developer-qa-transcript-08-09-2015

It is also worth saying that most of our damage and health calculations on the server are done in floating point numbers. Computationally, the expense between large and small floats is the same, and most of the expense on the server is usually the raw quantity of the calculations we are trying to do rather than values stored in the floats themselves.

So, there is no need for some “Big Number Arithmetic” to surpass the 64Bit limit. D3 is already using Floating Point variables for damage calculations.

10

I would argue the root issue to be a confluence of factors: 1.) Old Coding Architecture, 2.) Lack of Monetization, and 3.) PowerCreep (and by “creep” I mean “Usain Bolt Sprint”)

D3 is an old game by today’s standards. Older games have outdated coding techniques and infrastructure. Merely maintaining these systems, let alone updating them for newer gen hardware, costs money.

D3 doesn’t generate much revenue these days, and what it does generate is a series of 3 one-time-shots (Game, RoS, Necro). Without sustained income streams, resource allocation becomes strained, making updating the code on a larger scale more and more difficult. Remember, it’s not about “can Blizz afford it” (they certainly COULD), but rather “does Activision’s risk management team think the CBA of putting profits back into D3 is favorable” (old game, no sustained revenue, probably NOT).

So it becomes a self-fulling prophecy of failure. Game needs maintenance to retain player interest -> CBA deems it risky to invest in (or at least, MORE risky than a microtansaction/subscription IP like WoW) -> budget gets cut -> Devs need to make do with what they can afford -> Tweak some variables rather than coding overhaul -> Powercreep -> Players start to get bored -> Game needs maintenance…

They wouldn’t need to attempt a 64B-bypass if they never implemented 10,000% multipliers. But, they needed to create those multipliers because they had to do SOMETHING to retain player interest. What the game actually needs is an overhaul 3.0 -> blanket number squish + account wipes + coding overhaul to support microtransactions. Compensate those who have cosmic wings or other such one-time-only shinies in some appropriate manner and then go from there.

Not the most popular option, to put it lightly, but that + regular balancing tweaks from there on out would correct the foundation shift. It will never happen at this point in the game’s lifespan though.

Point is, there’s a problem at the core of D3, and applying a programming trickery bandaid won’t solve it. I applaud the creativity, but what’s truly needed is something that won’t feasibly happen. Probably better to just learn to accept D3 for what it is - a fun, if absurd, action-RPG slaughtermachine.

1 Like
11

True. It can only happen if they allow modding. But this never happens too. Sad story. A Diablo 3 story.

12

Far better and easier solutions have been posted many times before.

  1. Monsters get a scaling 17% damage reduction buff per GR

  2. Player damage is reduced by a scaling 17% value as a debuff per GR.

Both ways effectively keep the same increase going.

13

Fixed the numbers for consistency with +17% life per GR.

14

I also suggested something like this on our forum - to do not change HP of mobs and damage of player at all, starting from some level of GR (I do not know, may be GR-70 or even GR-25). Just to increase their defense and to display extra-damage (of sets) only in the profile + to add the limit on the player’s damage = the maximum HP of mobs (one shot kill).
In such case we will not have so many digits in HP of mobs and player’s damage as now - the HP of mobs will be always the same on all GR, only the value of player’s damage will be changed (like we have now for HP of player which is limited by about 1m and the appropriate damage of mobs) - i.e. on the low level of GR you will always have damage = maximum value of it. With increasing the level of GR your damage will become less and less - i.e. mobs have greater and greater defense.

But - by opinion of fans on our forum - this idea will require too big work in comparison with the main idea of this thread.

BTW: in the case of your suggestion there is another problem (in the future) - the damage of player will overflow int64 on the low GR.

And again about int64: just remember how the HP of mobs is displayed in the game. :wink:

15

It should be noted that a uint64 is 18,446,744,073,709,551,615, or (2^64 - 1). That’s unsigned, since damage isn’t going to be negative. We’ve seen trillions for damage numbers, but I’m not sure the game’s gone anywhere near the uint64 limit.

It should also be noted that GRs initially were capped at 255. This was well before the insane multipliers started getting inserted into the game, and as such, numbers were far lower than they are now.

The problem is actually less that the skills are buffed by 10,000% and more that there are so many multipliers in the game (thus requiring that). The method of scaling also plays into this as well. Had the developers originally made the top end GR either 100 or 200, and based their numbers off of the maximum gear could provide, we’d have a more linear and usable system in place as players wouldn’t reach that ceiling until they got near perfect gear, which in a season only three months long would likely rarely happen.

There would be no need for primals. In fact primals would be a detriment to a system with such a ceiling using linear calculations because they represent near perfect pieces of gear, affix value-wise.

The problem isn’t the core values themselves. It’s that they multiply off of each other. That’s where the insane numbers come from. And they’re necessitated by the infinite scalar nature of GRs. With a hard cap as a ceiling, that could be done away with. Unfortunately, that’s a metric crapton of work now thanks to the methodology the original RoS team left the Classic team with. There’s nothing to work with anymore that’s sane.

As long as the infinite scaler exists, we will revisit this scenario again and again until the end of time. Such is the nature of the infinite.

As for the majority of suggestions regarding values in this thread, they would actually add stress to the servers, not reduce it. It’s more calculations to do the same function. Efficient code is not more, it’s less. You can only achieve less by squishing the stats at this point in the game’s life. It costs a lot more to divide and multiply than it does to add or subtract in terms of compute cycles. Efficient code and K.I.S.S. are best buddies for a reason.

16

I have a simpler solution - just add a -17% debuff on player’s damage per GR level above 150. Monster health stays the same.

17

Well, from all their mistakes at least one turned to be something good.

18

Its been confirmed long ago that its a signed integer and that -health does happen.

1 Like