sampev color text

[user1241]

Версия MoonLoader

.026-beta

function sampev.onServerMessage(color, text)
    if text:find("Nick_Name") then
        sampAddChatMessage(":u1f53b: "..text, color)
    end
end

почему оно не выводит оригинальный цвет, а изменяет его? на тей же гейзоне, где /me - розовый, а здесь голубой.

 

[moreveal]

sampAddChatMessage принимает color в RGB (3 байта), серверный color приходит в RGBA (рудиментарный альфа-канал)
мунлоадер (а вернее сама игра в которую тот прокидывает вызов), ожидая что ты передал туда 3 байта, где каждый из которых отдельный цветовой канал, достает по байтику с конца числа:

r = (color >> 16) & 0xFF;
g = (color >> 8)  & 0xFF;
b = color & 0xFF;

иными словами, доверяет тебе и предполагает что ты не долбоеб, а передал нормальные 3 байта, которые он побитовыми операциями извлекает по порядку, но если ты не оправдал его доверие, эта цепочка приведет его к тому что серверный розовый 0xC2A2DAFF (R=C2,G=A2,B=DA,A=FF) будет принят за непонятный голубой, т.е. C2A2DA станет A2DAFF(R=A2,G=DA,B=FF), первый байт отсечется

Спойлер: наглядно

но мы то умнее тупого sampAddChatMessage, поэтому заранее преобразуем число в то что ему понятно:

local bit = require('bit')

function sampev.onServerMessage(color, text)
    sampAddChatMessage(text, bit.rshift(color, 8))
end

- это сдвинет число на байт вправо, отсечя тем самым ненужный A

p.s. ответ выше говно костыль и тд, не уверен, что tohex() гарантирует ведущие нули, и скорее всего получится срань для цветов < 0x100000
а сама функция не принимает никакой hex, это форма записи числа, ей похуй сожрать 0xFF0000 или 16711680