Channeling Fix

[azxten]

Channeling rate on P99 seems to be inaccurately high particularly at lower levels. This was previously discussed in another thread but I'm starting a new one for visibility.

EVIDENCE

Old bug report:

https://www.project1999.com/forums/showthread.php?t=343453

Torven TAKP discussion on changing to the decompiled methodology:

https://www.takproject.net/forums/index.php?threads/lull-changes.12968/#post-72810

Dolalin private message to me repeating statement from TAKP dev:

Mackal is the EQEmu developer who decompiled our client. (our client is circa November 2002)

EQ Lead developer discussing when they found out they had broken channeling and reverted back to old mechanic:

https://web.archive.org/web/20061207150714/http://eqforums.station.sony.com/eq/board/message?board.id=Veterans&message.id=239994
https://web.archive.org/web/20061011111439/http://eqforums.station.sony.com/eq/board/message?board.id=Veterans&message.id=239994&view=by_date_ascending&page=3

Now its back to working how it used to, which is based on your skill, but caps at 90%. One thing to note here is that your chance to channel is better if you are casting spells lower level than yourself, which is generally when you'd hit that cap.

Correct, for each hit you take, you make the roll. The more you're getting hit, the harder it is to continue casting a spell.

The only way that the level of the NPC hitting you gets factored in is that lower con NPCs have a harder time hitting you in the first place. But if you take damage while casting a spell, you have to make a channeling roll to continue casting regardless of what it was that hit you. At that point, it doesn't care where the damage came from. The only "level" that factors into the equation at all is a bonus that gets applied if you are casting spells whose required level to cast them is lower than what you are currently.

You're right. I just took another look at it and there is some wiggle room in there. If you move more than a few inches, but less than what it takes to automatically break the spell (which is about 1 foot), you get a channeling check to keep the spell. So to answer the other person's question, if you moved a little, but not enough to automatically lose the spell, and got hit at the same time, that would be two channeling checks you'd have to succeed to keep the spell. That'd be why sticking your back up against a wall helps you get spells off easier.

Arguably these posts by Rashere imply slight differences from the client decompile. The decompile shows 370/391 max roll which is 95% cap instead of the mentioned 90%. He also says the only way level matters is spell scribe to player level difference but the decompile also adds a bonus of your player level in addition to that. Finally he confirms that distance moved is a separate channeling check roll. Currently in EQEmu code and in my modified code a penalty is applied to your channeling chance based on distance moved up to a limit where it is guaranteed to fail. All three of these changes would make channeling even more difficult if added and are contentious based on the decompile code. Rashere had previously stated distanced moved was not a separate check so he does admit he made a few mis statements. This archived thread may be worth reviewing further but I did not see any additional posts by him but I also didn't look much.

EQEMU

This is because the EQEmu code starts with a guaranteed ~30% success rate, scales up too quickly with channeling skill improvements, does a 100 roll, and only does a single channeling check roll for a spell cast which is modified by the number of times you are hit. It is widely known that the EQEmu code is based on nothing.

Classic evidence compiled from archived live EQ developer forum posts and decompiled EQ Mac client code by an EQEmu developer indicates this is incorrect. Forum posts support that a channeling roll is done separately for every time you are hit. The client decompile gives us near exact methodology for channeling during classic era.

This methodology can be summed up in the following code which is based on Dolalin's LUA pseudo code provided by the EQEmu developer who reverse engineered the classic client. I used that exact same methodology but converted to C++ code and replacing the existing spells.cpp logic.

+ spell_level_diff_bonus = GetLevel() - spells[spell_id].classes[GetClass()-1];
+ if(spell_level_diff_bonus < 6) {
+ spell_level_diff_bonus = 0;
+ } else {
+ spell_level_diff_bonus = spell_level_diff_bonus * 3;
+ }
+ channelchance = GetSkill(EQ::skills::SkillChanneling) + GetLevel() + spell_level_diff_bonus;
+ if(channelchance > 370) {
+ channelchance = 370;
+ }

+ if(!spells[spell_id].uninterruptable) {
+ LogSpells("Channel chance: [{}]", channelchance);
+ int channel_checks = attacked_count;
+ for(channel_checks; channel_checks > 0; channel_checks--) {
+ int interruptchance = zone->random.Real(0, 391);
+ LogSpells("Interrupt roll: [{}] Check Number: [{}]", interruptchance, channel_checks);
+ if(interruptchance > channelchance && interruptchance > 39) {
+ LogSpells("Casting of [{}] canceled: interrupted", spell_id);
+ InterruptSpell();
+ return;
+ }
+ }
}

METHODOLOGY

First, we get the difference between the player level and the spell scribe level. For my Enchanter example I am level 20 using a level 12 spell so the value is 9 inclusion of the scribe level.

Second, we check if the difference value is 6 or more. If not, no modifier is applied. If yes, a bonus to channeling chance is created which is 3x the difference and in this example would be 9*3 or 27.

Third, we calculate our channeling chance which is your channeling skill level, plus your player level, plus the spell scribe/player level difference bonus. In this example that is 100 channeling skill, plus level 20, plus a 27 bonus for casting a level 12 spell (Choke) giving us a chance of 147.

Fourth, we check if our channeling chance is greater than 370 and if so set it back to 370 which is the maximum chance you can have as an interrupt is always a possibility.

Fifth, once you cast this spell a count is obtained of the number of times you are attacked. At the end of the cast a separate interrupt chance roll is done for every time you were attacked. The EQEmu code caps this attack count at 15 and I have left this alone, it is unknown if classic had a cap but the decompile doesn't seem to indicate there was one. The roll value is 391 compared to your channeling chance which in this case is 147 for a level 20 Enchanter casting Choke.

This means if you are hit once the interrupt roll of 391 must be less than your channeling chance of 147. If it is higher you are interrupted. A level 20 Enchanter has a 38% chance to cast Choke through 1 attack. A level 20 Enchanter has a 31% chance to cast a level 20 spell through 1 attack. A level 50 Enchanter has a 78% chance to cast through 1 attack.

This gives the new function:

X = times hit during cast, capped at 15
Y = player level
Z = scribe level to player level difference if >=6

channel_chance(x, y, z)

((Y * 5 + 5 + Y + Z * 3) / 391)^X = A

Or for our level 20 Enchanter casting a level 12 spell and being hit 1-4 times and 15 or more times...

channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 9 * 3) / 391)^1 = 39% success rate
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 9 * 3) / 391)^2 = 15%
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 9 * 3) / 391)^3 = 6%
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 9 * 3) / 391)^4 = 2%
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 9 * 3) / 391)^15 = .0000007%

