Jump to content

twostars

Administrators
  • Content Count

    1640
  • Joined

  • Last visited

Everything posted by twostars

  1. 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...
  2. 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?
  3. 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.
  4. 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...
  5. 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.
  6. 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...
  7. twostars

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

    SkyKingBLANKA - A greatest LIAR of this server

    Items have been restored to mail. Please be more careful in future.
  9. twostars

    Stun rate going crazy again

    For the last time, we didn't change the rates. >.>
  10. As this is a common issue at present, we encourage you to report all players currently abusing events in this manner here in this thread so we can look into it. Thanks!
  11. twostars

    level rebirth / reincarnation problem

    You need to unequip the items you have equipped.
  12. It should work now. Sorry for the inconvenience!
  13. twostars

    List of bugs 2017

    What exactly happens here? Do you start not doing any damage to them? Can you not even target them or do they become unreachable or something?
  14. twostars

    List of bugs 2017

    Alright. That should be fixed then.
  15. twostars

    List of bugs 2017

    This is an oversight since the same logic was applied to the target. From what's been said, there shouldn't be any way you can directly remove another player's stealth except via an AoE. As this is focusing on a single target, and not AoE, this doesn't apply here, so I've removed this entirely. If you can think of any cases where that's still wrong, please let me know. As-is, that'll be implemented in the next restart.
  16. Can you take a screenshot of what you're seeing with the panel? The Power-Up Store is probably erroring for the same reason. Edit: Security should be a lot more relaxed. Let me know if you're still having issues.
  17. twostars

    List of bugs 2017

    Stun rates aren't the same as slows but they're similar. Simming these with 255 INT and 100res, it'll be about 5.5%. Can we have some feedback on the things that were addressed; these all good now? I modified the original post to group them.
  18. twostars

    List of bugs 2017

    Funnily enough, this skill is called "Confusion of Devabird", so I guess they considered it at some point but either got rid of it or didn't use it? I'll remove it.
  19. twostars

    List of bugs 2017

    That should read monster skills no longer cancel. Melee should still behave the same. The logic needs fixing up for monsters, so for the meantime we dropped it. Right, but INT isn't valued all that much anyway in the calc. Archers do have INT, it's just useless to you for anything else. The rates should be much the same as in the second example with 160 INT (as said, it isn't valued much). I'd switch the base stat to the player's primary stat, but when the calcs were in the client officially they always used INT. So trying to keep its behaviour as close to official as possible. The rates are capped there, so theoretically it could be scaling higher but considering all reports on the issue are that they're either proc'ing too much or there's no difference between players with high/low resistances (which there is: ~5% to ~33% is a huge difference, even if the gap should perhaps be higher), I'm a little hesitant to do so.
  20. twostars

    List of bugs 2017

    See post directly above yours.
  21. twostars

    List of bugs 2017

    Can you give me an example of a skill that behaves like this? I'm running simulations on various slows and the % doesn't seem to reflect what you're describing. For example: Ice Staff: Caster: Mage with 255 INT Target: 0 resist Rate: 22.2% (capped + staff chance is reduced) Caster: Mage with 255 INT Target: 10 resist Rate: 17.8% Caster: Mage with 255 INT Target: 30 resist Rate: 11.9% Caster: Mage with 255 INT Target: 50 resist Rate: 8.9% Caster: Mage with 255 INT Target: 70 resist Rate: 7.14% Caster: Mage with 255 INT Target: 100 resist Rate: 5.5% *** (with less INT, but it's really not worth that much) Caster: Mage with 160 INT Target: 0 resist Rate: 22.2% (capped + staff chance is reduced) Caster: Mage with 160 INT Target: 100 resist Rate: 5.1% *** Prismatic: Caster: Mage with 255 INT Target: 0 resist Rate: 33.3% (capped) Caster: Mage with 255 INT Target: 10 resist Rate: 26.2% Caster: Mage with 255 INT Target: 30 resist Rate: 17.5% Caster: Mage with 255 INT Target: 50 resist Rate: 13.1% Caster: Mage with 255 INT Target: 70 resist Rate: 10.48% Caster: Mage with 255 INT Target: 100 resist Rate: 8% As you can see, there's quite a gap between players with no/low resist to players with 100 resist. If you could give me anything more specific for me to sim which can help show this behaviour, that'd be appreciated.
  22. twostars

    List of bugs 2017

    Regarding not being able to be slept, what else should behave like this? I think we exempt pots for some reason, and it probably doesn't tell the difference. Potting should also break stealth though? What isn't meant to break stealth? The threat generated from this is so minor any attack will rip off it. I can change it but unless you have a specific scenario where it's counterproductive, I don't think this is illogical. Are we referring to soloing content here? Debuffing first then having more time to cast the first attacks since they completely ignore you otherwise? I guess what I'm asking is how is this harmful? It's only Juraid that causes this. I suspected Forgotten Temple would too, since it's also not meant to behave as it does, but apparently not. This is fixed for the next restart. The other one that should have a notice is the infiltration quest from [Tactical] Josiah/Grace in Luferson/EMC, but I wasn't sure what specifically triggered that when I did it myself officially. I'll add this one, since that one at least has an obvious trigger. Edit: This one's been added, pending restart. Why not FT? The main purpose of it is to have people require some involvement on that character before participating so you don't just run them on a fresh character and sabotage the event. Obviously it isn't perfect, and I have more planned for dealing with this (I want to refill in-progress instances, although FT is still a special case), but it should somewhat help. As far as rebirthing, that's a very good point. Rebirthed characters satisfy this "involvement" requirement, so there's no need to further enforce the 800 NP on them. I'll fix that. Edit: This is fixed, pending restart. So did I. I'll have to look more into this. Yeah, I'm pretty sure this is the one that had an exact rate of 50% officially. I'll look into that. Edit: We should already be enforcing this rate. I'll test it further, but at a glance it looks fine. Edit 2: Still looks okay, but I've made some tweaks which should hopefully guarantee this (pending restart). It's possible that precision on live is causing our checks to behave oddly, so changed things a little to avoid this. That's an interesting one, because the only way for this to be the case is if the skill was configured to have a DoT & skill configs are all from official data. I'll check it out. Edit: Okay, so what I've discovered is this. Checking this against official data, this data is correct/consistent, so I'm guessing it's just another one of those cases where the tooltip doesn't say exactly what things do. It'd be nice to have someone check this specifically on USKO/SteamKO, because if it *doesn't* have the DoT then they're not using the same data as in the client. That doesn't make a whole lot of sense though, because the client would then still show the DoT even though the server didn't apply it. So IDK.
  23. twostars

    Kurian's Devil Transformation

    That sounds odd indeed. The way it's supposed to work (at least, the way we've implemented it) is the full absorb amount is supposed to be equivalent to your max HP (at the time of transformation). It absorbs 30% of each hit until the absorb's depleted and then the transformation's removed.
  24. twostars

    MY ACCOUNT GOT HACKED !

    Nobody ever does, which is why we've always been against account sharing, and yet people still just think it's just a silly rule that doesn't apply to them. Yet here we are, another victim of account sharing by another trusted friend...
  25. twostars

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