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.

[Baugi]

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

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.

I agree that it's not weird for server-side code artifacts to be there. My contention was more that they can't be trusted since they aren't used by the client and might be stale/ect. I think it's fairly obvious that the titanium client doesn't do spell channel prediction? Generally speaking, you would never try to predict 50/50 server-side dice rolls on your client.

I concede that it's a pretty safe bet if the magic numbers from the classic-era decompile matched up well with observed behavior on Live servers (maybe that's what nilbog meant by testing?), but the use of the decompile seems very hand-wavy in everything presented.

[plonkster]

It's one thing to do client-side prediction with server-side reconciliation for some features such as movement, collision or even bullet hits. In fact, it's been the standard in gaming netcode for the last 3 decades.

Spell interruption, however, does probably not fall into this category. I have a hard time believing that the mechanic was "client rolls the save, and if it fails, it interrupts the spell effects and displays a spell interruption message, but if the server rolls the same save and succeeds, the spell still goes through". After spell interruption, hybrids would start dishing out melee swings on the client, which would not be recorded on the server since from its point of view, the character is still casting.

The EQ netcode is a hell of a clusterfuck. But I don't think they went as far as making it THIS messy.

I'm not saying this is impossible, but we'd need more proof about the client reverse engineering. Proof that this is actually how it worked, and not just "the function was in the client, therefore it must be how it worked".

- The code could be in the client but not actually used, dead or test code.
- The code could be in the client and actually used, but not be the same as the one in the server - we don't know if this code was actually SHARED with the server.

It all boils down to "do the admins want to nerf channeling on P99 or not, even if it would significantly and negatively impact most/all casting classes in order to make a few select ayatollahs happy?".

[Rygar]

I think one of the big things on a 'perfectly recreated spell casting system', even after this fix goes live, is looking at the push code. I know that little changes in your position can affect your spell casting, and can be mitigated to some degree by corner casting.

On P99 I feel mobs and PCs get pushed around like they are standing on ice. Push happened in era, but not to this degree. On current live (no idea if push code has changed), but I melee'd a frog in seb with a monk (non-twinked, no AAs) and it looked like only it's toe was on the ground, the tiniest push would put it in the river. Over the course of entire fight it didn't move a single pixel.

I seem to recall Haynar built the push code on P99 based on smallest possible push value, but i'm very curious if EVERY melee swing should institute a push. Are double attacks ignored? primary swings only? I did a bug post prior where people in era were thinking only kick/bash/slam abilities instituted a push chance/value:
https://www.project1999.com/forums/s...d.php?t=284728

Oh fuck no! Slam increases the amount of movement of the mob. Mob placement is one of the most critical aspects of killing ubers, push a dragon up a flag pole and you're almost garanteed to lose.

Couple of things - first, mage water pets generate almost no push - they don't bash or kick. If you don't give 'em proccing weapons there is no push. The other thing is that, while pets don't push *more* than a melee, they are more tenacious - they immediately move up and stay engaged with a mob - melee tend not too.
With a water pet and my kitty on the back of a mob, I can hold a mob perfectly stationary with my BL tanking

A lot of other talk about channeling in that thread

[loramin]

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

My contention was more that they can't be trusted since they aren't used by the client and might be stale/ect.

If only we had a seasoned programmer who knew all the code and evidence involved, and could make intelligent decisions about them, so the peanut gallery here didn't have to. Ideally it's be someone so authoritative, so experienced, that they'd been working on re-creating classic EQ for well over a decade.

But where, oh where, could we possibly find someone like that? [You must be logged in to view images. Log in or Register.]

[sammoHung]

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

If only we had a seasoned programmer who knew all the code and evidence involved, and could make intelligent decisions about them, so the peanut gallery here didn't have to. Ideally it's be someone so authoritative, so experienced, that they'd been working on re-creating classic EQ for well over a decade.

But where, oh where, could we possibly find someone like that? [You must be logged in to view images. Log in or Register.]

You are insufferable. I see a few people discussing technical details and then Loramin comes in to shit it up. Please continue, Kich, Rygar, Plonkster - interesting reads from you guys.

[Kich867]

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

It's one thing to do client-side prediction with server-side reconciliation for some features such as movement, collision or even bullet hits. In fact, it's been the standard in gaming netcode for the last 3 decades.

Spell interruption, however, does probably not fall into this category. I have a hard time believing that the mechanic was "client rolls the save, and if it fails, it interrupts the spell effects and displays a spell interruption message, but if the server rolls the same save and succeeds, the spell still goes through". After spell interruption, hybrids would start dishing out melee swings on the client, which would not be recorded on the server since from its point of view, the character is still casting.

The EQ netcode is a hell of a clusterfuck. But I don't think they went as far as making it THIS messy.

I'm not saying this is impossible, but we'd need more proof about the client reverse engineering. Proof that this is actually how it worked, and not just "the function was in the client, therefore it must be how it worked".

- The code could be in the client but not actually used, dead or test code.
- The code could be in the client and actually used, but not be the same as the one in the server - we don't know if this code was actually SHARED with the server.

It all boils down to "do the admins want to nerf channeling on P99 or not, even if it would significantly and negatively impact most/all casting classes in order to make a few select ayatollahs happy?".

So probably not per-hit I agree, but being bashed or stunned instantly cancels your casting. I mean again, I don't have this stuff in front of me, I've never looked at the client code or much of the eqemu code, but given laziness and simplicity it wouldn't surprise me if they basically just copied a bunch of stuff off their server code into the client and called it a day.

In other words it wouldn't shock me if the channeling code existed alongside other relevant things they put into the client.

Is it stale? Maybe, I would say with confidence that it's not arbitrary, it's not like they just wrote some channeling code in the client that they had no intention of using on their back end. So if anything, it would be stale, but that means it did work that way at some point. And, I think in cases like this, it would be more correct to put the onus on proving this isn't how it worked. Like, we know our existing channeling mechanics aren't classic the code was just yolo'd 20 years ago or whatever.

[loramin]

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

You are insufferable. I see a few people discussing technical details and then Loramin comes in to shit it up. Please continue, Kich, Rygar, Plonkster - interesting reads from you guys.

This isn't a normal "fill it with your personal thoughts" thread.

It is a big forum thread, for people to report evidence about bugs ... not speculate (without any evidential basis).

[Goregasmic]

If you're a chanter and you torch & haste your pet, you do it knowing VERY WELL that if charm breaks, it is basically trying to catch a falling knife especially on a 56+ mob, better have a wand of allure handy, an escape route or a CR contingency plan. I'm not sure anyone is meant to survive a mob that quads for 600 every second or so when you have 1.6k hp and 650ac.

[sammoHung]

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

If you're a chanter and you torch & haste your pet, you do it knowing VERY WELL that if charm breaks, it is basically trying to catch a falling knife especially on a 56+ mob, better have a wand of allure handy, an escape route or a CR contingency plan. I'm not sure anyone is meant to survive a mob that quads for 600 every second or so when you have 1.6k hp and 650ac.

What about a level 44 trash mob? To me, it seems like you should be able to get a cast off on a mob 16 levels lower than you (green con) when you've got 2300hP and 900AC.