Level 20 Enchanter casting a level 20 spell and being hit 1-4 times and 15 or more times...

channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 0 * 3) / 391)^1 = 32% success rate
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 0 * 3) / 391)^2 = 10%
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 0 * 3) / 391)^3 = 3%
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 0 * 3) / 391)^4 = 1%
channel_chance(1, 20, 9) = ((20 * 5 + 5 + 20 + 0 * 3) / 391)^15 = .00000004%

A level 50 Enchanter casting a level 49 spell and being hit 1-4 times and 15 or more times...

channel_chance(1, 20, 9) = ((50 * 5 + 5 + 50 + 0 * 3) / 391)^1 = 78% success rate
channel_chance(1, 20, 9) = ((50 * 5 + 5 + 50 + 0 * 3) / 391)^2 = 60%
channel_chance(1, 20, 9) = ((50 * 5 + 5 + 50 + 0 * 3) / 391)^3 = 47%
channel_chance(1, 20, 9) = ((50 * 5 + 5 + 50 + 0 * 3) / 391)^4 = 37%
channel_chance(1, 20, 9) = ((50 * 5 + 5 + 50 + 0 * 3) / 391)^15 = 2%

This is the existing EQEmu formula and again X is capped at 15 attacks:

((30 + Y / 400 * 100) - X * 2) / 100 = A

Currently on P99 a level 1 character casting a level 1 spell and being hit 1 times with 5 channeling skill has a 29% success rate.
Level 20 casting a level 20 spell and being hit 1 times has a 54% success rate.
Level 20 casting a level 20 spell and being hit 4 times has a 48% success rate.
Level 20 casting a level 20 spell and being hit 15 or more times has a 26% success rate.
Level 50 casting a level 49 spell and being hit 1 times has a 92% success rate.
Level 50 casting a level 49 spell and being hit 4 times has a 86% success rate.
Level 50 casting a level 20 spell and being hit 15 or more times has a 64% success rate.

SUMMARY

This demonstrates how broken channeling is using the EQEmu code compared to classic decompiled channeling and developer forum post supported code changes.

A level 1 Enchanter casting a level 1 spell after being hit 1 time has a 29% success rate on EQEmu code compared to 10% on proposed classic code.
A level 20 Enchanter casting a level 20 spell after being hit 15 or more times has a 26% success rate on EQEmu code compared to .00000004% on proposed classic code.
A level 50 Enchanter casting a level 50 spell after being hit 15 or more times has a 64% success rate on EQEmu code compared to 2% on proposed classic code.

Making channeling classic would represent a fundamental change to P99 gameplay mechanics which will reintroduce difficulty at all levels of the game and likely put an end to a lot of existing "cheesy" strategies. It may also even allow reverting AE group nerf changes as AE killing mobs would be significantly more challenging. This change will reintroduce a lot of the difficulty involved in soloing in particular especially indoors or without SoW/Jboots and in theory should encourage more grouping and social behaviour which I feel is lacking on P99 due to the ease of soloing and primarily related to channeling ability. It may also add to the difficulty of high level play including raiding and especially in situations where players are currently relying on being able to cast while being attacked by multiple high level mobs.

NOTE: Dolalin mentioned he has provided the LUA code from EQEmu dev who decompiled the classic client. I have this as well but won't post it since he probably wanted it kept private for a reason and will leave that up to him to repost if needed. A patch file is attached for my code changes.

NOTE2: I also change the NPC channeling chance from EQEmu 85 to 391 in my patch because the channeling roll changes from 100 to 391 which means NPC channeling also needs to conform to this higher roll. The NPC channeling chance on P99 already seems to be modified so that would need to be reviewed by devs to ensure this change doesn't interfere. I don't know how NPCs calculate distance moved channeling check or if they are using the EQEmu code, I imagine they're using a different code base.

NOTE3: There is also a "&& interruptchance > 39" in the code which I didn't mention above. This is the lower limit of channeling chance from the classic decompile which effectively sets your channeling chance to 39 and was likely to help lower level players. A level 3 player with the formula above has a 6% chance to channel through 1 hit for example, level 1 is only 3% chance. This bit of code raises the channel success rate to 10% for level 1-5 and then at level 6 the formula scales to higher than 10%.

NOTE4: I have done no validation for Bard songs, NPCs, etc because that code seems to be handled by separate code blocks within the same function. Might be worth checking before making this live.

NOTE5: The reason I left the attack cap at 15 attacks is due to performance concerns. I have not stress tested or validated performance changes due to this code change. A character being hit 1,000 times would previously do 1 random, now they will do 15, without a cap they would do 1,000. This seems like it has some potential to degrade performance but limiting to 15 per character should avoid that while still approaching a near 0% success rate. It may be worth considering adding something like if attack count is > 30 we just guarantee an interrupt of the spell. This would avoid rolls where players are hit >30 times instead of doing the 15 rolls and would guarantee that if players are being hit excessively they will fail rather than giving them that small chance of success which according to the decompile and dev statements doesn't exist.

NOTE6: Although I enjoy trolling Enchanters this change is intended to make P99 more classic and my quest to fix this began when I was just bored with P99. I saw too many people soloing, power leveling up alts due to the ease of leveling, and generally being unsocial jerks in the game. I knew live EQ was much more challenging to solo on any caster class and that this is a big part of why grouping was more popular except for the few classes like Necro, Druid, etc who had ways to avoid channeling checks via pets, run speed buffs, etc.

I'll end with archived Enchanter tears from the archived thread above where an Enchanter was crying that now they won't be able to crowd control as easily since the old channeling code is being restored. This matches the live Enchanter experience where Enchanters died more than any other class and were in short supply for that reason as no one wanted to play it. Enchanter is powerful but also should be much more difficult to play well and their power is primarily level 50+.

Enchanters need to be able to cast under fire to be able to perform crowd control duties properly. This was already a problem area for enchanters before this change.

[azxten]

Patch file:

https://www.pastefile.com/2969hw

--- spells.cpp 2021-12-04 13:17:30.931386378 -0800
+++ /home/eqemu/server_source/zone/spells.cpp 2021-12-04 13:11:13.223277487 -0800
@@ -1130,11 +1122,11 @@
// but cap it so it's not that large a factor
if(attacked_count > 15) attacked_count = 15;

- float channelchance, distance_moved, d_x, d_y, distancemod;
+ float channelchance, channelbonuses, spell_level_diff_bonus, distance_moved, d_x, d_y, distancemod;

