Skip to content

Enforced Avatars

Some worlds need players to be a specific character — an RPG where everyone is a knight or a mage, a themed venue, a game where race or class matters. The Avatar Policy component lets your world force one avatar on everyone, or restrict players to a set you chose.

The one thing to know first

Your policy never changes a player's saved avatar. It's a per-visit override: while a player is in your world the server shows them the avatar your world requires, and the moment they leave, their own avatar comes back automatically. You're borrowing their appearance for the visit, not editing their account.

Add the component

Put an Avatar Policy on your world root — the same object as your World Descriptor (Add Component ▸ Social Scape/Avatar Policy).

It has one Mode:

Mode What players get
Off Players use their own avatar and can switch freely. (Same as not having the component.)
Force Everyone is shown the single Forced avatar you chose.
Restrict Players may only use an avatar from your Allowed avatars list. Anyone whose current avatar isn't in the list is put on the first one when they enter.

Referencing your avatars

You reference avatars by their GUID — the avatar_… id shown when you upload an avatar. The avatar is not bundled into your world; it's loaded on demand by id, the same way any avatar loads, and it's re-checked against the platform's avatar rules every time it loads.

  • Force mode: set Forced avatar to one GUID.
  • Restrict mode: add each allowed GUID to Allowed avatars.

By default you may only enforce avatars you own (or public ones). Referencing an avatar you don't own is rejected when you upload the world — so you find out at publish time, not from a broken world.

Where do I get the GUID?

Upload the avatar first (it's a normal avatar upload); its avatar_… id is shown on the upload result and in your content list. Paste that id here.

Advanced: allow public avatars by GUID

Allow public avatar by GUID is off by default. Leave it off unless you specifically need your world's scripts to put a public avatar on a player that isn't in the lists above — turning it on widens what your scripts can do.

Changing a player's avatar from script

Beyond the spawn-time policy, a server-driven script can assign avatars dynamically — e.g. hand out the knight or the mage when a player picks a class:

Player.SetAvatar(playerId, "avatar_1234…");   // force one of your policy's avatars on a player
Player.ClearAvatarOverride(playerId);          // give them their own avatar back
World.GetAllowedAvatars();                      // string[] of the avatars your policy permits

Player.SetAvatar is server-authoritative — call it from a server-driven script (an SSPlatform in Script drive mode) or a server trigger, and it only accepts an avatar your world's Avatar Policy permits. It's ignored on a normal client-side script, and rejected for any avatar the policy doesn't allow.

Driving the character (armor, gear, expressions)

Enforced avatars are authored by you, so they carry the animation parameters and toggles you designed — armour sets, gear, poses. Reveal them as the player progresses by setting those parameters from a script; the change shows to every other player automatically (no networking to wire — it rides the same channel as expressions and gestures):

Player.SetAvatarBool(playerId, "ChestArmor", true);     // toggle a piece of gear on
Player.SetAvatarFloat(playerId, "CloakBlend", 1.0f);    // blend a value

The parameter must be one your avatar's Avatar Descriptor declares as a synced expression parameter. These set the local player's avatar (each player's own script drives their own character), and it replicates to everyone. See Avatar animation for how to declare parameters.

What stays true no matter what

  • Your policy can't override the platform's avatar rules. A forced avatar is still size- and content-checked when it loads, exactly like any avatar.
  • A player's real avatar is never changed — only overridden for the visit, and restored on exit.
  • The server decides, so everyone sees the same thing — there's no way for one player to see a different avatar than the rest of the room.

Component class names (for scripts and search): SSAvatarPolicy.