skins.yml

This file works like usernames.yml, for skins. Entries are grouped into pools, and default is the one used by the keyword random.

An entry can be written two ways.

skins:
  default:
    # the skin of an existing player, looked up on Mojang
    steve_look: Notch
    # a value and signature pair from mineskin.org
    red:
      value: "ewogICJ0aW1lc3RhbXAiIDogMTYyMzIxOTY3MTM0MCwK..."
      signature: "rLhllNEYguQG0EDxuEkx9J6AO4uwu2wPD0Bz1PA7r4LLtfZoWZ3D..."

The value and signature strings are much longer than shown here. Copy them in full from mineskin.org, and keep both: an entry missing one of the two is skipped with a warning.

Use a username when the skin belongs to a real account, and a mineskin pair for a custom skin that no player wears.

The key of an entry works as a name. This picks the red skin every time instead of a random one:

zones:
  arene:
    disguise:
      skin: red

A value that matches neither a pool nor an entry key is treated as a player username and looked up on Mojang. So skin: Notch works without declaring anything.

For entries given as a username, SomaHider looks in three places, in order:

1. its own cache, filled by earlier lookups;
2. the player themselves, if they happen to be connected at that moment;
3. the Mojang API, on a background thread.

The server is never blocked waiting for Mojang. While a lookup is in flight, the player keeps whatever skin they already had, and the new one appears at the next refresh.

Pool usernames are looked up when the plugin loads and on every /sh reload, so they are normally cached well before your first zone starts.

SomaHider backs off rather than hammering the API, and logs each case once:

A username that does not exist is the common one, and it is almost always a typo in this file. Check the log after adding new entries.