VladimirMangos

As i check code big packets must work correctly.I not sure border case with packet size = 0x7FFF +-1

Yes. Not use for 4.x.

Hmm, for 2.4.3 maybe also add reference where possible find DB/scripts. Something "Look UDB/ScriptDev2 forums for 2.4.3 DB/scripts." I not sure how clear write this: UDB forum have TBC_DB project subsection and SD2 include compatibility patch in own repo.

ServerPktHeader arg `size`is "* size is the length of the payload _plus_ the length of the opcode" So 2 is opcode size. Real size calculated in uint8 getHeaderLength() { // cmd = 2 bytes, size= 2||3bytes return 2+(isLargePacket()?3:2); } Packet size field store data+opcode size and as i look current code correctly check this... In any case if we must select by full packet size then need fix ServerPktHeader::isLargePacket instead suggested way But this can be proved only if will find packet when data+opcode <= 0x7FFF but full packet > 0x7FFF That very hard i think.

quality != 0 redundant in this case... Add in [10770] with this change. Thank you

Please, next time ask move thread (possible using my email link) instead creating multiply threads

Client not support in full rate levels > 80 so can not show some info for characters > 80, for example it not show experience bar. I sure in last case, but not check "purple Number when if i earn EXP". And clearly i am not interested go and check this.

You not have real xp gain or just not see show xp gain in client? If last, then this just client limitation and not related to core.

crash logs not help in this case. mover corrupted in different packet handler some time before crash affected handler called. So crash log not have any useful info for external viewer. In like case can be help only repeatable way reproduce crash.

You need data in DB for XP gain: `player_xp_for_level`

Last is special case, and base at it for like change just strange. Use < for class/subclass/invtype very strange way... We can add special way handling all-0-used query but without check same for non 0 query suggested changes low proved for adding.

In [10765]. Thank you Not see patch before recent random search.

Hmm, i not find better way for charges part, so applied original way code with some changes. In [10764]. Thank you

Just read _really_ error message.

In [10762] added alt. patch

It's not broken, in fact it not has been fixed, just absent proper sever side anti-cheating checks allow it work. But must be properly implemented now in [10762]

Look like not need after [10762]

For same reason i drop this part from commited version. KAPATEJIb (insider42) version added in [10762] with some rewrites. Also from added code excluded all related Fingers of Frost charges counting. It not look like correct way implement it. I not close thread for this reason. About charges: spell 74396 have already max_stack = 2 and main spell affect 44544 hacve in basepoints 2 values (match to other 262 auras that also have allowed charges (but its also have its set in procCharges. I not sure set charges for 74396 right way, and it triggering lot hacks and adding in code and DB. More correct possible cast 74396 at proc event hit 44544 and at max stack of 74396 remove both auras.

outdated, not need

in [10761]. Thank you

Anyy sd2 discussion must be at sd2 forum. Closed.

Somme points at suggested patch: 1) I agree that have some wrapper for int64+int32 bit field (or at least for field access) can be useful and link really connected field in single object. 2) BUT for me totally look wrong use bit pos: (a) this just create additional problems for devs because most often steps in work with masks/bitpos is recheck it in spell.dbc and most dbc viewers let easy visually compare hex/bit view. In fact same spell can have many bits set for different purposes, and mask store not spell info but for selection some spells list (often not ranks of same spell) 3) use enums for mask can be useful or maybe not. Currently we use comments for mask using line for referecne what spell we check in line. In comment mostly referecne _exactly_ spell name that can be easy copied to clipboard for later search by web or spell.dbc or code.. enum will not let do it easy, one more problem for devs.

In theory this possible do in same way but for this need implement muti-characters pdump generation but code will near to similar from existed. Other way: save guild/etc data with leader? But this will allow cloning guild banks in result if leader chnaged in time 2 pdump generations Also problem with duplicated guild names: in different character no way ask client for ask character rename guild.

In fact if Ambal map's patch will completed will not many diffs in continent/instance maps. No any reasons not allow any map have instance data. Ofc, for continent main problem that state common for all players. And ofc expected size of this data.

If some problem not reported before then not meaning that problem not exist. Core just start better check DB data and then detect in DB data more problems. As already say this is DB problem. As most at startup errors.