Why We Lag Now?

[huth]

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

That's assuming that crit is off total hits rather than total casts. Both are possible. The "supercrits" explicitly only happen on crits, on the other hand. Primione's calculations are clearly based on a model where crit percentage is based of total events, not hits, so your calculations are actually even worse. In reality, it's only the miss chance that is to high, which is easily resolved by only generating values in the 0-99 range.

[PrimiOne]

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.

I still don't see the precision problem. A 64 bits number is an incredible huge number that gives you 18 quadrillion possible results. I would understand it could be a problem if we are simulating photons or any other way more complex models but for WOW? I just can't see it's not enough.

The size of the range is determined by the implementation of the model that obviously varies. If you ask me how I would do it in WoW's case its a really simple state map for that model: it's unidimensional ( events create just one outcome) and it's discrete ( events happens or don't happen but we don't have a 73% of an event) so the state map for the example I would do it's as follow ( one number for the state code,one number for the upper range of the event)

[1,4] Supercrit
[2,24] Crit
[3,89] Hit
[4,99) Miss

There you go. 2 x 8 bytes = 16 bytes per range. Just as simple as a two dimensional array ,can't get simpler( don't confuse the dimension of the model events with the dimensions of the data structure to store the states map...the model is still unidimensional).

Now ,sources. You don't find anything because as I said, I was not gonna enter into the proper math but if you are curious and using the real terminology this is called a cumulative distribution function that is the very basics of computer simulation ( I can not stree enough this is the ABC of compulter simulation). This function can be really simple ( in our example a discrete piecewise defined function) or it can be the function that determines the wavelength of a photon after being emitted by an atom ( not so simple then).

I didn't wanted to enter into how simulation works. It's just that I saw this absurd video doing absurd statements and wanted to put a simple example of how there's methods to determine multiple random events with just one random variable ( one roll). In your post you stated that doing 3x roles is 3x slower than doing one: it's not just that--> you need to evaluate (and store using memory) the outcome of the previous rolls.

1. Roll hit.
2. If Hit > 90 roll crit.
3. If crit >25 roll supercrit.

It's not just 3 rolls versus one...it's 3 rolls and two evaluations ( Is 1) > 90 ...is 2) > 25) so there's 5 operations versus one. If we have a more complex model it's just madness thinking anyone in this planet with a basic maths understanding wouldn't use a cumulative distribution function: go figure you have 1000 events and 20% are single nested ( happen only if just one previous event happen--> we have 2 nested in the example but are not single: supercrit depends that there's a crit and this one depends there's a hit) then you have 1200 operations....versus one (to rule them all).

Look I don't have insights on the specific Wow project but I do have an extensive experience on simulations and for (literally) decades I haven't seen a single project that does not use a cumulative distribution function or ever heard about one. Let's say as an analogy that I don't work for Mercedes so I don't have a particular knowledge of how an SLK engine is done but I do work designing cars so I don't really need to know the specifics of Mercedes to know that engine has cylinders even if i'm not related to the project.Why? Because I design cars and know how the industry works and know that engines have cylinders.


This video is complete abolute bullshit coming from someone clueless about the subject. I can be more rude but I can't be more clear: no one in this planet but a college student in his first year would solve this issue with multiple rolls.

[LordVargK]

That's assuming that crit is off total hits rather than total casts. Both are possible. The "supercrits" explicitly only happen on crits, on the other hand. Primione's calculations are clearly based on a model where crit percentage is based of total events, not hits, so your calculations are actually even worse. In reality, it's only the miss chance that is to high, which is easily resolved by only generating values in the 0-99 range.

A miss that crits is pretty counterintuitive.

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.

Primione clearly calculates with dependant probabilities. Meaning crits is off hits and not casts.

[Stardrift]

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

Idk much about his skill as a player but he certainly has no idea what he's talking about every time he gives an opinion piece or tries to explain how things work.

[huth]

A miss that crits is pretty counterintuitive.