if(IsClient())
{
- float channelbonuses = 0.0f;
+ channelbonuses = 0.0f;
//AA that effect Spell channel chance are no longer on live. http://everquest.allakhazam.com/history/patches-2006-2.html
//No harm in maintaining the effects regardless, since we do check for channel chance.
if (IsFromItem)
@@ -1142,9 +1134,17 @@
else
channelbonuses += spellbonuses.ChannelChanceSpells + itembonuses.ChannelChanceSpells + aabonuses.ChannelChanceSpells;

- // max 93% chance at 252 skill
- channelchance = 30 + GetSkill(EQ::skills::SkillChanneling) / 400.0f * 100;
- channelchance -= attacked_count * 2;
+ //
+ spell_level_diff_bonus = GetLevel() - spells[spell_id].classes[GetClass()-1];
+ if(spell_level_diff_bonus < 6) {
+ spell_level_diff_bonus = 0;
+ } else {
+ spell_level_diff_bonus = spell_level_diff_bonus * 3;
+ }
+ channelchance = GetSkill(EQ::skills::SkillChanneling) + GetLevel() + spell_level_diff_bonus;
+ if(channelchance > 370) {
+ channelchance = 370;
+ }
channelchance += channelchance * channelbonuses / 100.0f;
}
#ifdef BOTS
@@ -1164,7 +1164,7 @@
#endif //BOTS
else {
// NPCs are just hard to interrupt, otherwise they get pwned
- channelchance = 85;
+ channelchance = 391;
channelchance -= attacked_count;
}

@@ -1174,13 +1174,13 @@
{
d_x = std::abs(std::abs(GetX()) - std::abs(GetSpellX()));
d_y = std::abs(std::abs(GetY()) - std::abs(GetSpellY()));
- if(d_x < 5 && d_y < 5)
+ if(d_x < 3 && d_y < 3)
{
//avoid the square root...
distance_moved = d_x * d_x + d_y * d_y;
// if you moved 1 unit, that's 25% off your chance to regain.
// if you moved 2, you lose 100% off your chance
- distancemod = distance_moved * 25;
+ distancemod = distance_moved * 100;
channelchance -= distancemod;
}
else
@@ -1189,13 +1189,22 @@
}
}

- LogSpells("Checking Interruption: spell x: [{}] spell y: [{}] cur x: [{}] cur y: [{}] channelchance [{}] channeling skill [{}]\n", GetSpellX(), GetSpellY(), GetX(), GetY(), channelchance, GetSkill(EQ::skills::SkillChanneling));
+ LogSpells("Checking Interruption: spell x: [{}] spell y: [{}] cur x: [{}] cur y: [{}] channelchance [{}] channeling skill [{}] channelbonuses [{}] channel_checks [{}] level diff bonus [{}] \n", GetSpellX(), GetSpellY(), GetX(), GetY(), channelchance, GetSkill(EQ::skills::SkillChanneling), channelbonuses, attacked_count, spell_level_diff_bonus);

