openmultiplayer / server-beta-old

open.mp server beta releases
142 stars 14 forks source link

[BEHAVIOR DIFFERENCE]: PawnPlus' AmxString and AmxStringBuffer #206

Closed Hreesang closed 1 year ago

Hreesang commented 2 years ago

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

native SendClientMessageStr(playerid, color, ConstAmxString:string) = SendClientMessage;
native GetPlayerNameStrImpl(playerid, AmxStringBuffer:name, len) = GetPlayerName;

stock String:GetPlayerNameStr(playerid)
{
    new String:str = str_new_buf(MAX_PLAYER_NAME);
    str_resize(str, GetPlayerNameStrImpl(playerid, str, MAX_PLAYER_NAME));
    return str;
}

public OnPlayerConnect(playerid)
{
    new String:str = str_format("Welcome, %S.", GetPlayerNameStr(playerid));
    SendClientMessageStr(playerid, -1, str);
    print_s(str);
    return 1;
}

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

image

Y-Less commented 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.

Hreesang commented 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, you say that this problem should be dealt from the plugin side to adapt open.mp's more "correct" method?

Y-Less commented 1 year ago

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).