mtwango

Same as https://github.com/Sphereserver/Source-X/issues/1451

Yeah dont use the patch, its causing it. Use noloks dev brach, which has fixed flags and parsing. The patch doesn't take in mind resources, which are high int64 ids,...

Isn't the `pCharSrc == this` check implemented at the beggining? Feels more like a workaround to the issue: not applying the memory instead of fixing, why the memory goes away.

Good thinking. So to sumarize: when you enter combat, you will get memory object linked to combatant or your existing memory will get flags. After combat, the memory gets removed,...

It was actually in 2 commits, https://github.com/Sphereserver/Source-X/commit/0467bfcae9dbccd9ba31c2182b1acc124783a722 and https://github.com/Sphereserver/Source-X/commit/17a1cb2d7d2b3b41cdf9f9675cf2384ec498af50 The line https://github.com/Sphereserver/Source-X/blob/707f304fbe60b8be6f0bda2928210f7241279f5e/src/common/CExpression.cpp#L676 causes the issue. But the whole parsing seems messy to me.

The issue here being is that some function returns uint64 value which is somewhere converted to int64 value and causes the problem. For example if you try: `serv.log testing hval:...

Yeah, I understand this is issue for some values, that need to be max 07fffffff. But for example flags on the characters are greater (mounted is 080000000). But the digits...

I don't see it broken anywhere, the packet is not sent on statf_change. Should be a separate issue

You can test the flags with modified parser here: https://github.com/mtwango/Source-X/tree/hexadecimal-parsing

Maybe instead of this try to swap `MoveTo(pt)` to `MoveToDecay(pt, GetDecayTime())`