Whitelist и собеседования на RP-сервере

MAATRIX GAMES

Открыли сервер без входного барьера — и через неделю по улицам бегают картонные герои, которые матерятся в открытом чате и таранят полицию просто потому, что скучно. Знакомая история почти для любого свежего RP-проекта на FiveM: без фильтра на входе комьюнити формируется само, и формируется оно как попало. Whitelist — это не понт и не способ казаться элитным сервером, а рабочий инструмент отсева людей, которые физически не готовы играть роль, а не просто заходят «пострелять в GTA».

Зачем вообще нужен whitelist на RP-сервере

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

Во-первых, отсеивает тех, кто не читал правила — а значит, будет нарушать RDM (random deathmatch, убийство без ролевого повода) и VDM (то же самое на машине), просто не зная, что это запрещено. Во-вторых, поднимает порог входа: случайный игрок, зашедший от скуки на 10 минут, отваливается ещё на этапе анкеты, и в мире остаются в основном те, кто настроен играть всерьёз. В-третьих, создаёт ощущение закрытого клуба — прошедшие отбор ценят место больше и меньше склонны токсичить, потому что доступ можно потерять.

Обратная сторона тоже есть. Whitelist — это постоянная административная нагрузка: кто-то должен читать анкеты, проводить собеседования, вести базу отказов. На старте проекта, пока онлайна почти нет, жёсткий барьер может убить рост — люди не станут ждать неделю ради сервера с пустыми улицами. Многие проекты открываются с лёгким фильтром (капча + короткая анкета), а полноценное собеседование вводят уже после того, как набралось живое ядро игроков и есть что защищать. Если только выбираете, на чём строить RP-проект, вопрос платформы стоит закрыть раньше — сравнение вариантов есть в статье SA-MP, FiveM или RAGE:MP.

Форма заявки: что спрашивать и где её размещать

Анкета в Discord-боте работает лучше отдельной формы на сайте — игроки и так сидят в Discord вашего сервера и не хотят никуда переходить. Если базовый бот ещё не поднят, сначала разберитесь с ним — это отдельная тема, разобранная в статье про Discord-бота для управления игровым сервером: токен, discord.js или discord.py, автозапуск через pm2 или systemd.

Для анкеты чаще всего используют slash-команду с модальным окном (ModalBuilder в discord.js) или связку с Google Forms / Tally, встроенным через ссылку в описании канала. Модалка внутри Discord удобнее — заявка приходит прямо в приватный канал модерации без внешних сервисов, но лимит discord.js на модалку — 5 полей, так что анкету приходится ужимать.

Что реально стоит спрашивать (и не больше — длинная анкета отпугивает даже мотивированных):

• Возраст и часовой пояс — для расписания эвентов и понимания активности в прайм-тайм.
• Опыт RP — на каких проектах играл, в какой роли (гражданский, фракция, лидер банды), сколько по времени.
• Мини-сценарий на отыгрыш — например: «Ваш персонаж видит, как на улице грабят прохожего. Опишите от первого лица реакцию за 3-5 предложений». Единственный пункт, который реально показывает разницу между собой и персонажем в голове кандидата.
• Знание базовых терминов — метагейминг (использование информации, которую персонаж не мог знать) и павергейминг (навязывание результата действия без шанса на отыгрыш других). Открытый вопрос своими словами, не тест с вариантами.
• Discord-аккаунт и статический ID персонажа, если это часть онбординга и завязано на выдачу роли.

Заявки удобно собирать в канал #whitelist-заявки с правами только на отправку, а модераторам давать доступ к отдельному каналу-логу, куда бот дублирует каждую заявку с реакциями ✅/❌.

Критерии отбора: как отличить рабочую анкету от отписки

Главный маркер вымышленной вовлечённости — односложные ответы («норм», «играл где-то», «понимаю все правила»). Живая анкета почти всегда содержит детали: названия фракций с прошлых серверов, причину ухода оттуда и — самое ценное — вопросы по вашим правилам. Тот, кто дочитал регламент до конца, обычно находит в нём что-то неочевидное.

Отдельно смотрите на мини-сценарий отыгрыша. Плохой ответ выглядит как экшен-сцена от третьего лица («он достаёт пистолет и стреляет»), хороший — описывает реакцию и эмоцию персонажа, без нарушения логики (обычный гражданский не реагирует на грабёж как спецназовец). Скопированный с другого сервера сценарий обычно видно по чужой терминологии или названиям фракций, которых у вас нет.

Полезно завести таблицу решений, чтобы модераторы принимали заявки единообразно, а не на глазок:

Автопринятие без собеседования имеет смысл держать только для явно сильных анкет — это экономит время модераторов, но не должно становиться нормой, иначе собеседование как фильтр теряет смысл.

Голосовое собеседование: сценарий и на что смотреть

Текстовая анкета отсеивает откровенных рандомов, но не проверяет главное — умеет ли человек держать роль в реальном времени, с живой реакцией, а не заготовленным текстом. Для этого нужен голосовой созвон на 10-15 минут в отдельном приватном канале Discord.

Рабочая структура собеседования:

