SetPlayerSkinColor

From Wiki G1R-MP G1 Remake Multiplayer
Jump to navigation Jump to search

setPlayerSkinColor

AVAILABLE FROM UPDATE 0.1.3
This function is available in G1R:MP 0.1.3 and later. The contract below includes the compatibility guarantees introduced in that update.

Sets an independent server-owned sRGB skin-color override for a player.

Syntax

bool setPlayerSkinColor(int playerId, int r, int g, int b)

Parameters

Name Type Required Description
playerId int yes The connected player identifier.
r int yes The red sRGB channel: a finite integer from 0 through 255 inclusive.
g int yes The green sRGB channel: a finite integer from 0 through 255 inclusive.
b int yes The blue sRGB channel: a finite integer from 0 through 255 inclusive.

Returns

Returns true when the server accepts the override; otherwise returns false, including an unavailable player or invalid channel value.

Examples

Apply a skin tint after authorizing the request:

-- The resource must authorize this change first.
if not setPlayerSkinColor(playerId, 180, 140, 110) then
    outputDebugString("Skin color was rejected.")
end

Notes

  • Available only in server-side resource scripts.
  • Alias: SetPlayerSkinColor.
  • Cosmetic state only: this does not change identity, equipped armor, inventory, HP or other progression statistics.
  • Fractions, NaN, infinity and values outside 0..255 are rejected, not clamped. RGB is sRGB, converted to linear material RGB by the native client; there is no alpha argument.
  • This preserves the tattoo override. Use resetPlayerSkinColor to restore native material defaults; setting white is still an enabled override, not a reset.
  • Only supported skin surfaces are tinted. Armor, clothing, eyes and hair are not skin targets. Final appearance depends on the underlying skin texture, supported material, lighting and visible body regions.
  • The server owns the reliable state and replays it on late join and relevance entry; the native client reapplies it after supported visual rebuilds. Acceptance is not confirmation that a client has already rendered the change.
  • Resources must implement their own authorization before allowing a player request to call a setter. There is no client mutation packet or arbitrary texture upload API.
  • See Player customization and Player tattoo catalog.