Why We Lag Now?

[Enter Name Here]

reported for advertisement

[Craaazyyy]

Time dilatation was implemented back then quite literally. Everything was much slower. There goes your answer.
There was no 0.8s gcd 0.9s casts followed by barrage of other spells so you could burn your keyboard like fury warriors or DH's now.

Classic CPM for various classes:
Warlock: 22
Warrior: 24
Hunter: 22
Mage: 20

So lets say average around ~23

Now for retail:
Mage: 60
DH 73
Druid: 58
Hunter: 91 (dfuck?)
Rogue 65

So lets say average around ~65

Thats like 3 times faster. Now multiply that by amount of people in raids and you have your answer.

the thing is i played this game forever and in wotlk/cata/mop(when classes had the most abilities and highest cpm) when internet stopped being shit for most people, but sharding wasnt a thing yet and snapshotting was still a thing there was no lag like that. Also there is no lag like that on pservers, i played on many and it never lagged as much as current retail servers do(outside of times where the server just couldnt handle 15k people at the same time, but it was lagging everywhere, not just in a specific situations where a lot of people are casting a lot of stuff), like the lag in wintersgrasp on retail is unbearable, but i played through many wintersgrasps in wrath and it wasn't nearly as laggy on both retail wotlk and on pservers... same shit with any big scale pvp or big bgs

[keldarepewpew]

If you still think its a sharding issue try watching methods video of 30 mages vs nyalotha.

[LordVargK]

Let's say we still have a hit chance for simplificacion purposes and you have an azerite trait that gives you a 20% chance of doing damage on every crit. Let's call this trait supercrit and have this chances:

Hit: 90%
Crit: 25%
Supercrit: 20% on crit.

The first , most intuitive idea is that you need to roll the dice 3 times:

Roll 1. Determine if you hit or not.
Roll 2. If you hit determine if it crits.
Roll 3. If you crit determine if there's a supercrit.

This is false and completely absurd. Any college student that have been taking Computer Simulations 101 for two weeks would reject that idea so let me ...smile...when I see the guy in the video putting dices over dices over dices on top of the table.

To determine the outcome in any stochastic process you create a states map. The states map for this example is really simple (based no a 0-100 roll) :

90-100 Miss
25-89 Hit
5-24 Crit
0-4 Supercrit

You roll the dice once. You get a 78 ? -> its a hit. You get a 17 -> It's a crit. You get a 2 --> It's a supercrit ( crit+azerite trait)

As you can see you are determining the outcome of 3 events based on just one roll of the dice. The chances are still the same: 10% miss, 65% it's a hit but not a crit,20% its a crit but not a supercrit and 5% it's a supercrit.

