SetPlayerTattoo
Jump to navigation
Jump to search
setPlayerTattoo
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 a server-owned tattoo preset from the supported catalog, independently of skin color.
Syntax
bool setPlayerTattoo(int playerId, string presetKey)
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
playerId |
int |
yes | The connected player identifier. |
presetKey |
string |
yes | A case-insensitive key from getPlayerTattooNames. The key none explicitly removes tattoos; it does not reset the override.
|
Returns
Returns true when the server accepts the preset; returns false for an unavailable player, unknown key or rejected change.
Examples
Apply a catalog preset, explicitly remove it, or restore defaults:
-- The resource must authorize these changes first.
setPlayerTattoo(playerId, "novice1")
-- Explicitly no tattoo (enabled override):
setPlayerTattoo(playerId, "none")
-- Restore native defaults (disabled override):
resetPlayerTattoo(playerId)
Notes
- Available only in server-side resource scripts.
- Alias:
SetPlayerTattoo. - Cosmetic state only: this does not change identity, equipped armor, inventory, HP or other progression statistics.
- Only catalog keys are accepted. Arbitrary texture paths and unknown keys are rejected. Getters return canonical lowercase keys.
- The skin-color override is preserved.
noneis an enabled no-tattoo override; useresetPlayerTattoo, notdefault, to restore native defaults. - Presets contain only their verified head/torso/legs regions. Covered skin and unsupported cooked material permutations may not display a tattoo; catalog acceptance is not a guarantee that every body part or armor combination can show it.
- 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.