1. Разогрев вне роли (2-3 минуты) — почему выбрал именно ваш сервер, что читал в правилах. Задача — снять напряжение и понять, насколько человек внятно говорит и слышит вопросы.
2. Проверка правил через кейсы, а не пересказ — не «расскажи правила», а конкретная ситуация: «Тебя избили и забрали телефон в игре. Ты вышел и написал обидчику в личку в реальном Discord с угрозами — это нарушение?» (да, метагейминг и токсичность вне игры). Такое нельзя вызубрить заранее по FAQ.
3. Мини-отыгрыш голосом (3-5 минут) — короткая сценка: собеседующий играет полицейского или NPC, кандидат — своего персонажа (остановили на дороге, спрашивают документы). Смотрите на паузы, импровизацию без выхода из роли, дикцию и качество микрофона — если не слышно из-за шумов, это тоже повод для доработки перед принятием.
4. Вопросы от кандидата — минута на встречные вопросы часто показывает реальную заинтересованность в проекте.

Держите чек-лист с оценками по 3-5 пунктам (знание правил, качество отыгрыша, связь, адекватность в общении) и фиксируйте решение сразу после звонка — через час детали стираются.

Автоматизация: Discord-роли и проверка на стороне QBCore

Ручная выдача доступа после каждого собеседования — узкое место, которое снимается автоматизацией на стыке Discord-бота и игрового сервера: бот выдаёт роль Whitelisted после решения модератора, а сервер FiveM проверяет её при подключении игрока.

Проверка делается прямо в Lua-ресурсе сервера. Идентификатор Discord у игрока получаем нативной функцией:

local discordId = GetPlayerIdentifierByType(source, 'discord')
if discordId then
    discordId = discordId:gsub('discord:', '')
end

Дальше сервер дёргает Discord API от имени бота (нужен bot token с правом читать участников гильдии) и проверяет, есть ли у пользователя нужная роль:

local GUILD_ID = 'ваш_id_гильдии'
local ROLE_ID = 'id_роли_Whitelisted'
local BOT_TOKEN = 'токен_бота'

AddEventHandler('playerConnecting', function(name, setKickReason, deferrals)
    local src = source
    deferrals.defer()
    local discordId = GetPlayerIdentifierByType(src, 'discord')
    if not discordId then
        deferrals.done('Привяжите Discord-аккаунт к FiveM и зайдите заново.')
        return
    end
    discordId = discordId:gsub('discord:', '')
    deferrals.update('Проверяем whitelist в Discord...')

    PerformHttpRequest('https://discord.com/api/v10/guilds/'..GUILD_ID..'/members/'..discordId,
        function(status, body)
            local hasRole = false
            if status == 200 and body then
                local member = json.decode(body)
                for _, role in ipairs(member.roles or {}) do
                    if role == ROLE_ID then hasRole = true end
                end
            end
            if hasRole then
                deferrals.done()
            else
                deferrals.done('Whitelist не пройден. Подайте заявку на нашем Discord-сервере.')
            end
        end, 'GET', '', { ['Authorization'] = 'Bot '..BOT_TOKEN })
end)

Код кладётся в ресурс наподобие whitelist_check, который включается через ensure whitelist_check в server.cfg, после ensure discord_perms или аналогичного, если такой уже используется. Как раскладывать по папкам собственные ресурсы и подключать их без конфликтов, разобрано в статье про установку кастомных скриптов на FiveM.

Если у вас QBCore, логичнее хранить факт прохождения whitelist не только в Discord-роли, но и в базе (таблица players через oxmysql) — чтобы не зависеть от доступности Discord API при каждом коннекте и не терять статус, если игрока случайно выкинуло из роли модератором. Схема: после успешной проверки сервер один раз пишет whitelisted = 1 по license-идентификатору, а при следующих заходах сначала смотрит в базу и только при отсутствии записи обращается к Discord. Разницу между QBCore и ESX в подходе к таким кастомным проверкам смотрите в статье ESX и QBCore: сравнение фреймворков.

Отдельно: у панели txAdmin есть свой раздел управления доступом с несколькими режимами, один из которых завязан на членство в Discord-гильдии — если он закрывает вашу задачу, это избавляет от поддержки кастомного Lua-ресурса. Названия режимов и их поведение меняются от версии к версии, так что перед тем как полагаться на встроенный вариант, сверьтесь с документацией актуальной версии txAdmin.

Испытательный срок, отказы и повторные заявки

Приём в whitelist — не разовое событие, а начало испытательного периода. Разумная практика — держать новичка первую неделю под условным статусом Trial: отдельная Discord-роль, видимая модераторам как метка «новичок», и повышенное внимание к первым сессиям. Если за это время появляются жалобы на RDM, метагейминг или отказ от роли в стрессовых ситуациях — статус легко откатить назад, не дожидаясь, пока проблема укоренится.

Отказ формулируйте конкретно, а не общей фразой «анкета не прошла». «Плохо раскрыт мини-сценарий, ответ короче трёх предложений» — даёт понятный путь на повторную подачу, а не ощущение произвольного отказа. Стандартный кулдаун на повторную заявку — 3-7 дней, этого хватает, чтобы человек реально доработал ответы, а не просто нажал «отправить» ещё раз с теми же формулировками.

Ведите базу решений (таблица в Notion, Google Sheets или канал-лог с закреплёнными сообщениями) — чтобы новый модератор не собеседовал заново человека, которого уже отклоняли месяц назад по конкретной причине.

Частые вопросы