Intel

Yep, effect_ambience_effect_*, added a param with ttl that would set a timer on how many ms before removing it. There's also another change that we did in event_process, that again, unlikely anyone would encounter it: LPEVENT the_event = pElem->pvData; if(pElem->bCancel) { cxx_q.Delete(pElem); // if we are processing deletion of the an event's q_el // we need to reset q_el as well. // This is needed because there might be multiple game's class holding the same // LPEVENT and they could try to event_cancel (which resets LPEVENT pointer to NULL) multiple times // since event_cancel resets only the caller's pointer if (the_event->q_el == pElem) { the_event->q_el = nullptr; } continue; } new_time = pElem->iKey;

Well, as you said, probably nothing was triggering this problem. Our changes to the effect manager made the game kaboom, evidently. Funny thing is now the class manages the timer and not the event queue. Oh well, lol What? No, it's the same ahah The changes in event_process and event_destroy are literally the same

Nah, it's correct. We detected this bug with asan, too

"when I go to test it within the game the ninja keeps it "the same"" What you mean by this? That the ninja's male attack speed is the same? Are you sure? (I was able to finally upload a gif, but as you can see, they attack at the same speed) Regarding the binary, I was referring to the change proposed by CORKI on __RunNextCombo (if you applied it, then the fix trough the msa most definitely breaks)

I can't and, it's not that hard. d:\ymir work\pc\assassin\bow\attack.msa ScriptType MotionData MotionFileName "d:/ymir work/pc/assassin/bow/attack.gr2" MotionDuration 1.500000 Group ComboInputData { PreInputTime 1.500000 DirectInputTime 1.500000 InputLimitTime 1.500000 LinkTime 0.000000 } Group AttackingData { AttackingType 1 HittingType 2 StiffenTime 0.000000 InvisibleTime 0.000000 ExternalForce 0.000000 AttackingStartTime 0.846154 AttackingEndTime 0.846154 AttackingBone "equip_left" WeaponLength 0.000000 List HitPosition { } } Group MotionEventData { MotionEventDataCount 1 Group Event00 { MotionEventType 6 StartingTime 0.850000 AttachingEnable 1 AttachingBoneName "equip_right" FlyFileName "d:/ymir work/pc/assassin/effect/arrow_01.msf" FlyPosition 0.000000 -30.000000 0.000000 } } d:\ymir work\pc2\assassin\bow\attack.msa ScriptType MotionData MotionFileName "d:/ymir work/pc2/assassin/bow/attack.gr2" MotionDuration 1.000000 Group ComboInputData { PreInputTime 1.500000 DirectInputTime 1.500000 InputLimitTime 1.500000 LinkTime 0.000000 } Group AttackingData { AttackingType 1 HittingType 2 StiffenTime 0.000000 InvisibleTime 0.000000 ExternalForce 0.000000 AttackingStartTime 0.846154 AttackingEndTime 0.846154 AttackingBone "equip_left" WeaponLength 0.000000 List HitPosition { } } Group MotionEventData { MotionEventDataCount 1 Group Event00 { MotionEventType 6 StartingTime 0.850000 AttachingEnable 1 AttachingBoneName "equip_right" FlyFileName "d:/ymir work/pc/assassin/effect/arrow_01.msf" FlyPosition 0.000000 -30.000000 0.000000 } } Unless you have a pack folder containing "d:\ymir work\pc|pc2\assassin\bow\attack.msa" overwriting the change, or you also applied the fix in the launcher, or you are still thinking about my original message ("Copy Group ComboInputData and Group AttackingData", wrong, also MotionEventData, the only difference is the MotionFileName), then trust me, it must work. TLDR: attack.msa from pc2 must be the same as attack.msa from pc, except MotionFileName.

Fixed: Broken: Video: [Hidden Content] [this thing never worked jesus christ: streamable /f500b6]

Yeah I realized the LoginData constructor thing. I wonder why the FindLogonAccount check wouldn't be sufficient, but honestly I've had enough to investigate the login flow lol Btw I guess at the end of the day, if I am not mistaken, it boils down to badly written systems that don't do the needed checks anyway (better safe than sorry though ahah)

These days I was trying to create a REST API for the auth, eliminating the need for the auth server and I got to fight with the login key (well, I am not using the old key but a JWT but the problem still stands since the whole flow is.. quite something I gotta say). During logout I set the deletion of LoginData but this would then reject the old expired JWT so I had to make some changes for the warp, like you did here. Problem is, I've had to do it for the change character as well because of the logout change. This is making me question then, for everyone using the original login, should this fix be applied in the changing character phase? Something like: case SCMD_PHASE_SELECT: { if (d) { d->SetCanUseLoginKey(true); } ch->Disconnect("timed_event - SCMD_PHASE_SELECT"); if (d) { d->SetPhase(PHASE_SELECT); } } break; Technically changing character should trigger DESC::Destroy where bCanUseLoginByKey would be false and selecting one would send again LOGIN_BY_KEY again. Am I tripping or what? Nvm the last part, my brain is completely fried. There's indeed bool bCanUseLoginByKey = true; and it's also initialized in CLoginData. This still makes me question if the problem was even for a character change (and your solution fixes it anyway btw). I am completely ignorant about whatever exploit is used with it, so I am just speculating.

