OtherChoice

Is It possible to use a weakref to self not to unroll lambda expressions? for example like this from _weakref import ref for materialRow in self.materialSlots: j = 0 for material in materialRow: material.SetOverInItemEvent(lambda i= ref(self), trash = 0, rowIndex = row, col = j: i.__OverInMaterialSlot(trash, rowIndex, col)) Or would the garbage collector still find +1 references?

@enisina Maybe I didn't explain my thoughts correctly, sorry. What I meant is to add delete pkGrid; to the already existing method override . No excess code, it is already in your source.

Nice shot. For better code management and reusability you could remove the delete from the if (pkOldGrid) check and put it into the override method CGrid::CGrid(CGrid * pkGrid, int w, int h) : m_iWidth(w), m_iHeight(h) like this: CGrid::CGrid(int w, int h) : m_iWidth(w), m_iHeight(h) { m_pGrid = new char[m_iWidth * m_iHeight]; memset(m_pGrid, 0, sizeof(char) * m_iWidth * m_iHeight); } CGrid::CGrid(CGrid * pkGrid, int w, int h) : m_iWidth(w), m_iHeight(h) //<- if you add delete pkGrid here you can call M2_NEW CGrid(CGrid*, width, height) and it will delete the old pointer of safebox function at the end of this method { m_pGrid = new char[m_iWidth * m_iHeight]; int iSize = std::MIN(w * h, pkGrid->m_iWidth * pkGrid->m_iHeight); thecore_memcpy(m_pGrid, pkGrid->m_pGrid, sizeof(char) * iSize); //here delete pkGrid; }

