The network tick rate is over 10 times what it was back in 2004…
You do realize classic is gonna run on the new tick rate right…
There is literally a sticky right now on this forum with them announcing they are putting all spells on the slower tick rate. Its call “Spell Batching”. Why are you in this thread making incorrect claims like this when the actual correct data is so easily accessible?
These ‘discussions’ are becoming extremely tiring. People aren’t even trying to understand anymore. Just assumptions presented as fact; even when the data is literally right freaking THERE.
5 Likes
So you obviously do not understand what they said…
They changed the PRIORITY of spells to SIMULATE the slower tick rate for those… does not mean they are running a slower tick rate, just means that spells are gonna get checked less often everything else still runs at the higher tick rate.
2 Likes
You cannot possibly be this dense… Having the server check for data less often is the very reason why slower tickrates are less stressful on the server.
Do you… Do you have… any idea how this works? Im not insulting, because Im willing to break this down, but Im not going to bother if you won’t listen. Because what you just said made no sense. You literally contradicted yourself in the same post. Moving spells to a lower and slower processing loop processes them at a slower rate. This frees up massive amounts of server resources. This is why even though server hardware has undeniably gotten better since 2004, current server hardware (even networked) has trouble handling the same number of people. Its processing significantly more data per ms than it did back then.
6 Likes
I know how it works, you apparently do not. Reread what they said… spend some time learning what that means then come back here and realize you are wrong.
1 Like
Okay so yeah. I wont waste my time then. I just needed to verify that you are some kid that can’t admit they are wrong, and that happens to be WAY out of their league now that things have gotten technical. So you are just gonna bounce around this discussion and try to save face any way possible.
In any case, for those reading this thread that are actually looking to get more information on how this works here’s a link or two that kind of details the basics of what we are talking about and tick rates, client update rates and the differences between that and lag.
https://huntshowdown.kayako.com/article/29-bandwidth-latency-tick-rate
https://www.nbnco.com.au/blog/entertainment/what-is-tick-rate-and-what-does-it-do
Modern gaming hardware benefits from lower tick rates as they are less stressful on hardware. It’s the reason when Classic comes out with all spells on low priority loops comparative to today’s competitive games, you will notice a city raid that would choke BFA to death is actually holding steady in Classic. This doesn’t mean the servers will be invincible of course, but having to process less often will lead to significantly higher resilience when large crowds gather. There’s also a secondary benefit… The higher the tickrate on the server, the more its going to cost overall to have it maintain performance when stuff gets real (think raids in BFA).
The announcement about spell batching was HUGE for this reason alone. It’s about more than just being able to see two mages sheep each other. And its a double win for Activision, as they get to use their same hardware and don’t have to spend for more expensive stuff, yet the “stability” will be better just by default.
7 Likes
If they artificially limit the client/server update rate (tick), the server will be receiving less frequent updates and therefore will have an effectively lower update rate.
Ok let me try and spell this out for you cause you have very poor reading comprehension skills.
The game USED to run on a slow tick rate that processed EVERYTHING.
NOW the game runs on a FAST tick rate, but all actions that need to be handled get a priority so not all interations are handled every tick, so they can have much faster tick rates but dont have to spend every tick checking everything.
In Vanilla the slow tickrate that handled spells caused poor interations… so with the faster tick rates they solved those problems, because they didnt want those interations to work that way, they put spells as a high priority(getting checked every tick).
Now to simulate the old behavior they are dropping the priority of spells so they only get checked every few ticks instead of every tick. The servers still run at the faster tick rate they still handle the same amount of spells they just let the spells stack up for a few ticks before actually processing them.
The Classic servers will still run on the faster tick rate and most of the priorities are staying the same, however they are adjusting a little bit to simulate slower tick rates. The game is not going to run at a slower tick rate.
except thats not what they said they were doing…
They are using clouds because clouds are cheaper and easier and reduce risk, and therefore maximize profit and minimize losses.
Please don’t play dumb and ask if Activision Blizzard would really do something like maximize profit.
If the server is essentially sleeping for a tick to simulate Vanilla, that’s not causing load.
Thats not what its doing…
Its still processing stuff just not spell casts.
Yeah, hes clearly not experienced here. Hes having trouble understanding how the bandwidth is effected by processing frequency. Its not something thats easy to teach in a forum post. Especially without being condescending. Im trying to think of a way to paint a picture, but everything I come up with ends up with me seeming like Im talking down to the guy. And he refuses to Google this or read any links so its like … okay.
This is Blizzard directly telling the players all spell casts are being moved to a low priority loop for them to be PROCESSED AT THE FREQUENCY of Vanilla. Processed is the key word there. As is being aware of WoW’s code well enough to know that 90% of everything in the game is a “spell” with a set SpellID. Anyone who has run a Mangos server to fool around as a GM can tell you that. By putting 90% of all load processing (spells) on a lower tickrate the servers remaining load is absolutely miniscule with only minor things like Player Location being updated at current rates. This frees enormous amounts of resources.
9 Likes
Sounds good, I think we’re done here.
2 Likes
Lol, exactly. Heres some more information with a Blue post explaining tick rate in WoW and how it works and how it was updated to work versus how it worked in the past:
https://www.wowhead.com/bluetracker?topic=13087818929#131814318748
I was wondering when this’d get brought up. I’ve hinted about this in the past in a couple interviews… Yes, there was a very significant underlying change here, that may have implications for theorycrafting (though minor).
I don’t want to get too deep into the under-the-hood workings of WoW servers, but here’s a super short version. Any action that one unit takes on another different unit used to be processed in batches every 400ms. Some very attentive people may have noticed that healing yourself would give you the health instantly (minus client/server latency), whereas healing another unit would incur a delay of between 0ms and 400ms (again, on top of client/server latency). Same with damaging, applying auras, interrupting, knocking back, etc.
That delay can feel bad just due to the somewhat laggy responsiveness feeling, but also because the state of things can change during that time. For example: Holly the Holy Priest is healing Punky the Brewmaster. Punky spikes low, and Holly hits Guardian Spirit in a panic. The server verifies that Holly is able to cast it, and that Punky is alive (great!). The cast goes off, Guardian Spirit goes on cooldown, and a request is placed for the Guardian Spirit aura (that prevents dying) to be placed on Punky. That request will be filled next time the 400ms timer loops, which happens to be 320ms from now. 250ms later, the boss lands another hit on on Punky. Punky dies. Sadface. Another 70ms goes by, and the Guardian Spirit aura request pops up, and goes "Hey guys, I’m here!.. Aww… damn, I missed the party. Sadface."
We no longer batch them up like that. We just do it as fast as we can, which usually amounts to between 1ms and 10ms later. It took a considerable amount of work to get it working that way, but we’re very pleased with the results so far; the game feels noticeably more responsive.
I can’t guarantee that you’ll never ever again run into cases where Guardian Spirit went on cooldown and the tank still died… but it’ll be literally 40x rarer than before, and the whole game will feel more responsive too.
By [Celestalon][on 2014/06/18 at 2:30 AM](Patch 5.4.7)
The Punky example the Blizzard poster gives here should clear this up for you. The server does not actual expend resources processing UNTIL the tick is reached. This means less ticks == less time the server is processing overall. This is why less ticks is less stressful on a server, and why a server with a higher tickrate naturally is more expensive if you want it to perform well under pressure.
1 Like
Except what you seem to fail to understand is that they are NOT slowing the ticks down. They are keeping them fast, they just drop the priority of spells casts.
you still have the same amount of spells being processed the same number of ticks.
It still runs through all the things it needs/doesnt need to check and it processes the same amount of data.
Let’s say we have two identical servers running identical software.
On server “A” we set the tick / update rate to 10 billion per second.
On server “B” we also set the tick / update rate to 10 billion per second, but we modify the software to only send updates in batches of 60 per second.
Assuming the same amount of client activity on the server, which server will be under more load?
1 Like
This is where you are getting lost. Dropping the priority by definition is lowering the rate at which they are PROCESSED! Listen to Blizzard:
Do you see them. Right there TELLING YOU what dropping the spell casts to a low priority loop does? Because that’s literally them TELLING you the effect of the change.
No… You don’t. That’s the point. You are saying the opposite of what Blizzard told you:
Processed AT THE FREQUENCY of Vanilla wow… Not processed immediately, then again at the 400ms batch… Processed at the frequency of vanilla. Which was 400ms
No… Its does not. First of all, this would be computationally redundant. Second, if it still processed the things it needed to check immediately then two mages couldn’t sheep each other, because the check would be done and grant one mages spell priority over the other. The batching doesn’t PROCESS anything except on the 400ms loops. That’s what all the Blizzard posts Im linking is telling you in English. Let me link it again…
Any action that one unit takes on another different unit used to be processed in batches every 400ms
https://www.wowhead.com/bluetracker?topic=13087818929#131814318748
This is such a specific and direct statement here that it should be impossible for you to misinterpret it. This is a Blizzard employee literally telling you that the data is NOT processed as its received, but in 400ms batches. Specifically. There is no way for you to interpret this any other way… It’s impossible.
Edit: No offense, but its also long past time for you to realize that you are unable to provide citations to back any of your assumptions and yet, the opposing side has receipts for days… even from direct Blizzard employees. Either you are wrong, or the world is all collectively conspiring to put incorrect information all over the internet to make you LOOK wrong. Which is more likely dude?
3 Likes
Depends on how “B” is coded…
also not quite what is happening…
they way you would make “B” less strain is by cheating which they cant do in the model they made, so “B” would technically take more load.