In this case, there's a vector, it adds 25 first, then it adds 25 (the last value) + 25, so 50 Therefore we have vector{25,50} It calculates a random between 1 and 50, and then finds the position of the number that comes the closest in the vector (so, 1 to 25 position 0, 26 to 50 position 1: [Hidden Content]) That index (0 or 1 in this case), is then the index used in the vector that contains the list of the items that the monster drops: const SMobItemGroupInfo& GetOne() const { return m_vecItems[GetOneIndex()]; }

No, in Group Cursed_Wolf { Kill_drop 100 Mob 131 Type kill 1 5110 1 25 10 2 7160 1 25 10 } the 10 is the iRareDropPct, so the percentage that an item gets a bonus when dropped. 25 and 25 are the percentages to drop, but, considering the drop is of type kill, this drop is as it follows: 100 monsters (vnum 131) to kill to drop one of the items listed. The number 100 is influenced by the level difference between the monster and the player. The items listed are dropped with the same rules of the chests (you'll notice the GetOneIndex function is both in the CSpecialItemGroup class and CMobItemGroup). Both 5110 and 7160 got the same value, for two items total, so there's a 50% to drop one or the other. int GetOneIndex() const { int n = number(1, m_vecProbs.back()); auto it = lower_bound(m_vecProbs.begin(), m_vecProbs.end(), n); return std::distance(m_vecProbs.begin(), it); }

The 25 is the percent between the other items, it acts like the chests. In this case then, after 100 kills of the mob with vnum 131, there is a 50% to drop either 5110 or 7160, because they have the same "weight" (if for example you have three items with 25 5 and 5 pcts, the one with 25 it would have 66% chance to drop). You can drop only one of these items with this type of drop. Internally it goes: iPercent = iDeltaPercent(100) * 40000 / 100 = 40000 if (iPercent > rand(1, iRandRange)) { //drop } where iRandRange (default 4000000) is also influence by the level difference, so for example, using 1 would not always be a 100% drop.

dex difference between victim and attacker makes a huge difference (also called attack rating) float CalcAttackRating(LPCHARACTER pkAttacker, LPCHARACTER pkVictim, bool bIgnoreTargetRating) { int iARSrc; int iERSrc; { int attacker_dx = pkAttacker->GetPolymorphPoint(POINT_DX); int attacker_lv = pkAttacker->GetLevel(); int victim_dx = pkVictim->GetPolymorphPoint(POINT_DX); int victim_lv = pkAttacker->GetLevel(); iARSrc = MIN(90, (attacker_dx * 4 + attacker_lv * 2) / 6); iERSrc = MIN(90, (victim_dx * 4 + victim_lv * 2) / 6); } float fAR = ((float) iARSrc + 210.0f) / 300.0f; if (bIgnoreTargetRating) { return fAR; } float fER = ((float) (iERSrc * 2 + 5) / (iERSrc + 95)) * 3.0f / 10.0f; return fAR - fER; } used here // level must be ignored when multiply by fAR, so subtract it before calculation. iAtk = pkAttacker->GetPoint(POINT_ATT_GRADE) + iDam - (pkAttacker->GetLevel() * 2); iAtk = (int) (iAtk * fAR); iAtk += pkAttacker->GetLevel() * 2; // and add again

Which one? 99.99% this is a query error in the database (db's syserr.txt)

The function AddToCharacter never stacked items.. You need to use AutoGiveItem but we got a item pointer so we are back to square one (no stacking) So no, you can't, unless you create your own function that stack or give the item (and doesn't create ghost pointers all over the place)

or just fix it: int affect_add_collect(lua_State * L) { if(!lua_isnumber(L, 1) || !lua_isnumber(L, 2) || !lua_isnumber(L, 3)) { sys_err("add_collect wrong argument: int applyOn, int value, int duration"); return 0; } CQuestManager & q = CQuestManager::instance(); int applyOn = lua_tonumber(L, 1); LPCHARACTER ch = q.GetCurrentCharacterPtr(); if(applyOn >= MAX_APPLY_NUM || applyOn < 1) { sys_err("apply is out of range : %d", applyOn); return 0; } int value = lua_tonumber(L, 2); int duration = lua_tonumber(L, 3); auto affect = ch->FindAffect(AFFECT_COLLECT, aApplyInfo[applyOn].bPointType); if(affect != nullptr) { value += affect->lApplyValue; ch->RemoveAffect(affect); } ch->AddAffect(AFFECT_COLLECT, aApplyInfo[applyOn].bPointType, value, 0, duration, 0, false); return 0; }