- if(!spells[spell_id].uninterruptable && zone->random.Real(0, 100) > channelchance) {
- LogSpells("Casting of [{}] canceled: interrupted", spell_id);
- InterruptSpell();
- return;
+ if(!spells[spell_id].uninterruptable) {
+ LogSpells("Channel chance: [{}]", channelchance);
+ int channel_checks = attacked_count;
+ for(channel_checks; channel_checks > 0; channel_checks--) {
+ int interruptchance = zone->random.Real(0, 391);
+ LogSpells("Interrupt roll: [{}] Check Number: [{}]", interruptchance, channel_checks);
+ if(interruptchance > channelchance && interruptchance > 39) {
+ LogSpells("Casting of [{}] canceled: interrupted", spell_id);
+ InterruptSpell();
+ return;
+ }
+ }
}
+
// if we got here, we regained concentration
regain_conc = true;
MessageString(Chat::Spells, REGAIN_AND_CONTINUE);

Screen shots of testing:

https://imgur.com/a/zncfhij

Successful cast

https://i.imgur.com/g1P31By.png

Two rolls failure

https://i.imgur.com/apTNBR3.png

One roll failure, we don't reroll if you failed the first roll

https://i.imgur.com/vbKMN2h.png

[Lich]

Stop spamming.

[Dolalin]

I confirm I supplied the LUA pseudocode that Torven sent me from TAKP for this change.

[Tunabros]

nilbog isnt going to even glance at this bro

[Gustoo]

I don't know nilbog but this looks like an exemplary bug report and your shit posting isn't warranted in this guys thread. In my threads I consider it acceptable but only because I'm a bristlebane guy.

[azxten]

It's okay I like the haters. Nilbog already said in PM he'll review it but it also likely warrants testing as I noted which may take awhile.

[loramin]

nilbog isnt going to even glance at this bro

Shitpost elsewhere: this is the bugs forum.

[starkind]

Feels good. On classic I corner casted AoE spells with like 8 mobs on me as a wiz, more than that was crazy, I imagine sometimes they missed it was hard and not easy.

Otherwise I would strafe run and turn a bit to try and get a root off if out of doors.

[nilbog]

I haven't had the time to review this yet, but if it is an improvement on our existing system, it will certainly be considered and credit given where it is due.

[eisley]

This ones up there with Torched charm pets on the "why hasn't this been fixed yet?" tier list.

[azxten]

Oh it's gonna get fixed, I have full faith, and it will be GLORIOUS.

[eisley]

I know it's frowned upon to bump without additional evidence, but I just wanted to ask Nilbog, if you've had time to look at this?

I think it's time to squash the last few glaring bugs on p99. Channelling, Charm duration, Charm pet auto-quad with Torch, Memblur success rate, Sleeper's Tomb trash revamp, Fist weapons (Tunare, Eashen), Hoshkar Cleric staff, Raid bosses not gating when on their spawn point, etc.

Yeah, people won't be happy. But either rip off the bandaid or just tell us it's not gonna happen. The way Baton of Flame was handled was annoying, why not address all the other obviously broken weapons at the same time, so people don't feel targetted? Same deal with the Monk Sneak memblur fix, should've fixed Charm and Enc blur at the same time.

I know it's not that simple, and I appreciate all the Devs have done. I've been around since beta and have submitted dozens upon dozens of bugs. But we're 7 years into Velious. If you're burnt out, that's understandable, but maybe consider bringing on some new blood to address some things?

[long.liam]

I know it's frowned upon to bump without additional evidence, but I just wanted to ask Nilbog, if you've had time to look at this?

I think it's time to squash the last few glaring bugs on p99. Channelling, Charm duration, Charm pet auto-quad with Torch, Memblur success rate, Sleeper's Tomb trash revamp, Fist weapons (Tunare, Eashen), Hoshkar Cleric staff, Raid bosses not gating when on their spawn point, etc.

Yeah, people won't be happy. But either rip off the bandaid or just tell us it's not gonna happen. The way Baton of Flame was handled was annoying, why not address all the other obviously broken weapons at the same time, so people don't feel targetted? Same deal with the Monk Sneak memblur fix, should've fixed Charm and Enc blur at the same time.

I know it's not that simple, and I appreciate all the Devs have done. I've been around since beta and have submitted dozens upon dozens of bugs. But we're 7 years into Velious. If you're burnt out, that's understandable, but maybe consider bringing on some new blood to address some things?

They have more than 3,700 submitted Bug posts to go through. And that is just what is in this Subforum, they doesn't include the posts in Green Bugs, Quest Bugs, Spells, Mechanics, Merchants, NPC Bugs, Pathing etc...

They don't have a full time professional IT staff to do this Stuff, its just 2 dudes in their spare time when they feel like, working on issues here and there.

Be Patient, its gonna be a long while before this post and a lot others ever get reviewed if ever.

[long.liam]

Also A lot people waste their time by not reading the directions at the top of the page. I would imagine quite a few of the bug submissions are duplicate bug reports or simply don't have any sources cited.


#3
Old 10-01-2011, 08:23 AM
nilbog nilbog is offline
Project Manager
"
nilbog's Avatar

Join Date: Oct 2009
Posts: 14,233
Default
With the new round of beta testing, this is highly relevant.

Please make sure to include all the information you can about an issue.

I'm wasting a lot of time reading posts with no research or links.

Thanks.
"

[eisley]

Yeah, that was kinda my point. We used to have a lot more GMs. Uthgard, Sirken, etc. I don't believe we've added a new one since beta.

This game has always been nilbog's vision, and he's done an insane amount of work. Why not bring on a volunteer to address some of these longstanding bugs, and submit them to nilbog for approval? That way he doesn't have to be a one man team, and accomplish his goal faster.

And yes, I realize the numerous messy breakups of former staff members probably makes them hesitant.

[long.liam]

Yeah, that was kinda my point. We used to have a lot more GMs. Uthgard, Sirken, etc. I don't believe we've added a new one since beta.

This game has always been nilbog's vision, and he's done an insane amount of work. Why not bring on a volunteer to address some of these longstanding bugs, and submit them to nilbog for approval? That way he doesn't have to be a one man team, and accomplish his goal faster.

And yes, I realize the numerous messy breakups of former staff members probably makes them hesitant.

I think it might be unrealistic to expect anything to change at this point. While there are talented software engineers out there who could probably help fix a lot of the issues here, it's very unlikely many of them would be interested in doing unpaid work on emulator of a old video game. The few that would are probably mostly P99 players. Rogean and Nilbog would likely see that as a conflict of interest. I don't foresee things getting any better soon.

[eisley]

I think it might be unrealistic to expect anything to change at this point. While there are talented software engineers out there who could probably help fix a lot of the issues here, it's very unlikely many of them would be interested in doing unpaid work on emulator of a old video game. The few that would are probably mostly P99 players. Rogean and Nilbog would likely see that as a conflict of interest. I don't foresee things getting any better soon.

You're probably right. I even offered my own services, as I have years of experience as a volunteer Dev/GM on another popular EQEmu game, and I'm not an active raider so there shouldn't be any conflict worries. I never got a reply.

It sucks, but, yeah, guess it's time to accept it.

[DMN]

Oh it's gonna get fixed, I have full faith, and it will be GLORIOUS.

Indeed.

https://wiki.project1999.com/Color_Flux

[azxten]

Bump, coming up on 6 months since last staff response, I think that qualifies under the request that bugs not be bumped unless it has been a long time.

[azxten]

Revive the servers, fix channeling and restart green.

[long.liam]

Stop bumping bug posts for no reason. Unless you have a new evidence to add, then don't bump the post. Nilbog and Rogean will get to it when they get to it. It's a free to play emulated game. Just be grateful you get to play at all.

[azxten]

I'm gonna post when I wanna post

[Jujuminjo]

At this point the devs are just ignoring this, same with the Enchanter class bieng broken, they either don't want to admit they are wrong or they have other motive$.

[Dolalin]

I feel like if anyone were making money from p99 it would be patched more often, lol.

There are some really wild conspiracies floating around. All of them smell like BS.

[Croco]

I feel like if anyone were making money from p99 it would be patched more often, lol.

There are some really wild conspiracies floating around. All of them smell like BS.

^ this

Feel real bad for you guys. Almost a full year and no patch. Yikes.

[Jujuminjo]

^ this

Feel real bad for you guys. Almost a full year and no patch. Yikes.

It's like someone doesn't want to patch this at all, same with Encheaters.

[azxten]

I'm hopeful they realized such drastic changes should happen on a new server launch not in the middle of a server that is still wrapping up. Despite what Enchanters claim about how if channeling was fixed they'll just stun I know in my heart that the level of crying and rage if this fix goes in will be epic and it won't just be Enchanters.

There is a real chance all those players who thought level 1-50 was just AFKing in a power level group using back stabbing pets aided by endless alt buff bots will quit the game before they have to face actual classic EQ. The simple "get this mob off of me!" running in circles mainstay of classic EQ is missing because of this bug and it trivializes the entire game. Maybe that's a good thing.

All I know is green server launch fucking sucked in my opinion. Fast mob spawns. Nerfed quests. Instanced teal server. It's pretty hard to overlook that the staff seems to be on board with the idea that the only thing anyone likes about EQ is raid pixels and so we need to get people there as fast as possible. "Newb zones are crowded at server launch, we added a second server that we'll merge back later, and all newb mob spawns are fast! Yay!" That is when P99 jumped the shark. It was so painful because they had actually fucking recreated classic! It was overcrowded, it was busy, things were lively and fun and social. It had to go. Too many petitions or people weren't stacking up at raid level fast enough to satisfy the UN guild leaders. Timmy stole my decaying skeleton with a crack staff! What is the staff going to do about this?!? It's against the rules! Someone do something! I have a video recording! Staff always seems to cave to this utter bullshit instead of telling people to toughen up and holding back the pimp hand for times when it is actually warranted. They go for wide spread mechanic changes to avoid people crying at each other. See /list. There, you have /list, aren't you happy now? No more petitions please! Send all those petitions to the garbage especially anything relating to raid shenanigans and server would be much better and closer to classic.

[azxten]

Bump

[azxten]

Bump

[Trexller]

Nilbog should ask Yeahlight to help out. I bet he would if asked nicely.

[azxten]

Bump

[azxten]

Just gonna bump this again, hope devs get some free cycles. Try to pull this one into the next sprint.

[CrazyPro]

ㅤ

[nilbog]

I have been working on this and have a proposal under review for the other devs.

Thanks azxten for the attention to the issue. While your diff isn't a drop in replacement, it helped confirm methodology alongside the TAKP implementation.

The biggest change players will feel is multiple hits. Instead of one roll with a small penalty per hit, the classic formula rolls separately for each hit. This means getting hit multiple times while casting is harder to channel through.

This should bring channeling in line with classic EQ behavior where getting wailed on meant your spell was probably not going to land.

[loramin]

https://bestanimations.com/media/fireworks/671801409ba-awesome-coloful-fireworks-animated-gif-image-3.gif

https://media.tenor.com/0Sh7u1lRsyEAAAAM/wedding-crasher-hro.gif

https://media.tenor.com/LR8PZyI-r94AAAAM/yay-seinfield.gif

https://media0.giphy.com/media/26xBENWdka2DSvvag/200w.gif

[CrazyPro]

HUGE BUFF TO OGRES, HELL YES
NOW MY FSI IS LESS USEFUL
MINOR RELATIVE NERF TO OGRES, HELL NO
SERVER MORE CLASSIC, HELL YES
CASTER NERF, HELL YES

this is overall a HELL YES update, good job team

[Kich867]

Can someone ELI5, would this affect monsters as well? Leveling in SolB atm and the shamans for instance are just really fuckin annoying. If this went through would that mean fighting casters is easier since they should get interrupted far more often?

Or is this a player-only thing?

[sammoHung]

HUGE BUFF TO OGRES, HELL YES
NOW MY FSI IS LESS USEFUL
MINOR RELATIVE NERF TO OGRES, HELL NO
SERVER MORE CLASSIC, HELL YES
CASTER NERF, HELL YES

this is overall a HELL YES update, good job team

There was already a ninja channeling nerf about 4 years ago that made FSI unreliable. Max ogre, shrunk, with back to corner still gets spells interrupted currently -- will be worse after patch ;)

