SetPlayerIdentity

setPlayerIdentity

IMPROVED FROM UPDATE 0.1.3

This function is available in earlier releases and has corrected or expanded behavior in G1R:MP 0.1.3 and later. The contract below describes the updated behavior.

Selects a named head/face identity while preserving the player's game body, equipped armor and independent cosmetic overrides.

Syntax

bool setPlayerIdentity(int playerId, string identityKey)

Parameters

Name	Type	Required	Description
playerId	int	yes	The connected player identifier.
identityKey	string	yes	A stable key returned by getPlayerIdentityNames.

Returns

Returns true when the server accepts the validated identity state; returns false for an unavailable player, invalid key or rejected change. Success is not confirmation that every client has finished rendering it.

Examples

Select Milten's head/face without equipping armor or changing the body:

if not setPlayerIdentity(playerId, "milten") then
    outputChatBox("The identity could not be applied.", playerId)
end

Notes

• Available only in server-side resource scripts.
• This existing API has improved behavior in 0.1.3; it was not introduced in that release. Use a key from getPlayerIdentityNames, including default to select the default identity.
• The client applies a head-only identity layer, including the selected face presentation and supported hair/beard geometry. The current game body and armor remain in place; this does not replace the full body with the named NPC's mesh, texture set, shape or authored skin tone.
• The identity layers are committed together in server state. Native asset loading and visual reconstruction are asynchronous, so a successful call does not promise an immediately complete image on every client.
• Equipped armor remains controlled independently by setPlayerArmor. This call does not equip or remove items, change HP/progression, or reset setPlayerSkinColor/setPlayerTattoo overrides.
• Test the identities, armor, exposed skin, materials and LODs used by your resource on local and remote clients; not every authored combination or material permutation is guaranteed to render identically.
• Reliable server-owned state is replayed on relevance entry and late join. Resources must perform their own authorization before exposing this setter to player requests.
• Accepted changes emit existing compatibility events for the layers that changed: onPlayerFaceChange and onPlayerBodyChange for the legacy face/body state, and onPlayerHeadChange for the head state. The legacy body event name does not mean this renderer replaces the player's full body.
• See Player customization, Player identity catalog and Player tattoo catalog for the independent appearance layers and supported catalogs.