I know that you simplified things on purpose, but your calculations are slightly off.
0-100 equals 101 possibilities.
For miss (90-100) thats 11/101, meaning 10.89%, which is not 10% (1-90%) like it should be.
Same for hit without crit: 65/101 is 64.36%, whereas with real die rolls you would get 67,5% (= 90%*75%)
For crit: 20/101 = 19,8%, whereas 90%*25% = 22,5%
For Supercrit: 5/101 = 4,95%, dieroll: 90%*25%*20% = 4.5%
I don't want to criticizise you calculation here, since you wanted to keep things simple. But you're hiding a significant problem: the precision of state maps.
In your example (only integers values) you need 3 dies with 100 possible outcomes (let's not include 0 for simplicities sake). You thus have 1,000,000 possibilities.
In a state map you will lose precision, if you don't make the state map have 1,000,000 entries. Otherwise you can not account for 1% hit, 1% crit, 1% supercrit, which is 1/1,000,000. And now you have a problem. Make 3 dice rolls over a field of 100 or make 1 over a field of 1,000,000? Modern implementations of RNG perform indepentend from the given range, meaning 3 dice rolls take 3 times as long as one (assuming Blizzard has implemented this correctly). So runtime wise you got 3 times faster. But you needed 1000000/300 = 3333 times more memory to achieve this (if you actually create a map of which one element is getting selected).
Although memory is fast and cheap, such an increase is still not feasable.

So, you have to make a choice here: Either be fast or be accurate. And it gets exponentially worse with non-integer stat numbers.

[Frolk]

reported for advertisement

You think it was Preach who posted the video for self advertising?

[ymirsson]

Why do you need 3 die in that example?

[justandulas]

It’s bad programming. Simple as that.

The game used to be able to handle more players in a tight area no problem but the more they touch up the graphics, the worse the game plays together.

100v100 in classic can be less laggy than 30 man raids or battlegrounds in retail. How?!

[Asrialol]

Preach saves his breaths in canisters so he can breathe it back in later to "save oxygen".

Dude has no idea wtf he's talking about. Quit watching him and at the very least quit sharing him.

- - - Updated - - -



Yes, because that happened. Very cool.

I'd imagine you'd have gotten a single "k".

So much this. Preach is a cancer to this game and the community.

[justandulas]

So much this. Preach is a cancer to this game and the community.

Preach is, by far, the best wow youtuber this side of classic

The people who hate him often mistake him for heelvsbabyface (who is the definition of toxic gamer)

Preach is a damn good player, gamer, good guy and always is fair and honest about wow

Wow bfa just isn’t that good of an expansion, sorry but it’s the truth. If it wasn’t for wod, bfa would be the worst expansion in wow history and you could make a genuine argument that wod was superior in some ways

[kamuimac]

After attempting several Epic Battle grounds and realizing they are unplayable due to insane lag, I decided to search online for a reason and came across this clip -video is not mine.

Not only did all these additions (azerite gear / corruption on gear) reduce fun for me as an individual player, it looks like it also degraded game play quality.

its nonsense.

you are lagging because blizzard is saving $$$ on servers and on cleaning of game code.

we live in 2020 and servers are from like 10 years ago .

SL will come and lag will be only worse.

[Blackmist]

I don't think the Preach video is right. Rng on rng on rng isn't slowing anything down, because these operations are ludicrously fast. Like even if we were relying on one PC somewhere to calculate this for everyone (and we aren't, we're all on shards and instance servers for exactly this reason), it would still be able to cope with modern CPUs.

I think the real reason is hiding in plain sight. In BFA AoE spells will be limited to hit like 5 enemies. There's your culprit and your solution.

1 person hits a mob. 1 damage spell recorded and sent over the network.
1 person hit 20 mobs. 20 damage spells recorded and sent.
2 people hit 20 mobs. 40 spells recorded, and sent to 2 players, so 80 sent over the network.
25 people hit 20 mobs. 500 spells, sent out to 25 players, so 12,500 sent out.
You can see how a giant 40v40 cluster fuck in Alterac Valley could spiral out of control here. 40x40x2x80=256,000 damage records sent.

And this is happening potentially every second.

[kamuimac]

So much this. Preach is a cancer to this game and the community.

agreed. youtubers nd twitch streamers are equaly cancerous

its because of them game is catered towards top 5% of players instead 95% .

its also why retail is dying while classic is growing

people dont want to play instance symulator - people want to play true mmorpg/

just wait what will happend once both TBC and WoLK will be out.

[Vilendor]

The truth is in any stochastic simulation you roll the dice once to determine a virtually infinite number of related events

[snip]

Someone send a message to that guy explaining him you don't need 40 dices but one single dice.

Even you said that your example works with related events. Great. What the video was about is the massive amount, unrelated random procs/events/buffs/happenings that causing lag. I don't see how your argument contradicts his.

Especially when Blizzard devs literally contacted him and told him that's what causes the problem.
Well, unless you think he is lying.

[huth]

I know that you simplified things on purpose, but your calculations are slightly off.

Which could be trivially fixed by making it 1-100 or 0-99 instead.

Your supposed counterexample doesn't actually show anything new. It also depends on how the system works: 1% hit and 1% crit could simply mean that every hit will also crit, at which point you go from 1/1,000,000 to 1/10,000

Although memory is fast and cheap, such an increase is still not feasable.

Sure is. Neither takes a significant amount of memory, and unless they programmed specificially for efficiency, they probably don't even take a different amount of memory because they both use the same variable type.

- - - Updated - - -

Especially when Blizzard devs literally contacted him and told him that's what causes the problem.
Well, unless you think he is lying.

Did they tell him it's the number of rolls being made, or the results of those rolls having to be communicated to every player in the area?

[PrimiOne]

I know that you simplified things on purpose, but your calculations are slightly off.
0-100 equals 101 possibilities.
For miss (90-100) thats 11/101, meaning 10.89%, which is not 10% (1-90%) like it should be.
Same for hit without crit: 65/101 is 64.36%, whereas with real die rolls you would get 67,5% (= 90%*75%)
For crit: 20/101 = 19,8%, whereas 90%*25% = 22,5%
For Supercrit: 5/101 = 4,95%, dieroll: 90%*25%*20% = 4.5%
I don't want to criticizise you calculation here, since you wanted to keep things simple. But you're hiding a significant problem: the precision of state maps.
In your example (only integers values) you need 3 dies with 100 possible outcomes (let's not include 0 for simplicities sake). You thus have 1,000,000 possibilities.
In a state map you will lose precision, if you don't make the state map have 1,000,000 entries. Otherwise you can not account for 1% hit, 1% crit, 1% supercrit, which is 1/1,000,000. And now you have a problem. Make 3 dice rolls over a field of 100 or make 1 over a field of 1,000,000? Modern implementations of RNG perform indepentend from the given range, meaning 3 dice rolls take 3 times as long as one (assuming Blizzard has implemented this correctly). So runtime wise you got 3 times faster. But you needed 1000000/300 = 3333 times more memory to achieve this (if you actually create a map of which one element is getting selected).
Although memory is fast and cheap, such an increase is still not feasable.

So, you have to make a choice here: Either be fast or be accurate. And it gets exponentially worse with non-integer stat numbers.

About the bolded part...emm..no you don't.

Well,let's start for the begining.You don't have 1 M possibilites -> you just did 100 x100x 100 but this does not describe the model: that million posibilites include events where it does not hit but still crit or supercrit and it includes events where it does not crit but it supercrits. These events are out of the model as non feasible events. Not every combination of events is allowed in the model and therefore we can't just make a combination of 100x100 x100: you can't miss and supercrit at the same time.

The main thing tough is that you are describing numerical treatment as independent from it's logical implementation that is a 64 bits number. It does not matter if you want to get a 0-100 random number or a 1 - *18.446.744.073.709.551.616‬ random number ( 2^64): the system is still generating a 64 bits number and the computational cost is the same ( the 78 you get when doing /roll 100 is the rounding of the result).

But what about the memory? Again in the example we got 3 parameters that are stored in a 64 bits numbers. We see:

90% hit
25% crit
20% supercrit on crit

But those numbers are still a 64 bits number. In an scenario of 3 roll dices you still are obtaining a number between 1 and 2^64 to determine the result.... so the state map using one single 64 bits number can have 18.446.744.073.709.551.616 "entries" ( as you called it)

Wow...I have no insight of the game implementation (none of us do) but that's quite big number of entries. No matter how complex is your state map: you are just gonna roll once. You can have 0.00001 % hit and 0.00001% crit if you hit and 0.00001% supercrit if you crit and still have a mind-nubbing ammout of unused entries in the 64 bits numbers.

The real cost in the memory is that you have to store the states map: you need to store that between 89.9999 and 99.9999 it's a miss so (let's add one more number for the state code) you got 24 bytes per range. You can add 1000 ranges (and this is quite generous for WoW) to your states map and still using just around 24 kylobytes of memory to store the states map.

The memory cost of a state map is not determined by the scale of the roll: it's determined by the precission,scale and number of ranges in the map.

Especially when Blizzard devs literally contacted him and told him that's what causes the problem.
Well, unless you think he is lying.

No, we are mixing concepts here wich is something easy to do when not in the proper context.

I don't believe for a single second ( and if that's what Preach is saying then yeah I 100% say he is lying) that Blizzard told him specifically there's too much rolls. Not at all.