And happens in neither model.

Primione clearly calculates with dependant probabilities. Meaning crits is off hits and not casts.

Not necessarily. There's just no need to determine crits if the target isn't being hit to begin with in either model.

[LordVargK]

--snip--

Thank you! I will inform myself about this.

[kaminaris]

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

That is false, T16 in MoP didn't have highest APM, number of abilities are irrelevant.
Wotlk from what I have seen had around 40 APM (can be wrong on this one, only found couple of pieces over internet)
MoP had around 50 APM.

Snapshotting only affects dots/hots and not even that much to affect server performance.

- - - Updated - - -

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.

Yeah that is also funny when people confuse server side lag with client side lags. Mythic raider wannabees turn on multiple details windows with fast processing and animations mode tying to mimic scrype on mediocre PC and blaming blizzard for server lags.

[Shinrael]

I guess reading comprehension is not your strong suit.

I intentionally omitted the "compared to YouTubes" part, yes. They are not. Look at the shitshow here and on Wowhead. How many of the bigger WoW content creators allow themselves to be THIS openly hostile and negative towards Blizzard and the game? You aren't being objective.

[huth]

I intentionally omitted the "compared to YouTubes" part, yes. They are not. Look at the shitshow here and on Wowhead. How many of the bigger WoW content creators allow themselves to be THIS openly hostile and negative towards Blizzard and the game? You aren't being objective.

You also missed the "comments" part of "youtube comments". The content creators aren't what they were talking about.

[Shinrael]

You also missed the "comments" part of "youtube comments". The content creators aren't what they were talking about.

I guess I did. I still stand by my point though. Either way, it's the same people hating on all the platforms. People will always whine.

[protpaul]

Assuming this is true and the servers can't handle the amount of information they are receiving shadowlands wont fix this as the covenants and I assume the legendary items will keep roughly the same amount of procs.

[huth]

Assuming this is true and the servers can't handle the amount of information they are receiving shadowlands wont fix this as the covenants and I assume the legendary items will keep roughly the same amount of procs.

Then your count is off by a magnitude. You can end up with one or more different procs on every single piece of equipment you wear currently. SL doesn't have anywhere near that outside of Torghast, which resolves it by being limited to 5 people.

[dzd]

The size of the range is determined by the implementation of the model that obviously varies. If you ask me how I would do it in WoW's case its a really simple state map for that model: it's unidimensional ( events create just one outcome) and it's discrete ( events happens or don't happen but we don't have a 73% of an event) so the state map for the example I would do it's as follow ( one number for the state code,one number for the upper range of the event)

What happens when there are multiple supercrits and that are not related to each other? What happens when there is multiple on hit effects that doesn't care if it's crit too?

When do you build these maps?

It's not just 3 rolls versus one...it's 3 rolls and two evaluations ( Is 1) > 90 ...is 2) > 25) so there's 5 operations versus one

How do you get the result out of the map without doing single operation?

[huth]

What happens when there are multiple supercrits and that are not related to each other? What happens when there is multiple on hit effects that doesn't care if it's crit too?

You have a range for each of the possible outcomes. So one for effect #1, one for effect #2, one for effect #3, one for #1+#2, one for #1+#3, one for #2+#3 and one for all three together.

[dzd]

You have a range for each of the possible outcomes. So one for effect #1, one for effect #2, one for effect #3, one for #1+#2, one for #1+#3, one for #2+#3 and one for all three together.

Yes and that doesn't sound so simple table anymore (at least for me) when there are 30 different effects.

My real question was when do you build these tables and why can he just ignore the operations that has to be done to build this table?

I don't like understand how this is a simple problem where you can use prebuild table? Don't you have to rebuild it everytime your miss/crit chance changes(in this example)? For example some of these effects can increase your crit chance..

[huth]

Yes and that doesn't sound so simple table anymore (at least for me) when there are 30 different effects.

My real question was when do you build these maps and why can he just ignore the operations that has to be done to build this table?