@Gurgarath Hello, I'm trying to reproduce the bug but I'm working on a "worked-around" source, do you know how this work around was made? EDIT: After a bit of testing, as i was expecting is a client fix made on skilltable.txt. Your solution is also not a real fix, this skill as the majority of them checks on client side for hit collision. So the real problem is in client data inconsistencies in skill range set in skilltable.txt and hit data from skill yongpa(_2,_3,_4).msa. The following are the "actual hitting" ranges, while range in skilltable.txt is the range your character walks up to before casting the skill, so basically those two values have to match. Group Event03 { MotionEventType 4 StartingTime 1.193431 DuringTime 0.200000 EnableHitProcess 1 AttackType 0 HittingType 1 StiffenTime 0.000000 InvisibleTime 0.500000 ExternalForce 0.000000 HitLimitCount 5 CollisionType 4 SphereDataCount 1 Group SphereData00 { Radius 200.000000 Position 0.000000 -200.000000 150.000000 } } Group Event04 { MotionEventType 4 StartingTime 1.445256 DuringTime 0.200000 EnableHitProcess 1 AttackType 0 HittingType 1 StiffenTime 0.000000 InvisibleTime 0.500000 ExternalForce 0.000000 HitLimitCount 5 CollisionType 4 SphereDataCount 1 Group SphereData00 { Radius 200.000000 Position 0.000000 -600.000000 150.000000 } } those hitting spheres are positioned in front of the character at radius distance from you and from the first sphere covering a total distance of 4*radius so 800, I suggest to use this value lowered by a 50 for latency and moving victims, you can fiddle with this value and get the desired result, for skilltable.txt (and skill_proto as well, DB is not used but if you want to add a check serverside for skillrange hacks and such you'd better have consistent data). So with current .msa file settings the correct value for skilltable.txt is 750; hitsphere, however, is noticeably smaller than the dragon head range. Another good solution would be to increase sphere radius to 250 (for each of the 4 msa) and skilltable.txt value to 950. This solution has been tested and works with no double damage computation( @Heathcliff™) and with the default m_me->OnMove(true) function (no need to change source). If you want any further explaination about OnMove usage here do not esitate to ask.

Might be also a good idea to change data size for communicating structures like header of packets and sequence magic table (of course also change the table itself) currently unisgned char, more bits == more work for attacker. Those things will make packet forging attempts much harder. There are also packs which can be loaded, if client code gets rewrote wiser, after client-server first communication (majority of them, the ones you want to protect actually). Just combine those two factors (don't want to get too deep into it not to exploit it) and you will have a decent looking server packet decryption key system.

Lol, best asnwer is in this small line.

I'm not 100% sure but probably its managed on client source level with matrices of texture, depth stencyl, and such by Direct3d8

Hello everyone, today i'm on my second day trying to expand dynamic shadows view range, i found many limiters here and there for example SHADOW_APPLY_MAX_DISTANCE, bShadow_cutoff but none of those seem to be really affecting shadow range, Dynamic Shadows are rendered inside a square (not a circle so radius like constants mentioned above or distance between mainInstance and targetInstance are not involved) around the current playing character. Do you guys know if there's a cube or a square for dynamic shadows to be rendered on, and if so where is it defined? Hope you can help me I can't really figure it out. SOLVED: matLightProj was set to 2400.0f x 2400.0f x 1 x 15000.0f, changing the height and width of projection matrix will project more shadows UPDATE: larger projection will upscale shadow texture so it results in a shadow quality reduction, it can be partially bypassed by increasing m_wShadowMapSize but only up to a limit of 8192 set by Direct3d8.

Yeah it works smoothly

@HITRONIf you use two screen setup you can use, move, click, watch Netflx on the other screen still playing at fullscreen on the first one (if you played either guild wars2 or blackdesert online you should have seen those settings, and I'm sure there are lot more games using this) [Hidden Content]

The only variable in the formula is "k" which is the skillpower vaiable and ranges from 0.05 at level 1 to 1.25 at P. You have to ways of accomplish what you want, edit the formula to reach the cap you want at the current rate of change which implies intermediate values will follow the function. For example: or you can totaly remove the formula and manually enter the values from level 0 to 40 in a declared array accessible by the function short m_PartyAttackBonus[41] = { 1,2,3,4,5,/*YOUR 41 values here*/... }; and then change int Bonus = m_PartyAttackBous[ch->GetParty()->GetLeader()->GetSkillLevel(YOUR_LEADERSHIP_SKILL_VALUE)] it would be better if you add a check if the party leader exists( if (ch->GetParty()->GetLeader()) ), maybe it is not needed but you would want to test it before (having two chars in group with the leader logging off while the party member is attaccking monsters so he is constantly checking for those values)

You can also use windef macros and use way less CWindows and workarounds, I made my client borderless (full screen over the taskbar but not locked as top window like actual fullscreen) with this exact method. Those macros, in the right execution order are: SetWindowLongPtr, SetRect, AdjustWindowRectEx, MoveWindow, SetWindowPos. You can have a look at how they are used in PythonApplication.cpp bool CPythonApplication::Create(PyObject * poSelf, const char * c_szName, int width, int height, int Windowed) for game window, but they can be applied to any window handler.

run this query in player db and report the results: SELECT * FROM player.item WHERE id = 10019575; according to bt thats the ID of the item that crashes core when you try to remove it.

I can't see anything wrong neither in this function, so probably you should check your db item_proto entries as suggested (you can also have a sys_err("deleting %d", item->GetVnum()) at the beginning of your DestroyItem() function, after /ip or /ipurge command load your character, with your latest item_proto entries (most likely there's nothing wrong with vanilla items) and then disconnect, if you get a core again you can check which item caused it in your sys_err since it will be last line before crash).

The crash occured after a disconnect as you can see in the bt, the Disconnect() method and the ~CHARACTER destructor are called, for what i can see there's no problem with ClearItems() and DestroyItem(), post your CHARACTER::Destroy() method maybe there are more clues on what happened. It might be a double deletion of something since you get undefined behaviour if you try to delete an object through a pointer more that once. But the pointers in func args seem ok they don't look like bogus pointers. Or maybe @WeedHex is right and you got db incosistencies.