[sammoHung]

Can someone ELI5, would this affect monsters as well? Leveling in SolB atm and the shamans for instance are just really fuckin annoying. If this went through would that mean fighting casters is easier since they should get interrupted far more often?

Or is this a player-only thing?

Nah players only. They already buffed mob channeling years ago - its why you cant reliably interrupt a caster mob with melee push

[JayDee]

I was wondering what the hell happened to channeling recently. Why isnt this posted on the front page

[Goregasmic]

I was wondering what the hell happened to channeling recently. Why isnt this posted on the front page

Nothing changed yet so if by "recently" you mean a couple years ago...

[Kich867]

It's either all of one or the other, no?

No I think it's very literally whatever they want to work on when they feel like doing it.

I don't think it goes past that or really needs any additional scrutiny.

[usmcjdking]

Nilbog, if it's not terribly complicated, would you consider having this chance to interrupt scale linearly as you get hit wherein an internal counter resets on either spell interrupt or spell completion through random distribution?

For example, if you need to make a 90% chance roll, the initial hit during a cast would have a 1.5% chance to interrupt, the second hit 3%, then 4.5% until the spell is interrupted or completed where the counter resets. This gives you an average number of attacks of 10, no different than a roll but much less vulnerable to lucky/unlucky streaks. It's a lot more stable of an output than just a roll, and doesn't result in massive streaks.

I think this will have a much better desired effect on the gameplay than a roll on each attack. Not opposed to the idea of fixing channeling in this manner you suggested, works but a fair bit blunt.

[nilbog]

My proposal is the same as what was available from the aforementioned client decompile in the OP, which was also compared against the Kunark decompile, and the results are essentially the same. What is being proposed is not inherently non-classic. What currently exists was 'made up' by solar from eqemu like 20+ years ago. It worked fine for the time, but with real information available, not using it, to me, is more inherently non-classic.

That being said, we are actively testing this and reviewing. That is why you haven't seen a 'Fixed, pending update.'

[usmcjdking]

My proposal is the same as what was available from the aforementioned client decompile in the OP, which was also compared against the Kunark decompile, and the results are essentially the same. What is being proposed is not inherently non-classic. What currently exists was 'made up' by solar from eqemu like 20+ years ago. It worked fine for the time, but with real information available, not using it, to me, is more inherently non-classic.

Looks good then. I could have easily misinterpreted what was provided and what you said, which looks to be the case. Thanks for the response and the hard work!

[Duik]

Idiots. Please dont annoy the devs who makes your sandbox game possible.
Im sorry but this crybaby bullshit is annoying me, and im not even the target.

Nilbog and Rogean must work in childcare IRL. All Im sayen.

[Jimjam]

I'm amazed at what a convincing job Solar did in pulling a convincing emulation of classic EQ 'from his ass'. Consider how much depth of time and investigation is required to correct the discrepancies, and even with the corrections Solar's attempts are so convincing people remain convinced they are more classic than the actual client decompiles!

Nilbog you're a saint to continue going the extra mile on correcting what many would consider 'already close enough'. Thank you!

I hope we can continue to support you in your quest for true classic! Keep us posted on where you require further research!

[Danth]

Someone getting hit a dozen times during a cast *shouldn't* be landing spells through it more than once in a blue moon. That's what EQ was, glossed over by 16 years of P99 players who either never played or can't remember original. You could root something hitting you, maybe a two pull, but you weren't going to waltz into Karnor and brute force solo root a 5 pull. Even SK casted feign death was troublesome at times and that's a 1.5 spell, it's why monks were the preferred splitter, insta-feign, not like P99 where outside raids SK's and necros do it way easier. P99 has for many years been effectively EZ-mode EQ. Part of the reason P99'ers do stuff the original players didn't wasnt entirely because "Gee golly those old boomers back then sure sucked," but because the P99 tactics were in many cases outright impossible or very improbable in-era. I have the same justifiable worry that the P99 team might overdo it (look at the awful and still-broken spell aggro change!), but the present implementation is undoubtedly way too lenient.

One thing I don't recollect or know, personally, was whether double attacks counted as one or two attacks in terms of having to roll a channeling check. That was behind the curtain and players couldn't see it directly.

[barda444]

is this more of an issue at lower levels? i get interrupted on a 60 enc trying to stun 3-4 mobs very often