I don't like understand how this is a simple problem where you can use prebuild table? Don't you have to rebuild it everytime your miss/crit chance changes(in this example)? For example some of these effects can increase your crit chance..

It's still a simple table. You're mostly just adjusting the ranges, not even the entries. And a proper RNG isn't that easy, so it may well be faster to rebuild the table than roll twice.

[dzd]

It's still a simple table. You're mostly just adjusting the ranges, not even the entries. And a proper RNG isn't that easy, so it may well be faster to rebuild the table than roll twice.

Bad wording by me: the table itself is "simple" of course, but building it isn't. You don't use "proper RNG" for a video game, you just use some fast one which can be done with couple operations.

I'm not saying that using table is bad idea, but you are seriously underestimating the overhead that comes from building the table when there are multiple effects.

Btw classic WoW uses this for melees, but not for casters.

edit: what I'm trying to say is that it's just dishonest to tell someone it's free to calculate 30 effects with this "super trick" where you just roll once and the result magically appears from some table that was actually never built.

[huth]

Bad wording by me: the table itself is "simple" of course, but building it isn't. You don't use "proper RNG" for a video game, you just use some fast one which can be done with couple operations.

I'm not saying that using table is bad idea, but you are seriously underestimating the overhead that comes from building the table when there are multiple effects.

Btw classic WoW uses this for melees, but not for casters.

edit: what I'm trying to say is that it's just dishonest to tell someone it's free to calculate 30 effects with this "super trick" where you just roll once and the result magically appears from some table that was actually never built.

Nothing is ever free. But it's really just multiplication, not some higher mathematics at work here. This isn't complicated stuff.

[dzd]

Nothing is ever free. But it's really just multiplication, not some higher mathematics at work here. This isn't complicated stuff.

That's just not relevent at any level. It doesn't matter how easy it is for humans to understand. Only thing that matters is how many CPU cycles you use doing it.

- - - Updated - - -

This isn't complicated stuff.

Oh btw if this isn't complicated stuff, I'm sure you can calculate how many CPU cycles it takes to build a table for 30 effects? You can choose the effects yourself as long as only couple of them are dependent on each other. I seriously don't know and I would like to know some estimate.

[PrimiOne]

I don't buy it

And that's a good thing really. It's extremely healthy , given how the world works , being skeptical about what a random guy in the internet says but calling me dishonest because I didn't wanted to enter into the maths...its a bit ..well ok.

The first thing ,being precise, is that we can't talk about cycles. Cycles relates to an specific physical implementation,an specific software,compiler and hardware and we are talking here about an algorithm so we we need to discuss about the order of the algorithm. You know this but for those who don't the order of an algorithm defines how resources (computing time,memory) growths based on input size. For example using the estándar Big Oh notation an O(n) indicates a linear growth ( if the input is 1000 the time is 1000) while a O(n^2) indicates an exponential growth (if the input is 1000 the time is 1000000).

You asked:

What happens when there are multiple supercrits and that are not related to each other?

Really simple.

We have now a Megacrit: 10% on crit to destroy Azeroth and send retail back to Vanilla. Parameters:

Hit:90
Crit:25
Supercrit: 20
Megacrit: 10

