Jump to content

twostars

Administrators
  • Content Count

    1746
  • Joined

  • Last visited

Everything posted by twostars

  1. twostars

    Assassin Skills Fail

    Closing as non-issue (also skill timings were tidied up since, so any stray skill fail should be improved).
  2. twostars

    stealth fail

    Is this still an issue?
  3. twostars

    Some curse (i'm guessing sweetkiss) deletes scrolls

    This was caused by the "Full Skill Gear" curse, aka the silence and fixed some time ago.
  4. twostars

    List of bugs 2017

    With a macro I can reproduce it, and it's happening because the client's trying to deal with 2 connections at once (one of which will be disconnected, but not before it screws with encryption). It's inevitably going to break things. I think this is one of these cases where the solution is simply "don't do that", because there's nothing really wrong here aside from the client not letting go of its previous connection, but that's a bug with the client -- not the server. I mean... I can try to look into fixing the client's behaviour there, but I really don't see the point. :|
  5. twostars

    List of bugs 2017

    Spent quite a while trying to reproduce this using the information provided, but no such luck. :/ I can't actually reproduce this either (on live). I have a fair idea why it might happen, but I can't really say whether or not it's worth fixing if I can't actually trigger it. I mean, is it something that happens commonly to people?
  6. It's already done, pending restart.
  7. twostars

    silverharpoon claiming something strong

    You guys even get patch notes for the upcoming patch (the "WIP" thread in the patch notes section). But yes, he's making stuff up.
  8. twostars

    List of bugs 2017

    ^ That issue's already been fixed for the next patch. Thanks. (also, maestro pots have always been broken like this... regular pots originally worked though)
  9. twostars

    Atross/Riots NP bugged

    Which classes are you? Is there a possibility you're ranging them?
  10. twostars

    List of bugs 2017

    Are you sure? Were they the same pots both times? I'm assuming maestro pots have never worked like this but regular pots were fine. Edit: Nope. I know why it's doing this, it's because of the stealth changes. Same deal with the maestro pots, only they weren't counted before I guess. The problem is the logic to break stealth on attack/movement is also interrupting the cast (that's why I never saw a follow-up from the client). This didn't happen before because this logic wasn't called for pots before, we exempted them. That's why before pots never broke stealth (but they do now). However, now that they break stealth, they also interrupt stealth casts. As does anything else that breaks stealth. Thinking about it, this logic doesn't need to be here at all. If stealth is meant to be interrupted by attacks, this will already happen with the existing interrupt logic (at the correct rate, be it 100% or not). Pots won't trip it from there. So I can remove this logic entirely and fix both issues. Yay!
  11. twostars

    List of bugs 2017

    The way it works is it pulls in the rankings the site uses and then goes over each of them seeing if they're online. It sets 5 commanders from the top 5 found in the list that are online. The rankings, however, are generated daily (meaning new clans aren't in it), and it was limited to the top 100, so any clans not in that top 100 were also not in it. So if no clan leaders in the top 100 ranked clans were online for the war, it wouldn't have anyone else to give commander to. That's why I rank all clans now, and update these at the 5min mark before assigning commanders. It means everyone's counted. As for the king, we do have that implemented as well.
  12. twostars

    List of bugs 2017

    I need to check this with USKO/SteamKO, because as far as I can tell this isn't our server doing this... it's the client itself. I'm not so sure this is exactly the case officially. What I know: The commanders are pulled from the same data as the website shows for clan rankings. Now, whether or not they update the rankings before every war, I don't know, but the server definitely reloads the table here. Honestly, this really only disputes one thing: "The 5 clan leaders with highest position in the overall server ranking (including clans that aren't in the website list) that are present at war should get commander status per nation." If they update the rankings/website before (or rather, 5min into every war), then that makes sense. But their website should update as well (although I don't pretend to know what goes on with their website). So I mean, we can update clan rankings at every war and that's probably all we need to do here? Everything else should be working the same. That's the way it's coded, at least. Not sure if I understood if any other part of that was actually broken. Edit 2: Alright. All clans should now be ranked, and rankings now get updated every war for war commanders to include current clans.
  13. twostars

    Help Me Please.

    Hey. Listen. http://forum.apexko.com/topic/4572-help-me/ It's still Navi gonna happen.
  14. twostars

    Help Me

    Looked into your case, and account sharing's forbidden for this reason. I won't be restoring these items, sorry. I suggest changing your password, enabling OTP, and not telling anyone your account details. Edit: There's no way for anyone to gain access to your account unless they know your details. Be safe with your details. We have never once had a case where a player's account was 'hacked' (i.e. by someone they didn't know). We've done all we can to ensure your account security. It's up to you to protect your own account with the tools provided, coupled with a sprinkling of common sense.
  15. twostars

    Help Me

    Can you provide any information whatsoever here? i.e. When this happened (approximately), what was taken (doesn't have to be everything, just something to give me an idea of what to look out for), etc.
  16. twostars

    FT: Remove Specters from Final Level

    Any specifics on how that works?
  17. twostars

    List of bugs 2017

    Honestly, I think it's fine as it is. You're thinking of it as if it's blinking, but the problem was that people start blinking after they load in. While they're still loading in, players (edit: I was wrong, this was never an issue) and monsters can see them(!), but they're not yet blinking (since they haven't yet loaded in) so they're attackable. Ouch. This just fills that gap and prevents people from being attacked while they're still loading. Ideally they wouldn't be shown at all until they've finished loading (or we start them blinking when we start loading in -- but that's unofficial), but I didn't want to break anything with this change (and I probably would have broken things fixing that up). Once they've loaded ingame, it's fair game to be able to hit them. Before then just seems unfair. I think our behaviour is pretty much the same as official now, unless officially you aren't visible until you load in (but I'm not sure about that, I think they show up still as well -- I'll check this. Possibly it's even inconsistent. edit: yeah, officially it's really inconsistent). EDIT: Ignore what I said about that. There was never any problem for player visibility, just monsters. And since that's now fixed, there's nothing here to be concerned about. So we're good on all fronts here. Players can't see (or attack) other players until they finish loading in (which is when they start blinking, if applicable). Monsters can't see/attack players until they finish loading in (and aren't blinking, once they have finished loading in). So... everything is fine now.
  18. twostars

    List of bugs 2017

    Yes, it's just RNG. Cancellations are difficult to test (since I can't see any bad behaviour in my testing), but I have a theory that the way we're working it now, we're potentially attempting to cancel old casts as well (which is silly). It's super unlikely, because it would mean the client has to do some weird things, but... presently, technically possible. So I've tweaked logic to prevent that potential scenario. Aside from that, it all looks fine. Perhaps we'll get lucky and it was doing that for whatever reason. If not, well... need to dive back into it. It really doesn't differ from official logic otherwise, as far as I can tell, so if there is a problem with rates it has to be doing something wacky like that, I think. Also fixed a few of the other things on the list while I was looking over that. All of these changes will be applied on the next restart.
  19. twostars

    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.
  20. twostars

    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...
  21. twostars

    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?
  22. twostars

    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.
  23. twostars

    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...
  24. twostars

    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.
  25. twostars

    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...
×