SetPlayerTattoo

From Wiki G1R-MP G1 Remake Multiplayer
Revision as of 02:32, 9 September 2026 by QCherry (talk | contribs) (Document skin color and tattoos available from 0.1.3; identity/armor improvements)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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. none is an enabled no-tattoo override; use resetPlayerTattoo, not default, 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.