Closed Hreesang closed 1 year ago
So it turns out that the problem is actually SA:MP being less consistent than us. In SA:MP you need an almost random assortment of AmxString:
and AmxStringBuffer:
depending on how the native accesses string data internally. In open.mp we use more "correct" methods, so only AmxString:
is ever needed, and using AmxStringBuffer:
will give the wrong result.
Apparently.
So it turns out that the problem is actually SA:MP being less consistent than us. In SA:MP you need an almost random assortment of
AmxString:
andAmxStringBuffer:
depending on how the native accesses string data internally. In open.mp we use more "correct" methods, so onlyAmxString:
is ever needed, and usingAmxStringBuffer:
will give the wrong result.Apparently.
So, you say that this problem should be dealt from the plugin side to adapt open.mp's more "correct" method?
No. The plugin isn't "wrong" per-se, it was written to accommodate two different ways of reading string in SA:MP natives, and when people adapt their natives to use PawnPlus strings they have to pick either AmxString:
or AmxStringBuffer:
based on the exact internal implementation of that native. But of course the open.mp exact internal implementations are different, so the essentially random choice of which one of those to use becomes different (and actually much simpler - just use one).
Description
In SA:MP server, everything works as intended. PawnPlus' string is shown as how it should be. However, in open.mp, everything turns into random symbols that I don't even know what symbols are those.
How to re-produce this behavior difference
Relevant log output
SA:MP Server
Client: Welcome, Hreesang.
Console: Welcome, Hreesang.
open.mp
Client: Ûã0
Console: [Info] Welcome,
open.mp server version
Build 10
Operating system or distribution
Windows 8.1 & Windows 10
Contact information
Hreesang#0614
Additional information