Jump to content

twostars

Administrators
  • Content count

    1497
  • Joined

  • Last visited


Reputation Activity

  1. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    Since this "window logic" apparently applies to skills too, let's look at skills. It's essentially the same, but no awkward Action() call -- it's handled directly, so there's less to... interpret, I guess.
    So, let's look at type 3 stuff (generally mage skills) in particular, since it's the easiest to interpret (they're all handled the same way, just different triggers).
     
    The client source is really underwhelming for this, since it's lacking a lot, but the gist of it's here:

    void CMagicSkillMng::EffectingType3(DWORD dwMagicID) { __TABLE_UPC_SKILL_TYPE_3* pType3 = m_pTbl_Type_3->Lookup(dwMagicID); __ASSERT(pType3, "NULL type3 Pointer!!"); if(!pType3) return; StunMySelf(pType3); int key = 0; if(pType3->iStartDamage>0 || (pType3->iStartDamage==0 && pType3->iDuraDamage>0) ) key = DDTYPE_TYPE3_DUR_OUR; else key = DDTYPE_TYPE3_DUR_ENEMY; if(key==DDTYPE_TYPE3_DUR_ENEMY && pType3->iAttribute==3) StopCastingByRatio(); The important part that cancels our casts is StopCastingByRatio(). According to this, this applies for lightning based skills from enemies. 
    StopCastingByRatio() looks like this:

    void CMagicSkillMng::StopCastingByRatio() { m_pGameProcMain->CommandSitDown(false, false); // ÀÏÀ¸ÄÑ ¼¼¿î´Ù. if(IsCasting()) { __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); if(pSkill) { int SuccessValue = rand()%100; if(SuccessValue >= pSkill->iPercentSuccess) // ½ºÅ³ Å×ÀÌºí¿¡ ÀÖ´Â È®·ü´ë·Î ½ÇÆÐÇÑ´Ù.. { FailCast(pSkill); //if( s_pPlayer->Action(PSA_BASIC, false, NULL, true); // ij½ºÆà Ãë¼Ò, ±âº»µ¿ÀÛÀ¸·Î °­Á¦ ¼¼ÆÃ.. } } }So same deal as with regular attacks, but this calls FailCast() instead to immediately fail the cast. Simple. 
    For reference, FailCast() looks like this:

    void CMagicSkillMng::FailCast(__TABLE_UPC_SKILL* pSkill) { s_pPlayer->m_dwMagicID = 0xffffffff; s_pPlayer->m_fCastingTime = 0.0f; s_pPlayer->m_iSkillStep = 0; int16_t data[SkillDataFields] = {0}; data[3] = SKILLMAGIC_FAIL_CASTING; BuildAndSendSkillPacket(s_pPlayer->IDNumber(), s_pPlayer->IDNumber(), MAGIC_FAIL, pSkill->dwID, data); } All it does is resets the cast (immediately) and tells the server. 
    In 1.298:

    v4 = *(_DWORD *)(this + 36); v19 = a2; sub_58D550(&v21, &v19); result = *(_DWORD *)(v4 + 24); if ( v21 != result ) { v6 = v21 + 16; if ( v21 != -16 ) { CMagicSkillMng::StunMySelf((_DWORD *)v3, v6); v7 = *(_DWORD *)(v6 + 12); if ( v7 <= 0 && (v7 || *(_DWORD *)(v6 + 16) <= 0) ) { v8 = 200; if ( *(_DWORD *)(v6 + 24) == 3 ) // pType3->iAttribute == 3 CMagicSkillMng::StopCastingByRatio(v3); } else { v8 = 100; }There's no changes there, it's just merged in the lightning-type check into the existing check, instead of checking a second time. 

    void __thiscall CMagicSkillMng::StopCastingByRatio(int this) { int v1; // [email protected] int v2; // [email protected] int v3; // [email protected] int chance; // [email protected] signed int v5; // [email protected] int v6; // [email protected] int v7; // [email protected] __int16 v8; // [email protected] int v9; // [email protected] char v10; // [email protected] char v11; // [sp+Fh] [bp-31h]@0 int v12; // [sp+10h] [bp-30h]@4 int v13; // [sp+14h] [bp-2Ch]@4 int v14; // [sp+18h] [bp-28h]@9 int v15; // [sp+1Ch] [bp-24h]@9 int v16; // [sp+20h] [bp-20h]@9 char v17; // [sp+24h] [bp-1Ch]@9 int v18; // [sp+28h] [bp-18h]@9 int v19; // [sp+2Ch] [bp-14h]@9 int v20; // [sp+30h] [bp-10h]@9 int v21; // [sp+3Ch] [bp-4h]@9 v1 = this; sub_5D91F0(*(_DWORD **)(this + 24), 0, 0, 0); // CommandSitDown(false, false, false) if ( *(_DWORD *)(dword_818794 + 0x2FC) == 6 // These are the IsCasting() checks, just inlined because the compiler felt like it I guess. || *(_DWORD *)(dword_818794 + 0xB04) != -1 || *(_BYTE *)(dword_818794 + 0xAF4) == 1 ) { v2 = dword_818760; // __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); v12 = *(_DWORD *)(dword_818794 + 2820); sub_46D7E0(dword_818760 + 20, &v13, &v12); if ( v13 != *(_DWORD *)(v2 + 24) ) { v3 = v13 - 0xFFFFFFF0; if ( v13 != -0x10u ) // if (pSkill) { chance = rand() % 100; v5 = 100; if ( !*(_BYTE *)(dword_818794 + 0x470) ) // same check as in the previous example, to allow the specific transformations to have a rate of 100%. v5 = *(_DWORD *)(v3 + 0x88); if ( chance >= v5 ) { v18 = 0; // FailCast() is inlined here as well, so this is what FailCast() looks like. v17 = v11; v19 = 0; v20 = 0; v21 = 0; //4002 Casting failed sub_615080(4002, &v17); // show the fail message (client source doesn't do this) v6 = *(_DWORD *)(v1 + 24); sub_5D7250(&v17, -50373); *(_DWORD *)(dword_818794 + 2820) = -1; // s_pPlayer->m_dwMagicID = 0xffffffff; v14 = 0; *(_DWORD *)(dword_818794 + 2828) = 0; // not sure what this flag is v7 = *(_DWORD *)(dword_818794 + 1140); // prepare the packet to send v8 = *(_DWORD *)(dword_818794 + 1140); v9 = *(_DWORD *)v3; v15 = 0; v16 = 0; sub_583540(4, v9, v8, v7, &v14, -100, 0, 0); // send the packet v21 = -1; } } } } }So it's more or less the same, no window logic there either...
  2. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    Okay. Well, it is affected by resistances. It uses the same logic as stuns, with the addition of a reduction to rates for staff skills.  

    The DoTs themselves are doing this? Or is it the initial skill that applies the DoT? I'm assuming it's the latter?  

    Which skills *should* be cancelling then?  

    I've looked over all the logic involving cancellations in the client (that's where they're normally handled). Not gonna lie, I've never seen anything remotely like this. I think this is just a coincidental thing that's been assumed to be the case, to be honest...
  3. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    Does this happen anywhere in particular? The reason it still exists (despite being reported in beta) is because we've never been unable to reproduce it and it's never been clarified when asked. Even testing just now in the Moradon arena & CZ, it works just fine for me.
     
    Is there something in the mix like transformations? Is it in a specific area? I highly doubt it, but are you dead when you relog? (and respawn after relogging)
     
    Edit:
    Alright. As suspected, transformations can cause this. At least, when they're fixed (right now, they can't because they're broken, so the bug report *now* is rather confusing).
     
    Edit 2:
    This behaviour is the same officially. You cannot blink while transformed. It's impossible.
     
    So unless this occurs when not using a transformation...
  4. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    RNG. Each skill has an individual rate of cancellation. This is why it's harder to interrupt healers.
    int SuccessValue = rand()%100; if(SuccessValue >= pSkill->iPercentSuccess) // cancel the skill at a rate defined per the skill we're casting That's this. 
    I'm not sure what you mean by that. I know arrows can interrupt, as can lightning-based magic skills because there's logic there for it. 
    So with that in mind, going back to your original post:
    Taking away from the whole "at the right time" thing (unless we translate that mean "we got lucky with RNG"), it all makes complete sense with what I'm seeing. 
    The difference between here and other servers is purely that we shifted this logic to the server, since doing it on the client's end is very abusable ("hey, I can't ever be cancelled!").
    So with that in mind, we need to determine what actually is the problem here. Are we implementing it for things that shouldn't trip it, etc.
     
    Why priests in particular feel like they're getting cancelled more than they should be, and we've ruled out the window thing.
    So I'll look into that.
  5. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    Since this "window logic" apparently applies to skills too, let's look at skills. It's essentially the same, but no awkward Action() call -- it's handled directly, so there's less to... interpret, I guess.
    So, let's look at type 3 stuff (generally mage skills) in particular, since it's the easiest to interpret (they're all handled the same way, just different triggers).
     
    The client source is really underwhelming for this, since it's lacking a lot, but the gist of it's here:

    void CMagicSkillMng::EffectingType3(DWORD dwMagicID) { __TABLE_UPC_SKILL_TYPE_3* pType3 = m_pTbl_Type_3->Lookup(dwMagicID); __ASSERT(pType3, "NULL type3 Pointer!!"); if(!pType3) return; StunMySelf(pType3); int key = 0; if(pType3->iStartDamage>0 || (pType3->iStartDamage==0 && pType3->iDuraDamage>0) ) key = DDTYPE_TYPE3_DUR_OUR; else key = DDTYPE_TYPE3_DUR_ENEMY; if(key==DDTYPE_TYPE3_DUR_ENEMY && pType3->iAttribute==3) StopCastingByRatio(); The important part that cancels our casts is StopCastingByRatio(). According to this, this applies for lightning based skills from enemies. 
    StopCastingByRatio() looks like this:

    void CMagicSkillMng::StopCastingByRatio() { m_pGameProcMain->CommandSitDown(false, false); // ÀÏÀ¸ÄÑ ¼¼¿î´Ù. if(IsCasting()) { __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); if(pSkill) { int SuccessValue = rand()%100; if(SuccessValue >= pSkill->iPercentSuccess) // ½ºÅ³ Å×ÀÌºí¿¡ ÀÖ´Â È®·ü´ë·Î ½ÇÆÐÇÑ´Ù.. { FailCast(pSkill); //if( s_pPlayer->Action(PSA_BASIC, false, NULL, true); // ij½ºÆà Ãë¼Ò, ±âº»µ¿ÀÛÀ¸·Î °­Á¦ ¼¼ÆÃ.. } } }So same deal as with regular attacks, but this calls FailCast() instead to immediately fail the cast. Simple. 
    For reference, FailCast() looks like this:

    void CMagicSkillMng::FailCast(__TABLE_UPC_SKILL* pSkill) { s_pPlayer->m_dwMagicID = 0xffffffff; s_pPlayer->m_fCastingTime = 0.0f; s_pPlayer->m_iSkillStep = 0; int16_t data[SkillDataFields] = {0}; data[3] = SKILLMAGIC_FAIL_CASTING; BuildAndSendSkillPacket(s_pPlayer->IDNumber(), s_pPlayer->IDNumber(), MAGIC_FAIL, pSkill->dwID, data); } All it does is resets the cast (immediately) and tells the server. 
    In 1.298:

    v4 = *(_DWORD *)(this + 36); v19 = a2; sub_58D550(&v21, &v19); result = *(_DWORD *)(v4 + 24); if ( v21 != result ) { v6 = v21 + 16; if ( v21 != -16 ) { CMagicSkillMng::StunMySelf((_DWORD *)v3, v6); v7 = *(_DWORD *)(v6 + 12); if ( v7 <= 0 && (v7 || *(_DWORD *)(v6 + 16) <= 0) ) { v8 = 200; if ( *(_DWORD *)(v6 + 24) == 3 ) // pType3->iAttribute == 3 CMagicSkillMng::StopCastingByRatio(v3); } else { v8 = 100; }There's no changes there, it's just merged in the lightning-type check into the existing check, instead of checking a second time. 

    void __thiscall CMagicSkillMng::StopCastingByRatio(int this) { int v1; // [email protected] int v2; // [email protected] int v3; // [email protected] int chance; // [email protected] signed int v5; // [email protected] int v6; // [email protected] int v7; // [email protected] __int16 v8; // [email protected] int v9; // [email protected] char v10; // [email protected] char v11; // [sp+Fh] [bp-31h]@0 int v12; // [sp+10h] [bp-30h]@4 int v13; // [sp+14h] [bp-2Ch]@4 int v14; // [sp+18h] [bp-28h]@9 int v15; // [sp+1Ch] [bp-24h]@9 int v16; // [sp+20h] [bp-20h]@9 char v17; // [sp+24h] [bp-1Ch]@9 int v18; // [sp+28h] [bp-18h]@9 int v19; // [sp+2Ch] [bp-14h]@9 int v20; // [sp+30h] [bp-10h]@9 int v21; // [sp+3Ch] [bp-4h]@9 v1 = this; sub_5D91F0(*(_DWORD **)(this + 24), 0, 0, 0); // CommandSitDown(false, false, false) if ( *(_DWORD *)(dword_818794 + 0x2FC) == 6 // These are the IsCasting() checks, just inlined because the compiler felt like it I guess. || *(_DWORD *)(dword_818794 + 0xB04) != -1 || *(_BYTE *)(dword_818794 + 0xAF4) == 1 ) { v2 = dword_818760; // __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); v12 = *(_DWORD *)(dword_818794 + 2820); sub_46D7E0(dword_818760 + 20, &v13, &v12); if ( v13 != *(_DWORD *)(v2 + 24) ) { v3 = v13 - 0xFFFFFFF0; if ( v13 != -0x10u ) // if (pSkill) { chance = rand() % 100; v5 = 100; if ( !*(_BYTE *)(dword_818794 + 0x470) ) // same check as in the previous example, to allow the specific transformations to have a rate of 100%. v5 = *(_DWORD *)(v3 + 0x88); if ( chance >= v5 ) { v18 = 0; // FailCast() is inlined here as well, so this is what FailCast() looks like. v17 = v11; v19 = 0; v20 = 0; v21 = 0; //4002 Casting failed sub_615080(4002, &v17); // show the fail message (client source doesn't do this) v6 = *(_DWORD *)(v1 + 24); sub_5D7250(&v17, -50373); *(_DWORD *)(dword_818794 + 2820) = -1; // s_pPlayer->m_dwMagicID = 0xffffffff; v14 = 0; *(_DWORD *)(dword_818794 + 2828) = 0; // not sure what this flag is v7 = *(_DWORD *)(dword_818794 + 1140); // prepare the packet to send v8 = *(_DWORD *)(dword_818794 + 1140); v9 = *(_DWORD *)v3; v15 = 0; v16 = 0; sub_583540(4, v9, v8, v7, &v14, -100, 0, 0); // send the packet v21 = -1; } } } } }So it's more or less the same, no window logic there either...
  6. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    Look, I spent way more time than I should have trying to prove its existence. I'm not saying there's nothing wrong, but what I am saying is: this "window" logic doesn't appear to exist in any step of the process. I went through it, in the old client source, in 1.298 and in 2.128. I'm not just waving my arms around being all "I don't want to fix this, it doesn't exist" -- I spent my time trying to prove it exists to understand how it worked so we could make sure it worked the same here. I just happened to end up proving it didn't.
     
    You could at least attempt to prove its existence by demonstrating you can only successfully cancel during those windows? Or something?
  7. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    This "window" thing doesn't exist. If you're saying it applies to R attacks, I can tell you with absolute certainty that it doesn't exist.
     
    The client handles cancellation rates (or, did).
     
    In the client source (I know, not a great place to check because it's very dated and is lacking a lot -- but it'll help understand the next bit):

    if(bIAmTarget) // if we're the player being attacked { this->CommandSitDown(false, false); // force us to stand if we're not already if(m_pMagicSkillMng->IsCasting()) // if we're currently using the cast animation (which gets set the second we start casting something and lasts until the cast animation finishes) { __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); // lookup the skill we're casting if(pSkill) { int SuccessValue = rand()%100; if(SuccessValue >= pSkill->iPercentSuccess) // cancel the skill at a rate defined per the skill we're casting s_pPlayer->Action(PSA_BASIC, false, NULL, true); // reset the animation to what it would otherwise be (e.g. stand animation). cast will fail on the next tick because the state's reset. } } pTarget = s_pPlayer; } For reference, CMagicSkillMng::IsCasting() does this:
    bool CMagicSkillMng::IsCasting() { if(s_pPlayer->State() == PSA_SPELLMAGIC || // if we're currently in the cast animation s_pPlayer->m_dwMagicID != 0xffffffff || // if we have a skill ID set s_pPlayer->m_bStun == true) // also apply when they're stunned, so I guess this is why peoples' animations reset when stunned and interrupted return true; return false; } In 1.298:
    bool CMagicSkillMng::IsCasting() { return *(_DWORD *)(dword_818794 + 0x2FC) == 6 // s_pPlayer->State() == PSA_SPELLMAGIC || *(_DWORD *)(dword_818794 + 2820) != -1 // s_pPlayer->m_dwMagicID != 0xffffffff || *(_BYTE *)(dword_818794 + 0xAF4) == 1; // s_pPlayer->m_bStun == true }Attack logic in 1.298 (because it's slightly easier to read, but it's the same in 2.128):
    v12 = *(_DWORD *)(dword_818794 + 1140); v13 = v9 == v12; .. if ( v13 ) // if the player being attacked is us { sub_648EB0(4); v16 = v69; sub_5D91F0(v69, 0, 0, 0); // CommandSitDown(false, false, false); // force us to stand if we're not already v17 = v69[99]; if ( CMagicSkillMng::IsCasting() ) // if we're casting { // lookup the skill we're casting v18 = dword_818760; v67 = *(_DWORD *)(dword_818794 + 2820); sub_46D7E0(dword_818760 + 20, &v79, &v67); if ( v79 != *(_DWORD *)(v18 + 24) ) { v19 = v79 + 16; // logic is super obscure because internal lookup stuff, but if we're here it means the skill was found and we can proceed // if (pSkill) if ( v79 != -16 ) { v20 = rand() % 100; v21 = 100; // set default rate if ( !*(_BYTE *)(dword_818794 + 1136) ) // except for very few, very specific transformations (opening/closing ladders, kaul, mama magpie, "valentina"), use the skill's specified cancel rate v21 = *(_DWORD *)(v19 + 136); if ( v20 >= v21 ) { LOBYTE(v75) = v66; std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_Tidy(0); v88 = 0; sub_615080(4002, &v75); if ( v16[18] ) sub_52ACD0(&v75, 0xFFFF3B3B); (*(void (__stdcall **)(_DWORD, _DWORD, _DWORD, signed int, signed int))(*(_DWORD *)dword_818794 + 24))( // Action()... 0, 0, 0, 1, -1); v88 = -1; std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_Tidy(1);Logic there is the same. Only difference is:
    if ( !*(_BYTE *)(dword_818794 + 1136) ) // except for very few, very specific transformations (opening/closing ladders, kaul, mama magpie, "valentina"), use the skill's specified cancel rate v21 = *(_DWORD *)(v19 + 136); Where we're allowing for specific transformations that have a cancellation rate of 100% (apparently that's a thing, didn't realise until now). 
    Point being, the logic's the same. There's no "window" here. It applies from the moment the player starts casting their skill to the time the cast finishes (i.e. the cast animation).
     
    Just to prove that it also isn't a thing in 2.1xx:
     

    bool CMagicSkillMng::IsCasting() { return *(_DWORD *)(dword_DF0714 + 996) == 6 || *(_DWORD *)(dword_DF0714 + 3964) != -1 || *(_BYTE *)(dword_DF0714 + 3920) == 1; } // skipping into it a little because 2.1xx disassembly is a lot messier, but the above checks are the same if ( CMagicSkillMng::IsCasting() ) // same deal as before, if we're casting... { // lookup the skill we're casting v15 = sub_4EE700((char *)dword_DF060C, *(_DWORD *)(dword_DF0714 + 3964)); pSkill = v15; // if the skill exists if ( v15 ) { v3 = (int *)(rand() % 100); v15 = 100; // default the rate to 100% if ( !*(_BYTE *)(dword_DF0714 + 0x678) ) // if we're not using a specific transformation skill that overrides cancellation rate to 100%... specify the rate intead v15 = *(_DWORD *)(pSkill + 180); if ( (signed int)v3 >= v15 ) // time to cancel { v24 = *(_DWORD *)(s_pProcMain + 1268); if ( v24 ) // lookup genie ui { if ( dword_DF0714 ) // genie stuff --v { v25 = *(_DWORD *)(v24 + 844); if ( v25 ) { if ( *(_BYTE *)(dword_DF0714 + 1864) ) { switch ( *(_DWORD *)(dword_DF0714 + 1712) ) { case 103: case 109: case 110: case 203: case 209: case 210: *(_BYTE *)(v25 + 294) = 0; break; default: break; } } } } } // back to cancelling stuff... v81 = 15; v80 = 0; LOBYTE(v79) = 0; v89 = 0; sub_916270(4002, (int)&v78); // show the fail message v26 = *((_DWORD *)v68 + 113); if ( v26 ) sub_69A460(v26, (int)&v78, (int)&v78, 0xFFFF3B3B); // use Action() to override the animation. next tick will fail the cast since we're no longer casting. (*(void (__stdcall **)(_DWORD, _DWORD, _DWORD, signed int, signed int, signed int))(*(_DWORD *)dword_DF0714 + 24))( 0, 0, 0, 1, -1, -1); So that's R attacks. But you might say, but what if it for some reason succeeds with the cast anyway since R attacks wait until the next tick to fail casts, whereas if you're cancelling via a skill, it interrupts it immediately.So let's check that logic out:
     
    In the client source:

    void CMagicSkillMng::ProcessCasting() { //ij½ºÆà ó¸®.. if(s_pPlayer->m_dwMagicID != 0xffffffff) { __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); CPlayerBase* pTarget = m_pGameProcMain->CharacterGetByID(m_iTarget, true); if(pTarget) s_pPlayer->RotateTo(pTarget); // ÀÏ´Ü Å¸°ÙÀ» ÇâÇØ ¹æÇâÀ» µ¹¸°´Ù.. //ij½ºÆà ¼º°øÀûÀ¸·Î ¿Ï·á... float fCastingTime = ((float)pSkill->iCastTime) / 10.0f * s_pPlayer->m_fAttackDelta; if(pSkill) { bool bSuccess = false; if( s_pPlayer->m_fCastingTime >= fCastingTime && s_pPlayer->State()==PSA_SPELLMAGIC && s_pPlayer->StateMove()==PSM_STOP) { SuccessCast(pSkill, pTarget); bSuccess = true; } //ij½ºÆà ½ÇÆÐ... if(bSuccess == false && (s_pPlayer->State()!=PSA_SPELLMAGIC || s_pPlayer->StateMove()!=PSM_STOP)) { FailCast(pSkill); } } else s_pPlayer->m_dwMagicID = 0xffffffff; } } So, relevant logic is here:
    if( s_pPlayer->m_fCastingTime >= fCastingTime && s_pPlayer->State()==PSA_SPELLMAGIC && s_pPlayer->StateMove()==PSM_STOP) { SuccessCast(pSkill, pTarget); bSuccess = true; } //ij½ºÆà ½ÇÆÐ... if(bSuccess == false && (s_pPlayer->State()!=PSA_SPELLMAGIC || s_pPlayer->StateMove()!=PSM_STOP)) { FailCast(pSkill); } If we've finished our cast, and we're in a cast animation and the player's movement state is stopped, then the cast should succeed.It will fail here though, since their animation is no longer the cast animation -- thus "s_pPlayer->State()==PSA_SPELLMAGIC" will fail and so will the skill, in the next check.
     
    Let's see what this looks like in 2.1xx:

    v10 = 0.0; if ( sub_53E380(v6, (int)&v10) ) { result = CMagicSkillMng::SucceedCast((int)v2, v9, (int)v5, v7, v10); } else { result = dword_DF0714; if ( *(_DWORD *)(dword_DF0714 + 996) != 6 || *(_DWORD *)(dword_DF0714 + 1008) ) result = CMagicSkillMng::FailCast(v5); }So, they moved the check into a method:
    bool __thiscall sub_53E380(int this, int a2) { return *(_DWORD *)(this + 996) == 6 && !*(_DWORD *)(this + 1008) && sub_53CE10(this + 92, (float *)a2); }Which is essentially the same, reads something like:
    if (s_pPlayer->State()==PSA_SPELLMAGIC && s_pPlayer->StateMove()==PSM_STOP && CastTimeFinished())CastTimeFinished() is a little more complex than it used to be (a simple time check), but that's not important because s_pPlayer->State()==PSA_SPELLMAGIC is still false so it immediately fails because of that. 
    I think all that you've experienced is just RNG. I'm pretty sure that this "window" logic doesn't exist.
  8. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    Okay. Well, it is affected by resistances. It uses the same logic as stuns, with the addition of a reduction to rates for staff skills.  

    The DoTs themselves are doing this? Or is it the initial skill that applies the DoT? I'm assuming it's the latter?  

    Which skills *should* be cancelling then?  

    I've looked over all the logic involving cancellations in the client (that's where they're normally handled). Not gonna lie, I've never seen anything remotely like this. I think this is just a coincidental thing that's been assumed to be the case, to be honest...
  9. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    Are these things it's doing now and shouldn't? Or things it's not doing now and should? Your wording is confusing.
  10. Like
    twostars got a reaction from SkyHunter in List of bugs 2017   
    Does this happen anywhere in particular? The reason it still exists (despite being reported in beta) is because we've never been unable to reproduce it and it's never been clarified when asked. Even testing just now in the Moradon arena & CZ, it works just fine for me.
     
    Is there something in the mix like transformations? Is it in a specific area? I highly doubt it, but are you dead when you relog? (and respawn after relogging)
     
    Edit:
    Alright. As suspected, transformations can cause this. At least, when they're fixed (right now, they can't because they're broken, so the bug report *now* is rather confusing).
     
    Edit 2:
    This behaviour is the same officially. You cannot blink while transformed. It's impossible.
     
    So unless this occurs when not using a transformation...
  11. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    I'm sorry, but if you're not going to add any information to your "reports" then there's no reason for them to be there. "Fix priest" is useless to me.
  12. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    Look, I spent way more time than I should have trying to prove its existence. I'm not saying there's nothing wrong, but what I am saying is: this "window" logic doesn't appear to exist in any step of the process. I went through it, in the old client source, in 1.298 and in 2.128. I'm not just waving my arms around being all "I don't want to fix this, it doesn't exist" -- I spent my time trying to prove it exists to understand how it worked so we could make sure it worked the same here. I just happened to end up proving it didn't.
     
    You could at least attempt to prove its existence by demonstrating you can only successfully cancel during those windows? Or something?
  13. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    This "window" thing doesn't exist. If you're saying it applies to R attacks, I can tell you with absolute certainty that it doesn't exist.
     
    The client handles cancellation rates (or, did).
     
    In the client source (I know, not a great place to check because it's very dated and is lacking a lot -- but it'll help understand the next bit):

    if(bIAmTarget) // if we're the player being attacked { this->CommandSitDown(false, false); // force us to stand if we're not already if(m_pMagicSkillMng->IsCasting()) // if we're currently using the cast animation (which gets set the second we start casting something and lasts until the cast animation finishes) { __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); // lookup the skill we're casting if(pSkill) { int SuccessValue = rand()%100; if(SuccessValue >= pSkill->iPercentSuccess) // cancel the skill at a rate defined per the skill we're casting s_pPlayer->Action(PSA_BASIC, false, NULL, true); // reset the animation to what it would otherwise be (e.g. stand animation). cast will fail on the next tick because the state's reset. } } pTarget = s_pPlayer; } For reference, CMagicSkillMng::IsCasting() does this:
    bool CMagicSkillMng::IsCasting() { if(s_pPlayer->State() == PSA_SPELLMAGIC || // if we're currently in the cast animation s_pPlayer->m_dwMagicID != 0xffffffff || // if we have a skill ID set s_pPlayer->m_bStun == true) // also apply when they're stunned, so I guess this is why peoples' animations reset when stunned and interrupted return true; return false; } In 1.298:
    bool CMagicSkillMng::IsCasting() { return *(_DWORD *)(dword_818794 + 0x2FC) == 6 // s_pPlayer->State() == PSA_SPELLMAGIC || *(_DWORD *)(dword_818794 + 2820) != -1 // s_pPlayer->m_dwMagicID != 0xffffffff || *(_BYTE *)(dword_818794 + 0xAF4) == 1; // s_pPlayer->m_bStun == true }Attack logic in 1.298 (because it's slightly easier to read, but it's the same in 2.128):
    v12 = *(_DWORD *)(dword_818794 + 1140); v13 = v9 == v12; .. if ( v13 ) // if the player being attacked is us { sub_648EB0(4); v16 = v69; sub_5D91F0(v69, 0, 0, 0); // CommandSitDown(false, false, false); // force us to stand if we're not already v17 = v69[99]; if ( CMagicSkillMng::IsCasting() ) // if we're casting { // lookup the skill we're casting v18 = dword_818760; v67 = *(_DWORD *)(dword_818794 + 2820); sub_46D7E0(dword_818760 + 20, &v79, &v67); if ( v79 != *(_DWORD *)(v18 + 24) ) { v19 = v79 + 16; // logic is super obscure because internal lookup stuff, but if we're here it means the skill was found and we can proceed // if (pSkill) if ( v79 != -16 ) { v20 = rand() % 100; v21 = 100; // set default rate if ( !*(_BYTE *)(dword_818794 + 1136) ) // except for very few, very specific transformations (opening/closing ladders, kaul, mama magpie, "valentina"), use the skill's specified cancel rate v21 = *(_DWORD *)(v19 + 136); if ( v20 >= v21 ) { LOBYTE(v75) = v66; std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_Tidy(0); v88 = 0; sub_615080(4002, &v75); if ( v16[18] ) sub_52ACD0(&v75, 0xFFFF3B3B); (*(void (__stdcall **)(_DWORD, _DWORD, _DWORD, signed int, signed int))(*(_DWORD *)dword_818794 + 24))( // Action()... 0, 0, 0, 1, -1); v88 = -1; std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_Tidy(1);Logic there is the same. Only difference is:
    if ( !*(_BYTE *)(dword_818794 + 1136) ) // except for very few, very specific transformations (opening/closing ladders, kaul, mama magpie, "valentina"), use the skill's specified cancel rate v21 = *(_DWORD *)(v19 + 136); Where we're allowing for specific transformations that have a cancellation rate of 100% (apparently that's a thing, didn't realise until now). 
    Point being, the logic's the same. There's no "window" here. It applies from the moment the player starts casting their skill to the time the cast finishes (i.e. the cast animation).
     
    Just to prove that it also isn't a thing in 2.1xx:
     

    bool CMagicSkillMng::IsCasting() { return *(_DWORD *)(dword_DF0714 + 996) == 6 || *(_DWORD *)(dword_DF0714 + 3964) != -1 || *(_BYTE *)(dword_DF0714 + 3920) == 1; } // skipping into it a little because 2.1xx disassembly is a lot messier, but the above checks are the same if ( CMagicSkillMng::IsCasting() ) // same deal as before, if we're casting... { // lookup the skill we're casting v15 = sub_4EE700((char *)dword_DF060C, *(_DWORD *)(dword_DF0714 + 3964)); pSkill = v15; // if the skill exists if ( v15 ) { v3 = (int *)(rand() % 100); v15 = 100; // default the rate to 100% if ( !*(_BYTE *)(dword_DF0714 + 0x678) ) // if we're not using a specific transformation skill that overrides cancellation rate to 100%... specify the rate intead v15 = *(_DWORD *)(pSkill + 180); if ( (signed int)v3 >= v15 ) // time to cancel { v24 = *(_DWORD *)(s_pProcMain + 1268); if ( v24 ) // lookup genie ui { if ( dword_DF0714 ) // genie stuff --v { v25 = *(_DWORD *)(v24 + 844); if ( v25 ) { if ( *(_BYTE *)(dword_DF0714 + 1864) ) { switch ( *(_DWORD *)(dword_DF0714 + 1712) ) { case 103: case 109: case 110: case 203: case 209: case 210: *(_BYTE *)(v25 + 294) = 0; break; default: break; } } } } } // back to cancelling stuff... v81 = 15; v80 = 0; LOBYTE(v79) = 0; v89 = 0; sub_916270(4002, (int)&v78); // show the fail message v26 = *((_DWORD *)v68 + 113); if ( v26 ) sub_69A460(v26, (int)&v78, (int)&v78, 0xFFFF3B3B); // use Action() to override the animation. next tick will fail the cast since we're no longer casting. (*(void (__stdcall **)(_DWORD, _DWORD, _DWORD, signed int, signed int, signed int))(*(_DWORD *)dword_DF0714 + 24))( 0, 0, 0, 1, -1, -1); So that's R attacks. But you might say, but what if it for some reason succeeds with the cast anyway since R attacks wait until the next tick to fail casts, whereas if you're cancelling via a skill, it interrupts it immediately.So let's check that logic out:
     
    In the client source:

    void CMagicSkillMng::ProcessCasting() { //ij½ºÆà ó¸®.. if(s_pPlayer->m_dwMagicID != 0xffffffff) { __TABLE_UPC_SKILL* pSkill = s_pTbl_Skill->Lookup(s_pPlayer->m_dwMagicID); CPlayerBase* pTarget = m_pGameProcMain->CharacterGetByID(m_iTarget, true); if(pTarget) s_pPlayer->RotateTo(pTarget); // ÀÏ´Ü Å¸°ÙÀ» ÇâÇØ ¹æÇâÀ» µ¹¸°´Ù.. //ij½ºÆà ¼º°øÀûÀ¸·Î ¿Ï·á... float fCastingTime = ((float)pSkill->iCastTime) / 10.0f * s_pPlayer->m_fAttackDelta; if(pSkill) { bool bSuccess = false; if( s_pPlayer->m_fCastingTime >= fCastingTime && s_pPlayer->State()==PSA_SPELLMAGIC && s_pPlayer->StateMove()==PSM_STOP) { SuccessCast(pSkill, pTarget); bSuccess = true; } //ij½ºÆà ½ÇÆÐ... if(bSuccess == false && (s_pPlayer->State()!=PSA_SPELLMAGIC || s_pPlayer->StateMove()!=PSM_STOP)) { FailCast(pSkill); } } else s_pPlayer->m_dwMagicID = 0xffffffff; } } So, relevant logic is here:
    if( s_pPlayer->m_fCastingTime >= fCastingTime && s_pPlayer->State()==PSA_SPELLMAGIC && s_pPlayer->StateMove()==PSM_STOP) { SuccessCast(pSkill, pTarget); bSuccess = true; } //ij½ºÆà ½ÇÆÐ... if(bSuccess == false && (s_pPlayer->State()!=PSA_SPELLMAGIC || s_pPlayer->StateMove()!=PSM_STOP)) { FailCast(pSkill); } If we've finished our cast, and we're in a cast animation and the player's movement state is stopped, then the cast should succeed.It will fail here though, since their animation is no longer the cast animation -- thus "s_pPlayer->State()==PSA_SPELLMAGIC" will fail and so will the skill, in the next check.
     
    Let's see what this looks like in 2.1xx:

    v10 = 0.0; if ( sub_53E380(v6, (int)&v10) ) { result = CMagicSkillMng::SucceedCast((int)v2, v9, (int)v5, v7, v10); } else { result = dword_DF0714; if ( *(_DWORD *)(dword_DF0714 + 996) != 6 || *(_DWORD *)(dword_DF0714 + 1008) ) result = CMagicSkillMng::FailCast(v5); }So, they moved the check into a method:
    bool __thiscall sub_53E380(int this, int a2) { return *(_DWORD *)(this + 996) == 6 && !*(_DWORD *)(this + 1008) && sub_53CE10(this + 92, (float *)a2); }Which is essentially the same, reads something like:
    if (s_pPlayer->State()==PSA_SPELLMAGIC && s_pPlayer->StateMove()==PSM_STOP && CastTimeFinished())CastTimeFinished() is a little more complex than it used to be (a simple time check), but that's not important because s_pPlayer->State()==PSA_SPELLMAGIC is still false so it immediately fails because of that. 
    I think all that you've experienced is just RNG. I'm pretty sure that this "window" logic doesn't exist.
  14. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    Are these things it's doing now and shouldn't? Or things it's not doing now and should? Your wording is confusing.
  15. Like
    twostars got a reaction from Aziz in List of bugs 2017   
    I'm sorry, but if you're not going to add any information to your "reports" then there's no reason for them to be there. "Fix priest" is useless to me.
  16. Like
    twostars got a reaction from Drunken in My Power Up Store is not openning. Help me please.!!!!!!   
    It should work now. Sorry for the inconvenience!
  17. Like
    twostars got a reaction from Drunken in My Power Up Store is not openning. Help me please.!!!!!!   
    It should work now. Sorry for the inconvenience!
  18. Like
    twostars got a reaction from Smooth in Patch notes (07/04/2017)   
    Events
    Added a requirement of 800 National Points for signing up to events. Fixed a bug causing event signup UIs to break on zone change if you'd signed up. Event signup UIs should no longer desync from the server. Juraid Mountain
    You will now be prompted to sign up to Juraid Mountain from anywhere in-game, as with other events. This should allow more people to participate in the event. The signup NPC remains usable for signing up, and no longer always tells you it's the wrong time. Tweaked rewards: players will now additionally receive a Monster Stone Forgotten Temple
    Logging out during the event will now remove you from the event. Added strategically placed Specters to the event to help punish AFKers. Tweaked rewards: instead of an Apexis Chest, players will now receive a Krowaz chest and a Dragon's Scale Lunar Wars (invasions)
    Increased National Points given by monument blessings by 5x (so 1,000 NP for the first blessing, subsequent blessings give 500 NP). Added invasion quests (for both attacking and defending) which are accessible via the Karus Commanding Officer & Elmorad Commanding Officer NPCs which were added to the Karus & El Morad zones (more info on the quests below). Ultima now spawns at the end of an invasion. Boss events
    Removed Harpy Queens. Monster Stone
    The final boss Revenge Knight is now guaranteed to drop an old unique. Quests / NPCs
    [Grand Master] Kaishan has been cleaned out and the Nation Transfer process has been simplified. Added [Clan Manager] Adelia to Moradon, giving clan leaders the option to transfer their clan. This feature costs 800,000,000 coins and can only be used once every 48 hours. GMs will no longer transfer clans. Updated weapon rentals in Ronark Land to rent out Garges (+11) for 1 hour each day for an increased cost of 150,000,000 coins. This NPC is now [Weapon Rental] Soren. The Danger from Monsters quest from the [Ascetic] NPCs in Eslant now reward <selfname> (+8) weapons. The Danger from Monsters II quest from [Outpost Captain] in Ronark Land now rewards <selfname> (+8) weapons. All quests that reward EXP from [Outpost Captain] in Ronark Land were increased to reward 7.5% EXP (10% with premium). This should make it easier to rebirth without having to stop PKing. Added war invasion quests via the Karus Commanding Officer and Elmorad Commanding Officer NPCs in Karus and El Morad zones. Completed invasion quests reset every invasion, however if you haven't managed to finish your quest, progress will carry over.
    For defenders:
    Holding our Ground: defenders must kill 40 invaders. Reward: 2 x Krowaz Chest Defending Bellua / Asga: defenders must recapture the Bellua / Asga monument 2 times. Reward: 2 x Apexis Chest Defending Linate / Raiba: defenders must recapture the Linate / Raiba monument 2 times. Reward: 2 x Apexis Chest Defending Luferson / El Morad: defenders must recapture the Luferson / El Morad monument 3 times. Reward: 1 x Upgrade Scroll 100% to +6 The Ultima Defense: defenders must kill the invading Ultima. Reward: 1 x Ultima Chest For invaders: On the Offensive: invaders must kill 40 defenders. Reward: 2 x Red Potion Invading Bellua / Asga: invaders must overrun the Bellua / Asga monument 2 times. Reward: 2 x Apexis Chest Invading Linate / Raiba: invaders must overrun the Linate / Raiba monument 2 times. Reward: 2 x Apexis Chest Invading Luferson / El Morad: invaders must overrun the Luferson / El Morad monument 3 times. Reward: 1 x Upgrade Scroll 100% to +6 The Ultima Attack: invaders must kill the invading Ultima. Reward: 1 x Ultima Chest Implemented and otherwise fixed up [Analyst] Julius/Caesar's daily CZ quests: All quests are now available daily (as opposed to some quests only being available on certain days). Take the secret document of enemies is now implemented and rewards Oreads Voucher [1hr] To find the lost soul is now implemented (with its quest timer) and rewards DC Premium [1hr] Find the Spies is now implemented and rewards a Golden Mattock and 500 National+Ladder Points Disturbing the enemy base in Ronark Land is now implemented and rewards Menissiah's Official List (see below) + 500 National Points. As Disturbing the enemy base in Ronark Land requires the infiltration quest from [Tactical] Josiah/Grace in Luferson / El Morad Castle, this quest has also now been implemented. Drops / Monsters
    Felankor has been moved to the bowl in Ronark Land & its drops updated. As with Isiloon, there will now be a server-wide announcement when Felankor is about to spawn. Latenoid (Ultima) has had its drops updated. Its name was also changed back to Ultima. Felankor has had its drops updated. Evil Wizards, Booros, Balogs, and Doom Soldiers in Ronark Land have all had their drops updated to include Ron's Mage parts & Exceptional Hepa's (+6) pieces. Added Ultima Chest, which can drop various Krowaz pieces/weapons, shell armours, and more. These are obtainable from our invasion quests. Buffed Ultima's damage slightly (also made him bigger and scarier!). Monsters should no longer cancel casts. Mining
    Removed some useless (at this point) drops. Added Nest Scrap Added Scrap of Steel Added Monster Stones Miscellaneous
    All players old and new will receive a Newcomer's Package, which includes Cospre vouchers, a Wings of Hellfire voucher and a Name Change Scroll. The Name Change Scroll must be used within 24 hours. Players can no longer use scrolls or other persistent buffs with transformations (or vice versa). Fixed an issue with Clan Transfers; when players attempted to refuse the transfer, they found the responses were flipped in the "are you sure you want to leave the clan" confirmation. These have been flipped back for consistency. Additionally, we simplified the wording of the responses. Between these two changes, players should no longer feel like they were forced to transfer (or that it "bugged"). Freezing Distance can now only freeze a target if they're not already frozen, rather than extending the duration of the debuff. Implemented what we consider server rental items. These are now used by the [Weapon Rental] NPC (amongst other things), in place of regular expiration items. These items show you the time remaining on the item, realtime (as opposed to just the expiration time).
    Implemented support for quest timers (as used by the Finding the lost soul quest). Implemented support for the infiltration teleport scrolls (as used by the infiltration quest). Fixed a couple of bugs with the [Arrange Line] item which is used for changing your characters' positions on the selection screen. This should now always work correctly. Updated the [Gear Dispenser] in Moradon: Added Fire, Lightning & Glacier Hepa's Elixir Staff (+11) weapons (replacing the original Elixir Staff weapons that were sold) Added Elysium (+11) Added Hell Blood (+11) Added Garp (+11) Added Light Belt of Life (+1) Fixed a bug with rebirthing causing it to reset some quests / internal tracking that shouldn't be reset. Fixed a bug with monthly quests acting as if they were weekly quests. Added Menissiah's Official List item. This lets you search merchant stalls for items, as well as teleport to them directly & PM the vendors. You can purchase this from the Power-Up Store for 379 Apex Points, or obtain it via the Disturbing the enemy base in Ronark Land quest from [Analyst] Julius/Caesar in Ronark Land.
    Improved cheat detection for some types of hacks.
  19. Like
    twostars reacted to Razordagawd in Scrolls   
    These are 2 different bugs imo.
     
    One, when changing zones. Happens rarely (so far it has always happened to me after lunar war invasion, when tping to cz). A scroll disappears randomly and cannot be reapplied. Its effect is gone but the scroll is still lingering in the background, with its duration frozen (if you had it at 20 min before it disappeared when changing zones, after you relog / change zones again, it will return to you and still be at 20 minutes, even if you do it hours later). Since the scroll is still technically there after disappearing, it cannot be reapplied by using a replacement scroll of the same type.
     
    It might have something to do with the zones coding. It reminds me of having a TS on then proceeding to BDW. It works identically: the transform scroll disappears while in bdw, but it will be automatically reapplied after BDW ends, while maintaining its leftover duration.
     
     
    And the other bug, is when scrolls do disappear, and a relog or zone change won't bring them back. If you use a new one, it will work too. I cannot pinpoint what causes this. So far I've had it happen to dex scroll I think.
  20. Like
    twostars got a reaction from Razordagawd in Comeback4kill (or something)   
    02:50:00 [JM 297] [0] Players: ComeBacK4lKillYou MrNesh Elos Oooo00oooO OooooJLooooO Miyu SheBarracuda 02:50:00 [JM 297] [1] Players: IIIIIIIIII lFmycl AmericanShooter MyCashMoney Danger0uS HaLaskar SacredSouL
    Apparently it was ComeBacK4lKillYou, who's tied to lFmycl.
  21. Like
    twostars got a reaction from Razordagawd in Patch notes (22/03/2017)   
    Changelog
    Fix bug with some skills (Divide Armour, Iron Wall) breaking players holding the Pathos Fragment in Border Defense War. Player HP bars will now go grey as with official when the Aztec curse is active. The Aztec curse now correctly detects all potions, as with the Sweet Kiss curse. Nerfed Felankor's HP & defense by 30% to allow more clans to be able to kill it. Removed the stealth fade timer; stealth will now kick in immediately, as with official. Fixed a bug with Nation Transfers bugging signup queues & causing unbalanced instances. Players are now also automatically disconnected upon Nation / Class Transferring to avoid any other incidents involving players in bugged out states. Fixed a bug caused by appointing clan members that are offline as assistants. Fixed an exploit involving the Clan Nation Transfer feature. HP/Mana debuffs like Parasite/Superior parasite now work on monsters as well. Some fixes to character sealing: Cypher Rings can only be traded/merchanted to players of the same nation, to avoid being able to unseal characters of the opposite nation. Added some missed checks for Cypher Rings to merchanting (to buying & selling merchants) to avoid being able to possess 2 sealed characters at a time (and break the client). Nation Transferring while in possession of a sealed character will now also Nation Transfer the sealed character. Cypher Rings can no longer be mailed. Fixed several bugs with Cypher Rings bugging after being transferred to other players. Fire Rain curse no longer affects monsters. Fixed a bug inadvertently caused by the Smokescreen patch allowing AoE in arenas to harm the caster. Fixed a stability issue that could result in a server crash. Fixed some bugs caused by leaving alliances when a clan is performing a Nation Transfer. Fixed a discrepancy with how we divvy up XP/NP from monster/NPC kills (previously the pool would be out of everyone who contributed, as opposed to only those applicable for the reward.) Shovelled away the snow and cleared away all of the Christmas decorations. They've been around for too long Fixed a typo with the "Deadly Poisonous" title. You can update to 2.097 via the launcher or manually, here:
     
    http://download.apexko.com/upgrade/patch2097.zip
  22. Like
    twostars got a reaction from MrsD in Kurian bug in bdw   
    This has now been fixed for the next restart.
     

    This is a different issue, best to create a new thread for that one with as much info as you can provide. Thanks
  23. Like
    twostars got a reaction from MrsD in Kurian bug in bdw   
    Thanks, this helped. I still can't consistently reproduce it, however I have repro'd it once and sort've see why it's happening. 
    Should be able to fix that shortly.
     
    Edit:
    Okay. Can consistently reproduce it. That's actually really, really odd behaviour that I'm guessing officially mgame doesn't care about because it isn't as thorough with enforcing speedhacking as we are. That, and maybe they're blocking slows on these players?
    What seems to be happening here is interesting: something, related to these skills being used (haven't tracked it down yet to specifics) is entirely removing the slow from the client.
    The server still recognises them as having the buff (because why wouldn't they?), so when they're trying to move (at the regular non-slowed speed) they're getting yanked back to their position.
     
    So, the question is what's causing the client to silently drop the buff.
  24. Like
    twostars got a reaction from IIIAmJohnWick in Patch notes (21/02/2017)   
    Changelog
    Fixed a bug with the Bifrost draw timer causing it to effectively not be a thing. Bifrost should now behave correctly in this regard now. Kurian "Pull" skill no longer affects NPCs/artifacts, as this tended to cause things to break. It still works on monsters (which is unofficial behaviour, but intended here). Mage guard summons are now stationary. Fixed a bug with teleport skills (including things like Kurian's Pull/Dash skills) causing them to not respect certain logic and bug out the affected player/monster. Update: Fixed an issue that arose from this which broke some teleports. Projectiles should no longer affect players that have teleported / /town'd / died (they will still follow, but will no longer do any damage). Maestro potions are now included as potions by the Diet curse. Fixed a bug with transformations via curses; they should now be reverted correctly. Players affected by skills (e.g. debuffs) that teleport away at roughly the same time as the cast will now still be visibly affected by it. CSW crystal healing has been nerfed to 20% of the effective healing. Loot range has been increased for ranged classes that were previously on the outskirts and have their loot "stolen" by someone who is still in range. Ranged attacks no longer trigger lightning/fire/ice armour buffs. No longer credit the caster of the undead curse for the kill; as per official, these are now considered suicides. Fixed a potential cause for players to get 'stuck' in-game. Please remember to report any issue you experience with the patch. Thankyou
  25. Like
    twostars got a reaction from Sierra in Patch notes (23/02/2017)   
    Changelog
    Potions no longer break stealth. Fixed a bug with some projectile skills breaking (e.g. Styx) as of the last patch. Projectiles no longer care about whether the player teleported, only if they died or are no longer in range. Smokescreen now works as it does officially: it now also blinds friendly targets (including yourself), but unlike official, only in attackable areas (e.g. arenas, PVP zones). Kurian "Pull" skill no longer temporarily visually bugs out monsters (as caused by the last patch).
×