If the events are dependant the area that defines the function overlaps. In the situation you describe the Crit and Megacrit overlaps but the supercrit and megacrit are not related( you don't specify tough if both are possible at the same time I would suppose no).

0-4 Supercrit
4.1- 6.5 Megacrit
6.6 - 24 Crit
24.1 - 89 Hit
89.1 -99 Miss

There you go.

What happens when there is multiple on hit effects that doesn't care if it's crit too?

We add multistrike. Parameters:

Hit:90
Crit:25
Supercrit: 20
Megacrit: 10
Multistrike: 15

Again the crit and mulstrike are not related so their areas defined in the function don't overlap:

0-4 Supercrit
4.1- 6.5 Megacrit
6.6 - 24 Crit
24.1 - 39 Multistrike
39.1 - 89 Hit
89.1 -99 Miss

We can literally add as many events as we wants as long as we follow the logic of the model. We can't model a 55% crit and 45% multistrike because ...how come I have a 90% hit but 100% crit or mulstrike? Can I crit/multistrike if I miss?

When do you build these maps?

You build this map first ,obviously, when the character loads ( it's in the server in the memory allocated for your char) and whenever an event modifies the stats in your character that affects the amp: you unequip your Boots of Frustrating Obsolescence and the map is rebuilt,you get a buff and the map is rebuilt…you press your Trinket of Many Crits that give you +10% crit for 30 seconds and the map is rebuilt until it expires and you get back to your base map.

Now this is the part that keeps you skeptical. You seem to think it's a higher computational cost that rolling after rolling after rolling and evaluating dependencies so let's get into the order of both algorithms. You didn't stablished a well defined set of parameters so I would have to guess some of them but don't worry: I won't be "dishonest" and I will suppose an extremely (almost unrealistic) set that favors your arguments.

30 events
no dependencies at all ( no event depends on another event happening)

We got an O(30n) --> every time you cast there's 30 operations for the multiple rolls algorithm.

Let's suppose the map is a sorted list ( I'm not even gonna enter into more advanced data structures than I'm 100% sure Blizzard uses) and let's suppose ALL the events are unrelated so the map has 30 entries and are equally distributed. Let's suppose the events that modifies the map happens on average for 80% of the entries so every time the map is modified you need to alter 24 entries. You can't deny Im putting myself in an hard position.

The first thing is that the building of the base map is not part of the order: it happens once when the character is loaded so not affected by the input size ( its processing time does not grow based on the number of casts) and therefore out of the order.

You roll ( 1 operation) and needs to find the outcome in the sorted table. Since there's equal probability for any number if the 1-100 range you need to compare 15 entries on average( is my result bigger than position 1? is bigger than position 2?). So we got 16 operations per cast.

As we stated everytime your map changes 24 positions change wich implies calculating the new range ( if your crit is now 30% the range of the supercrit is not 1-5% but 1-6%) and updating the map so the order of the map is O(n16 + c48) where c is the number of times per cast that your map changes( you get a buff, a debuff…) that gives us O(30n) = O(n16 + c24) and therefore we got a c = 2.13

That's right : both algorithm have the same order when you have to change the map…basically every 2 casts.

Now let's resume. I have created a completely unrealistic scenario to make you win.

1. I have assumed generating a random number have the same computational cost than comparing/changing memory positions wich is hilariously false. Even in the most simple RNG method ,a linear congruential generator, there's order of magnitude of difference.
2. I have assumed every event is unrelated so we got 30 entries for 30 events and equally distributed ( the average number of operations to locate the result of the roll in the map would be drastically lower if ,for example, 15 events were in the 1-25 range)
3. I have used a sorted list that is the most unefficient data structure known for this task forcing us to iterate every position.
4. I have assumed every time the map changes 80% of the ranges change that is way generous for WoW ( if you get a crit buff the only positions that change are the range of the crit and its dependencies like supercrit or megacrit).
…and more.

Even with this truly disadvantageous scenario that in now way describes WoW the cumulative distribution function have a lower order than the multiple rolls algorithm if your map stats ( think that Attack Power or Spell power buffs does not change your map) change every 2 or more cast on average…


Look there can be no discussion on the efficiency of a cumulative distribution function to specify the distribution of a multivariate random variable problem. The 60s passed many decades ago...there's currently no debate over it in the computer sciences. You seem to think that's something used for physics or medicine simulations but that in now way is necessary for a "videogame" ignoring that sometimes videogames have the most brutal performance requirements of all specially those that needs real time events ( I can wait 5 days for the simulation of a set of photons impacting a solar panel.....Blizzard can not wait ,literally, 100 miliseconds to send and answer to the client).

This is the defacto standar for implementing every single model that includes multiple random variables.