identity/username/

identity/username/conflicts.yml содержит правила, которые решают, что делать, когда два аккаунта хотят один ник, а identity/username/messages.yml — то, что при этом видят игроки. Когда возникает конфликт и что делают правила по умолчанию, описано в разделе Ники и конфликты.

conflicts.ymlСкопировать ссылку на раздел

outcomes:
  rename-holder:
    pattern: "{username}_{provider}"
    tooLong: SHORTEN
    taken: NUMBER
    holderOnline: KEEP_PLAYING
  rename-arriving:
    pattern: "{username}_{provider}"
    tooLong: SHORTEN
    taken: NUMBER
  refuse: {}
providers: {}
rules:
  - arriving: { guarantees: [OWNED_USERNAME] }
    holder: { guarantees: [] }
    trigger: FIRST_JOIN
    outcome: rename-holder
  - arriving: { guarantees: [OWNED_USERNAME] }
    holder: { guarantees: [] }
    trigger: PROVIDER_RENAME
    outcome: rename-arriving
  - arriving: { guarantees: [] }
    outcome: refuse
  - outcome: refuse

Какое правило применяетсяСкопировать ссылку на раздел

Из правил, подходящих к конфликту, побеждает самое конкретное:

1. правило, называющее id провайдеров для большего числа сторон, сильнее правила, называющего их для меньшего;
2. затем правило, называющее гарантии для большего числа сторон, сильнее правила, называющего их для меньшего;
3. затем правило, которое дополнительно задаёт trigger или arrivedVia, сильнее правила без них.

Из одинаково конкретных правил побеждает первое в списке. Если два одинаково конкретных правила могут подойти к одному конфликту, но решают его по-разному, консоль предупреждает об этом при запуске и перезагрузке, потому что второе там никогда не применится. Если не подходит ни одно правило, входящему игроку отказывают.

rules[].arriving и rules[].holderСкопировать ссылку на раздел

Что правило требует от провайдера заходящего игрока и от провайдера держателя. Не указывайте сторону, чтобы принять любую.

outcome:
  id: rename-holder
  with:
    holderOnline: KICK_HOLDER

outcomes и providersСкопировать ссылку на раздел

Настройки исхода берутся из трёх мест, и каждое указывает только то, что меняет:

1. with правила — оно побеждает;
2. providers.<provider>.<outcome> — для провайдера аккаунта, который исход переименовывает: держателя для rename-holder, заходящего игрока для остальных;
3. outcomes.<outcome> — Identica записывает туда значения исхода по умолчанию.

providers:
  credential:
    rename-holder:
      pattern: "{username}_offline"

Ники без правилаСкопировать ссылку на раздел

Identica использует настройки rename-holder в двух случаях, которые не решает ни одно правило:

• Два аккаунта одного провайдера с OWNED_USERNAME хотят один ник, значит, ник держателя устарел: провайдер переименовал держателя, а тот с тех пор не заходил. Ник получает его нынешний владелец, а держатель — ник по настройкам rename-holder для своего провайдера. При следующем входе держателя новый ник от провайдера проходит через правила как PROVIDER_RENAME.
• На этом прокси под ником аккаунта ещё играет другой игрок, например держатель, которого переименовали, пока он был в сети, и который ещё не вышел. Тогда игрок в этой сессии играет под ником по настройкам rename-holder для своего провайдера.

messages.ymlСкопировать ссылку на раздел

Сообщения применяются во всех сценариях.

pipeline:
  policy:
    taken:
      - "<red>{username} is taken, please join with another name.</red>"
    holderReplaced:
      - "<yellow>The owner of {username} has joined. Join again to play as {renamed}.</yellow>"