[Mortdecai99]

is this more of an issue at lower levels? i get interrupted on a 60 enc trying to stun 3-4 mobs very often

Yea, my haste capped (tola + torch) enchanter pets push me across the room all the time.

[nilbog]

Posts unrelated to confirmed defects have been removed.

This forum is reserved for bug reporting and verification. Direct all other discussion to the appropriate sections.

[sammoHung]

Nilbog, given the statistical probability of landing a cast through multiple hits - how did Knights fair during classic era?

If they had to perform a roll for each hit mid-cast, it'd be pretty rare for a knight to ever land a spell mid-fight if tanking. Was any research done on this matter to corroborate the proposed change?

[nilbog]

Not sure where you're getting your statistical probability from - you can't see my code proposal.

The information presented in this thread is incomplete, particularly with respect to the referenced decompile data. Any conclusions drawn without that context are inherently limited.

[Danth]

how did Knights fair during classic era?

As someone who played paladins especially a lot back then, and SK's (as alts) to a lesser extent: Aggro was fine, typically-used aggro spells and stuns casted fast enough that you could either time them between swings or at worst might get hit once. Not a big deal. Disease Cloud doing near-zero aggro on P99 (wasn't nerfed until 2002 in the original timeline) should hopefully be rectified at some point. As noted above, casted feign death could be troublesome if you pulled an entire room and were trying to cast it vs 4 or 5 mobs hitting you. Slow casting spells like the high level lifetaps were difficult to use vs unslowed enemies and pretty much worthless vs multiples, that's a big part of why hybrids were given spellhaste during Velious.

[sammoHung]

It's a simple equation. To determine the chance of winning all X of X rolls, with starting probability P(1): P(x of x) = P(1) ^ x

[sammoHung]

As someone who played paladins especially a lot back then, and SK's (as alts) to a lesser extent: Aggro was fine, typically-used aggro spells and stuns casted fast enough that you could either time them between swings or at worst might get hit once. Not a big deal. Disease Cloud doing near-zero aggro on P99 (wasn't nerfed until 2002 in the original timeline) should hopefully be rectified at some point. As noted above, casted feign death could be troublesome if you pulled an entire room and were trying to cast it vs 4 or 5 mobs hitting you. Slow casting spells like the high level lifetaps were difficult to use vs unslowed enemies and pretty much worthless vs multiples, that's a big part of why hybrids were given spellhaste during Velious.

This helps to shed light on what I'm talking about. If the quick-casting spells were primarily relied upon during combat, because anything longer duration was near-impossible to cast - that lines up with the theory that each additional hit adds a new roll that you must also win to succeed cast.

[Crede]

this is just gonna start making monks more OP than they already are. I suspect we will see a lot more monk/shaman duos like back in the day or monk cleric bc that is probably the best duo right now.

[Rygar]

this is just gonna start making monks more OP than they already are. I suspect we will see a lot more monk/shaman duos like back in the day or monk cleric bc that is probably the best duo right now.

Channeling on NPCs is different, sounds like you are implying monks may interrupt casters better? Historically NPCs had insane channeling where PCs had weak channeling

Mcoy has a log where his wizard Qien, maybe 50+, was getting interrupted by green agro skellies

[Goregasmic]

Channeling on NPCs is different, sounds like you are implying monks may interrupt casters better? Historically NPCs had insane channeling where PCs had weak channeling

Mcoy has a log where his wizard Qien, maybe 50+, was getting interrupted by green agro skellies

