Leaderboard

It is indeed a client side issue, I've described it earlier, there: Anywho, lemme put it in detail this time: Well, there's a CRC skills check that happens on the client, the CRC is usually performed on the server and the client just merely verifies it and the issue lies in the following statement "sometimes the CRC is not being sent, to be more accurate on some types and/or specific skills", I haven't investigated which skills are exceptions for that, but, I've investigated the CRC check problem (in fact it is a garbage variable problem) and I'll describe it to you now. In a struct called stNetNotiSkillEffect (I guess the name should ring a bell), there's a variable called SSrcState, to be specific it's defined in NetProtocol.h Line 120, another issue lies here (There's no constructor that initializes any of these variables declared here), Let's trace where that struct is being used: In NetIF.cpp Line 60, you'll find that SC_CharacterAction (RPC function) is being called to notify the client with actions that are being performed, SC_CharacterAction is defined in PacketCmd_SC.cpp Line 692 (this is quite a big function/procedure, that's quite convenient since it's an RPC & usually they have to handle many different cases), if you scrolled down a bit, you'll find the only case (PacketCmd_SC.cpp L850) that handles/fills the sSrcState variable is enumACTION_SKILL_TAR (and it does that in a specific sub-branch), here PacketCmd_SC.cpp Line 914, Now with that said, if you scrolled down a bit you'll find a call to NetActorSkillEff with the SSkillInfo struct being passed as the second argument (PacketCmd_SC.cpp Line 975), umm I wonder what that function does... Let's follow. NetActorSkillEff is defined @ NetProtocol.cpp Line 937, wonderful where's the issue? Check this branch: NetProtocol.cpp from Line 1044 to Line 1066, alright, the issue lies here: if( SkillEff.SSrcEffect.GetCount()>0 || SkillEff.SSrcState.GetCount()>0 || (SkillEff.sSrcState & enumFSTATE_DIE) ) // This is it --> (SkillEff.sSrcState & enumFSTATE_DIE) The sSrcState variable is being and-ed (Well if there's such a word, however this refers to the bitwise AND op) with enumFSTATE_DIE which is declared in the Common lib @ CompCommand.h Line 162, so what's up with it? what's the issue here? I'll tell you in a second but I've to still show that this branch and if that "and operation" succeeds (which is the case and the culprit for the issue), there's a sub-branch @ NetProtocol.cpp from Line 1057 to Line 1060 which handles self-performed skills (I noticed that death is mostly happening on skills like berserk or buffs (self-performed buffs) "skills & not notes or other ways of buffing") there's a death that is being applied on the targeted character and if you follow, this is a client side only effect. The whole issue is that, sSrcState is not being explicitly initialized, by the time sSrcState is checked (and when the server doesn't send any value for it) there could be anything in that variable, it was never initialized and might trigger that death and might not, depending on whatever garbage value that's left there before C++ taking over it's memory.

This happens due to a CRC check failure, AFAIK that the variable wasn't initialized and for some skills the server doesn't send anything , when the client do the checks, you get whatever garbage value that was in memory and the client/server thinks u are malicious, I couldn't find how classes' variables behavior were in C++03 but what I'm sure of is that unless you initialize ur variable in modern C++, you get whatever was leftover in that memory.