IF Blizzard told him anything ( wich I honestly have problems believing because sharing this kind of insights is pretty rare) it's that the communication between the individual events shared to each client it's the thing that is causing the lag ( your pally tank has critted, the boss have procced Relentless desesperation,your drood healer is standing in the fire -> -10.000k HP for him...) wich has absolutely nothing to do with rolling the dice 40 times to see if your Enlarged Penis azerite trait procced or not.

[Shinrael]

Youtube/facebook comments always shit 24/7 on WoW with 0 arguments, fansites are paradise compared to them. If youtuber say "WoW is bad cause X", no one will argue with X there.

Fansites were a paradise xDD Do you hear that guys xD xD ?

Honest advice: Better take cover before the "paradise" hater missiles reach you!

[Onikaroshi]

Haven't lagged since the first few weeks of 8.3, but I don't play on warmode and that's where I hear most of the lag complaints.

[LordVargK]

Which could be trivially fixed by making it 1-100 or 0-99 instead.

No, it isn't. With 0-99 you won't be able to correctly reflect decimals. You would not be able to correctly calculate the hitchance without crit (which is 67.5%)

Your supposed counterexample doesn't actually show anything new. It also depends on how the system works: 1% hit and 1% crit could simply mean that every hit will also crit, at which point you go from 1/1,000,000 to 1/10,000