On live I would epic rune my 60 wizard (doesn't stop interrupts), aggro nearly the entire 2nd floor of TOFS and get a winds of gelid off. Sometimes I'd get interrupted once or twice then cast it again but it would always go off with like 20+ mobs on me.

WoG has a 6 seconds cast time.



For his monk comment I think he's implying they're already powerhouses and it is going to put them at a greater advantage compared to paladins and shadow knights or even rangers who have to cast while getting beat on to do their job effectively.

[blueknight]

I die all day on my enchanter when i get an extra mob or two I wasn't expecting and can't even get an aoe stun off half the time due to interrupt. My enchanter's entire build is based on AC to increase my chance of recovering from a mistake. What azxten is proposing sounds like it will just make it to where my deaths are 100% rather than 60% in those scenarios, and I'd probably just stop using that character altogether except for raid buffs (I certainly would stop trying to acquire AC gear like Bucker of Insight and instead go for the mana build Essence of Nature to be a buff bot). This eliminates interesting caster builds like AC builds, making casters a little more one-note and boring. A lot of people enjoy the subtle mechanics of the game and enjoy theory crafting specific purpose builds. Don't 'fix' something that isn't broken I say.

[Rygar]

Fix what isn't broken? Dev response literally said the system you are using isn't classic (i.e. broken) and was just conjured into being based on best guesses at the time. The client decompile for in era will make it as accurate as possible to classic.

Fear not neckbeards, P99 players have always adapted and will continue to do so. Worst case you need to duo certain content in a "massive multiplayer game", not the end of the world, just a good opportunity to make a friend (or eat a boxing ban)

[PatChapp]

I die all day on my enchanter when i get an extra mob or two I wasn't expecting and can't even get an aoe stun off half the time due to interrupt. My enchanter's entire build is based on AC to increase my chance of recovering from a mistake. What azxten is proposing sounds like it will just make it to where my deaths are 100% rather than 60% in those scenarios, and I'd probably just stop using that character altogether except for raid buffs (I certainly would stop trying to acquire AC gear like Bucker of Insight and instead go for the mana build Essence of Nature to be a buff bot). This eliminates interesting caster builds like AC builds, making casters a little more one-note and boring. A lot of people enjoy the subtle mechanics of the game and enjoy theory crafting specific purpose builds. Don't 'fix' something that isn't broken I say.

I assume your level enc is lvl 60 going by the tone of your post,so im wondering where are you fighting that your dieing 60% of the time on charm breaks?
I think the only zone where that might happen is sirens,otherwise maybe your reaction time/spell loadout is the issue. Seb/chardok/pom your death rate should be pretty low really.

[sammoHung]

I have died on my 60 necro with AC build to a hasted, torched level 44 pet. It's uncommon but not rare. Sometimes you just get chain interrupted and can't get a single cast off. It's extremely frustrating to watch a mob chew through 2300 HP while every single cast attempt gets interrupted. Have even done the Benny Hill kiting around trying to get FD off, but it's not a short cast.

[Jimjam]

I have died on my 60 necro with AC build to a hasted, torched level 44 pet. It's uncommon but not rare. Sometimes you just get chain interrupted and can't get a single cast off. It's extremely frustrating to watch a mob chew through 2300 HP while every single cast attempt gets interrupted. Have even done the Benny Hill kiting around trying to get FD off, but it's not a short cast.

Instacast mallets were godmode for making petbreaks easier to channel.

[loramin]

I have died on my 60 necro with AC build to a hasted, torched level 44 pet. It's uncommon but not rare. Sometimes you just get chain interrupted and can't get a single cast off. It's extremely frustrating to watch a mob chew through 2300 HP while every single cast attempt gets interrupted. Have even done the Benny Hill kiting around trying to get FD off, but it's not a short cast.

In classic EverQuest (ie. what this place is trying to recreate) charmers died uncommonly (if not commonly) from un-torched, un-hasted pets. The idea of giving a charmed pet a weapon and haste would have been crazy to the vast majority of charmers, because (just like you) they didn't want to die.

https://i.pinimg.com/originals/28/5e/2e/285e2ee3e559c3f6521facb074eb1425.gif

If anyone doubts that this thread should exist, just use Dolalin's amazing classic evidence search tool, https://search.eqarchives.org to search for yourself.

If anyone can present evidence that classic charmers were regularly and safely using haste and/or any weapon (I'm not sure the torch trick was universally known back then) then I will buy them beer IRL ... or at least Venmo the money for one.

[Jimjam]

I’m not convinced the torch trick was even a thing back then. How NPCs equipped weapons was very different. I can’t be the only one that remembers guards would often display a two hander and a shortsword in secondary?

[Rygar]

I’m not convinced the torch trick was even a thing back then. How NPCs equipped weapons was very different. I can’t be the only one that remembers guards would often display a two hander and a shortsword in secondary?

I remember reading that sneaking behind Raster spawn and handing him a mino horn actually disabled his dual wield, but that was a live comment imported to wiki at the time. It didn't work on P99.

[Danth]

IÂ’m not convinced the torch trick was even a thing back then. How NPCs equipped weapons was very different. I canÂ’t be the only one that remembers guards would often display a two hander and a shortsword in secondary?

I handed mobs shields many times for funzies (can't do that to uncharmed mobs on P99 either, but in original EQ you could) and it sure as heck didn't make them dual wield. Ultimately not too big a deal since giving stuff two weapons always worked...more of a visual irritant. Proof would be welcome if someone can find it, but player power is the same in the end either way.

Don't forget that channeling changes should *not* make it impossible to cast through multiple hits, just less consistent than it is today on P99. If it became totally impossible (or even excessively improbable) to cast through successive hits that'd be an indicator of a problem. People could and did channel at times through two-three-four-ten-etc hits. It mattered with things like charm pets because a solo enchanter might not live long enough to channel through several interrupts, not because he couldn't eventually get a cast off provided he stayed alive. And no, enchanters arming/hasting their charm pets was mostly a thing done (infrequently!) as a sort of joke, expecting to eventually have bad results. Either the ench eventually got flattened, or he'd get healed then the healer has said hasted/charmed pet hitting her in the face. Either way it was widely considered more trouble than it was worth and few groups tried it, certainly not regularly.

Oh and don't even get me started on the mez spells not memblurring every other cast or so the way the level 4 mez does on P99. If they blurred it was exceedingly rare. Enchanters weren't memblurring themselves out of (the very high) aggro they generated from CC'ing....pre-taunting mezzed mobs or ench trying to root them before break or the ench getting beat up was very much a thing, too. P99 enchanters have long benefitted from multiple issues that turn them into a sort of superhero parody of what they were.

[Baugi]

NOTE: Dolalin mentioned he has provided the LUA code from EQEmu dev who decompiled the classic client. I have this as well but won't post it since he probably wanted it kept private for a reason and will leave that up to him to repost if needed.

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.

[Kich867]

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]

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/showthread.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]

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? :confused:

[sammoHung]

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? :confused:

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]

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]

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]

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.

[plonkster]

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.

The proposed "fix" isn't about surviving a hasted mob that quads for 600.

It's about being a level 60 BiS wiz/dru/clr/(petless enc/nec/mag) and having close to zero odds of winning against a Blackburrow train.

[Goregasmic]

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.

You can, but if you haste and torch it it still quads just as fast but for 480 or so. Damage doesn't matter really it is the number of hits.

The proposed "fix" isn't about surviving a hasted mob that quads for 600.

It's about being a level 60 BiS wiz/dru/clr/(petless enc/nec/mag) and having close to zero odds of winning against a Blackburrow train.

Blackburrow train probably will miss 99% of swings. I reserve judgement for when the patch hits.

Like I said earlier I remember I could cast a 6 second spell with 3/4 the 2nd floor of TOFS on me but against level appropriate content if you get cornered by 4 mobs it was usually over. On here you got like 90% chance to get a stun off with 4 mobs bashing your head in. Seems overkill.

[sammoHung]

You can, but if you haste and torch it it still quads just as fast but for 480 or so. Damage doesn't matter really it is the number of hits.



Blackburrow train probably will miss 99% of swings. I reserve judgement for when the patch hits.

Like I said earlier I remember I could cast a 6 second spell with 3/4 the 2nd floor of TOFS on me but against level appropriate content if you get cornered by 4 mobs it was usually over. On here you got like 90% chance to get a stun off with 4 mobs bashing your head in. Seems overkill.

That hasn't been my experience, overall. On p99 green I used to use a level 60 druid to Powerlevel in Sol A, and the goblins there would pretty routinely interrupt spells - even with only 2-3 goblins attacking me. Not even bashes, just regular attacks. That's with back to corner, etc.

Not to mention, on an Ogre shaman, fully shrunk with back stuck in corner, I have gotten interrupted on casts from regular melee attacks.

[Goregasmic]

That hasn't been my experience, overall. On p99 green I used to use a level 60 druid to Powerlevel in Sol A, and the goblins there would pretty routinely interrupt spells - even with only 2-3 goblins attacking me. Not even bashes, just regular attacks. That's with back to corner, etc.

Not to mention, on an Ogre shaman, fully shrunk with back stuck in corner, I have gotten interrupted on casts from regular melee attacks.

I can say on live I was getting interrupted a lot more in general, just when trying to cast root and stuff like that but I also got to cast a 6 seconds AE regularly with 3/4 of the 2nd TOFS floor on me so like I said, it kinda depended a lot. We'll see. If it makes no sense we'll all be here saying so.

[loramin]

I see two options for everyone concerned about this ticket ...


