Spells: Channeling Fix

[Kich867]

Originally Posted by Baugi [You must be logged in to view images. Log in or Register.]

Maybe I'm not following the discussion well enough? Why is client side code relevant when the channel check was entirely server-side?

From what I can gather, they found some server-side code artifacts in the client with the magic numbers, but they seem to be contradicted by matching-era dev posts?

Obviously the original EMU code is arbitrary so I don't imagine there's a good argument against changing it, but it seems a little disingenuous to suggest a client decompile is ground truth for server code. It's also very confusing that there are privacy concerns regarding the decompile. If I'm just too naive to recognize the legal euphemism for server code I apologize.

Because it's incredibly common to have your client share the same code with your back end.

If your client is simulating the same thing the server is simulating, you can create the feeling of near instantaneous response times by having your client guess what is about to happen with a certain degree of confidence, then show the client that is what is happening, and then the server validates that was the correct thing to have happened. And if it's wrong, you essentially roll back what the client did to what actually happened.

If you ever played Counter-Strike, for instance, it's rare but you have moments where you snipe someone with an AWP (1-shot kill sniper) and you see the blood, you see their character react as if they're dead, and then they kill you. Because client prediction showed what it thought should've happened, and its correct more than 99% of the time, but in that instance it isn't and gave you a false positive.

Unity for instance essentially bakes this into their game engine, with tags basically where you can indicate what needs to be secret and only runnable by the server and what the client should try to simulate.

IDK if this is exactly the answer, but, it's what people have been doing for ages. Most good websites do this as well, they just presume what button you're pressing worked because in reality it takes about half a second to confirm but you can feel half a second of delay, instead why not just presume it worked and move forward assuming it did because the overwhelming majority of the time it does, so that the end user feels zero disruption and instantaneous response time as far as they know.