Well,let's start for the begining.You don't have 1 M possibilites -> you just did 100 x100x 100 but this does not describe the model: that million posibilites include events where it does not hit but still crit or supercrit and it includes events where it does not crit but it supercrits. These events are out of the model as non feasible events. Not every combination of events is allowed in the model and therefore we can't just make a combination of 100x100 x100: you can't miss and supercrit at the same time.

Please, draw me an example state map for 1% hit, 1% crit and 1% supercrit, that has the SAME probabilities as the dieroll model. In my model I have
1-990,000: "miss"
990,001- 999,900: "hit, but no crit"
999,901- 999,999: "hit, crit, but no supercrit"
and only 1,000,000: "supercrit".
This model reflects precisely the real probabilities. Where do I include non feasible events here?

Sure is. Neither takes a significant amount of memory, and unless they programmed specificially for efficiency, they probably don't even take a different amount of memory because they both use the same variable type.

The main thing tough is that you are describing numerical treatment as independent from it's logical implementation that is a 64 bits number. It does not matter if you want to get a 0-100 random number or a 1 - *18.446.744.073.709.551.616‬ random number ( 2^64): the system is still generating a 64 bits number and the computational cost is the same ( the 78 you get when doing /roll 100 is the rounding of the result).

But what about the memory? Again in the example we got 3 parameters that are stored in a 64 bits numbers. We see:

90% hit
25% crit
20% supercrit on crit

But those numbers are still a 64 bits number. In an scenario of 3 roll dices you still are obtaining a number between 1 and 2^64 to determine the result.... so the state map using one single 64 bits number can have 18.446.744.073.709.551.616 "entries" ( as you called it)

Wow...I have no insight of the game implementation (none of us do) but that's quite big number of entries. No matter how complex is your state map: you are just gonna roll once. You can have 0.00001 % hit and 0.00001% crit if you hit and 0.00001% supercrit if you crit and still have a mind-nubbing ammout of unused entries in the 64 bits numbers.

Ah, you are right, as WoW seems to be written in C/C++, which features specific memory allocation. I forgot about that (because I mainly use Python, which handles memory allocation for you so I rarely think about it).

The real cost in the memory is that you have to store the states map: you need to store that between 89.9999 and 99.9999 it's a miss so (let's add one more number for the state code) you got 24 bytes per range. You can add 1000 ranges (and this is quite generous for WoW) to your states map and still using just around 24 kylobytes of memory to store the states map.

The memory cost of a state map is not determined by the scale of the roll: it's determined by the precission,scale and number of ranges in the map.

The point about precision is the one I was talking about. But how is the size of one range calculated? And could you provide me with a link to a source with information about state maps? I tried to find it, but googling "state map" combinded with variing other terms proved fruitless.

[thebdc]

If you still think its a sharding issue try watching methods video of 30 mages vs nyalotha.

That's not server-side lag. What you're seeing is the client not being able to keep up with what's going on. For example caused by addons processing the combat log.

[Dracullus]

Fansites were a paradise xDD Do you hear that guys xD xD ?

Honest advice: Better take cover before the "paradise" hater missiles reach you!

I guess reading comprehension is not your strong suit.