Post like you're chicken little: assume (with no evidence) that it will result in the death of the game, at least for all charmers
Trust that the guy who has tirelessly volunteered his time for fifteen years to build this project isn't an idiot, and that his goal is to recreate classic EQ (where people did charm ... it was just a bit harder)


I know nothing I can say can stop people from picking #1, but seriously, consider #2.

[Jimjam]

I remember timing my casts to happen between npc swings on live. Never felt necessary here.

[Baugi]

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? :confused:

Friend, I'm trying to ask clarifying questions about the evidence already presented because that's generally the best way to start your own research. nilbog is great, but this thread is also 4+ years old so there's obviously a lot on his plate. I promise I have no vested interest in the outcome.

I'm still unclear whether the proposed code is entirely based on the decompile or used the magic numbers(I see the channelchance cap and interruptchance threshold) and supplemented with Live data? Personally, I don't mind TAKP's strategy of confirming against Live data but it's obviously a problem if I try to confirm Live derived formulas with more Live data.

[loramin]

Friend, I'm trying to ask clarifying questions about the evidence already presented because that's generally the best way to start your own research. nilbog is great, but this thread is also 4+ years old so there's obviously a lot on his plate. I promise I have no vested interest in the outcome.

I'm still unclear whether the proposed code is entirely based on the decompile or used the magic numbers(I see the channelchance cap and interruptchance threshold) and supplemented with Live data? Personally, I don't mind TAKP's strategy of confirming against Live data but it's obviously a problem if I try to confirm Live derived formulas with more Live data.

Again, you (or anyone else posting non-evidence posts here) have two options:


Wait until Nilbog releases an update, and you'll find out ... like every other player does with every other change to the project
Make a nuisance of yourself in a bug thread, which DOES NOT EXIST to answer player questions about upcoming changes! It exists to collect evidence to help Nilbog improve P99.


In other words there's no "researching" what the change will be: if you're here and not posting evidence you are getting in the way of the people who do. Even this post I'm making doesn't belong ... but I'm making it out of frustration.

Nilbog has spent fifteen years of his life building a game for you to play. The absolute least you can do is respect his wishes, and only post bug stuff in the bug forum.

[Baugi]

The absolute least you can do is respect his wishes, and only post bug stuff in the bug forum.

This forum is reserved for bug reporting and verification.

I'm trying to work on verification of the original bug report? Sorry if that was unclear.

[Baugi]

I tried pulling some data out of Velious/Luclin(no AA) logs to play with validation.

Please note: I have no way to disambiguate movement interrupts. I'm ignoring them for the moment, but presumably that makes this data overestimate interrupts in a potentially non-uniform way. Also, my statistics are rusty so probably don't trust them.

TL;DR - I wouldn't call the proposed function a great fit(potentially just noisy data?), but it does seem notably better than the supplied EQEmu code.

log source (https://github.com/tipa16384/harcourt_applets/tree/main/DSR)
event file (https://github.com/doxenfree/channel-parsing/blob/main/channeling_data_cleaned.csv)

https://raw.githubusercontent.com/doxenfree/channel-parsing/refs/heads/main/calibration_comparison_sm.png

summary -

--- Model A: Azxten Formula ---
Expected Successes: 634.42 (63.44%)
Brier Score: 0.2315
Total Error: 8.14%

--- Model A (Azxten) Calibration Table ---
Groups events by their predicted probability.
Pred Prob | Count | Actual % | Expected %
-----------------------------------------------
~ 0.00 | 3 | 0.00% | 2.03%
~ 0.10 | 10 | 30.00% | 13.46%
~ 0.20 | 22 | 22.73% | 22.31%
~ 0.30 | 33 | 36.36% | 31.61%
~ 0.40 | 128 | 28.12% | 39.57%
~ 0.50 | 142 | 43.66% | 48.13%
~ 0.60 | 53 | 69.81% | 58.28%
~ 0.70 | 294 | 59.52% | 69.43%
~ 0.80 | 154 | 64.94% | 78.30%
~ 0.90 | 161 | 76.40% | 88.88%

==================================================

--- Model B: EQEmu Formula ---
Expected Successes: 752.73 (75.27%)
Brier Score: 0.2718
Total Error: 19.97%

--- Model B (EQEmu) Calibration Table ---
Groups events by their predicted probability.
Pred Prob | Count | Actual % | Expected %
-----------------------------------------------
~ 0.50 | 14 | 7.14% | 53.13%
~ 0.60 | 181 | 33.70% | 57.79%
~ 0.70 | 30 | 56.67% | 72.77%
~ 0.80 | 775 | 61.16% | 79.85%

[Rygar]

Not sure what exactly I'm looking at, but compiling and graphing data based on log files is generating a healthy afternoon erection. Please continue

[Baugi]

Not sure what exactly I'm looking at, but compiling and graphing data based on log files is generating a healthy afternoon erection. Please continue

If the channeling code is correct, it should accurately predict actual channeling outcomes. That is, you plug in the variables (channel skill, player level, spell level diff) and it gives you the probability of a successful cast.

I walked through the log files I had to find all the relevant casts along with the relevant variables (event file). If you have a collection of casts, the expected number of successes is just the sum of the individual probabilities.

In the graph, for each model(ie azxten's code vs EQEmu code), I'm just calculating the probability of success for each cast according to the model and grouping them together based on their probability of success, then plotting the expected ratio of success in the group against the actual ratio of success for the group.

Ideally, a good predictor should follow the diagonal line because that represents the expected success ratio matching the actual success ratio. The azxten code more or less follows the slope which is a good sign that the variables and scaling are correct, but does bounce around a lot even given the sample size. Also, it consistently overpredicts the probability for groups with more events which makes it a bit worse than is obvious on the graph (possibly explained by the movement interrupt issue).

The EQemu code in contrast is just bad, you can see it curled up in the corner which means it consistently overpredicts and the scaling is likely wrong. The contrast is bad enough that it's not worth trying to compare them in a more sophisticated way. I did play a little with including the push interrupt term and assuming push increased linearly with number of hits, but the scaling wasn't any good.

If someone is bored, they could try fitting a better function with the event data and cross-validation. Better might be to test if the historical behavior matches up well with live behavior. If so, you could do much more controlled tests and get rid of the movement interrupt issue. I'm also under the impression that P99's interrupt code is different from the stock EQEmu code so it should really be compared as well, but to be honest I don't care to try and extrapolate out the behavior when the devs have access to the source.

My scripts are just in the repo btw if that's easier than reading the wall of text - scripts (https://github.com/doxenfree/channel-parsing/tree/main)