Ролевые фреймворки RedM: VORP или RSG

Для нового ролевого сервера RedM выбор стоит между VORP и RSG. VORP - фреймворк RedM с более долгой историей, со своей архитектурой и самым большим набором ресурсов, написанных специально для RedM вокруг vorp_core. RSG происходит от QBCore и сразу кажется знакомым каждому, кто держал сервер FiveM на QBCore или Qbox: активное использование ox_lib и подход QBCore к структуре работ, предметов и данных игрока. Обоим нужна MySQL-совместимая база данных через oxmysql, оба работают на одном и том же FXServer, и ни один не может запускать ресурсы другого. Выбирайте VORP, если вам нужен самый глубокий пул существующих ресурсов RedM; выбирайте RSG, если ваши разработчики уже знают QBCore. И оставайтесь на выбранном, потому что переезд позже означает вайп персонажей. В этом руководстве они честно сравниваются, а также описана установка любого из них.

Что делает фреймворк в RedM#

FXServer даёт вам пустой мир: ни персонажей, ни денег, ни инвентаря, ни работ. Фреймворк - это общий слой, который всё это даёт и с которым общаются все остальные ресурсы.

• Игроки и персонажи. Идентификаторы, привязанные к аккаунтам, несколько персонажей на аккаунт, создание персонажа, внешность.
• Инвентарь и предметы. Что существует, у кого что есть, вес и лимиты, используемые предметы.
• Деньги. В RedM обычно наличные и золото плюс то, что добавляют банковские ресурсы.
• Работы и группы. Кто шериф, доктор, ранчеро и что это позволяет.
• API. Функции и события, которые вызывают другие ресурсы, чтобы читать и менять всё перечисленное.

Именно API привязывает вас к фреймворку. Ресурс работы, написанный для VORP, вызывает функции VORP, чтобы выдавать предметы и платить зарплату; на RSG он этого сделать не сможет без переписывания. Поэтому выбор фреймворка - на самом деле выбор экосистемы. Версия того же решения для FiveM, с теми же рассуждениями, - в статье о сравнении фреймворков FiveM.

VORP и RSG рядом#

Ни один объективно не лучше. Это два стиля с двумя сообществами, оба на момент написания активно поддерживаются. Прежде чем определиться, проверьте в репозитории каждого проекта свежие коммиты и релизы, потому что RedM - небольшая сцена, и баланс смещается.

Вопросы, на которые стоит ответить до выбора

Решение о фреймворке, принятое только по репутации, обычно пересматривают через полгода. Сначала ответьте на эти вопросы, и выбор обычно делается сам:

1. Кто будет писать код? Если никто в команде не пишет на Lua, важнее всего размер пула существующих ресурсов, и вы будете собирать, а не строить. Если ваши разработчики пришли из QBCore, RSG обойдётся им дешевле всего.
2. Какие ресурсы вам обязательно нужны? Перечислите пять-десять систем, вокруг которых строится ваш сервер, - определённое ощущение инвентаря, система лошадей, система закона и наград за головы, конкретная экономика, - и проверьте, на какой фреймворк рассчитаны лучшие доступные версии.
3. Какие платные ресурсы вы собираетесь купить? Платные скрипты RedM обычно указывают поддерживаемый фреймворк. Проверьте, что нужная вам версия поддерживает ту версию фреймворка, которую вы будете запускать, а не только его название.
4. Сколько документации вам нужно? Почитайте документацию обоих проектов по часу, прежде чем решать. Та, которую вашей команде легче понимать, - та, которую вам будет легче поддерживать.
5. Насколько активен проект прямо сейчас? Посмотрите на свежие коммиты, открытые issues и примечания к выпускам ядра и его основных ресурсов. Остановившийся фреймворк - это фреймворк, который вам придётся форкнуть.

Запишите ответы. Когда через год кто-нибудь предложит перейти, вы захотите знать, почему выбрали то, что выбрали.

VORP#

VORP - это набор ресурсов вокруг vorp_core: vorp_inventory, vorp_character для создания персонажа и внешности, vorp_menu, админские инструменты и утилиты, а также длинный список ресурсов работ и систем от сообщества, написанных под них. Он существует почти всю историю RedM, поэтому большинство скриптов, созданных для RedM, которые вы найдёте, - бесплатных или платных, - либо рассчитаны на VORP, либо предлагают версию для VORP.

Ресурс получает объект ядра и работает с активным персонажем игрока:

local Core = exports.vorp_core:GetCore()RegisterNetEvent("ranch:sellMilk", function()    local src = source    local user = Core.getUser(src)    if not user then return end    local character = user.getUsedCharacter    -- validate on the server, then pay    character.addCurrency(0, 5.0)   -- 0 = cashend)

Старые ресурсы VORP получают ядро через TriggerEvent("getCore", function(core) ... end); современные используют export. Если вы смешиваете старые и новые ресурсы, в вашем коде встретятся оба стиля. Точный API устанавливаемой версии смотрите в документации VORP, потому что имена функций и типы валют менялись между мажорными версиями.

Кому обычно подходит VORP: серверам, которые хотят быстро собрать много существующего контента RedM, владельцам, которые не разработчики и будут полагаться на то, что сообщество уже создало, и командам, которые предпочитают API, спроектированный вокруг понятий RDR2, а не адаптированный из ролевой игры в GTA V.

RSG#

RSG берёт структуру QBCore - ядро с общими данными для работ, предметов и банд, таблицу PlayerData на каждого игрока, колбэки и функции на объекте игрока - и адаптирует её под RedM. Если вы писали для QBCore, код RSG читается естественно:

local RSGCore = exports['rsg-core']:GetCoreObject()RegisterNetEvent("ranch:sellMilk", function()    local src = source    local Player = RSGCore.Functions.GetPlayer(src)    if not Player then return end    if Player.Functions.RemoveItem("milk", 1) then        Player.Functions.AddMoney("cash", 5)    endend)

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

Кому обычно подходит RSG: командам с опытом QBCore, серверам, переходящим с FiveM на RedM, чьи разработчики хотят сохранить привычки, и владельцам, которые предпочитают компоненты ox_lib самописным.

Что должно лежать в основе обоих#

Что бы вы ни выбрали, фундамент одинаковый:

1. FXServer с `set gamename rdr3` и требованием актуальной сборки RDR2. Конфиг описан в статье о настройке сервера RedM.
2. Включённый OneSync. Оба фреймворка на него рассчитывают.
3. oxmysql, запущенный раньше всего, что обращается к базе данных.
4. `ox_lib`, который нужен RSG и многим ресурсам эпохи VORP тоже.
5. Ядро фреймворка, затем его собственные ресурсы, затем всё, что построено на нём.

Строка подключения к базе данных указывается в server.cfg через set, а не sets:

set mysql_connection_string "mysql://user:password@host:3306/redm?charset=utf8mb4"set mysql_slow_query_warning 150ensure oxmysqlensure ox_lib# framework core and its resources follow, in the order its docs give

mysql_slow_query_warning заставляет oxmysql выводить каждый запрос медленнее 150 мс - это самый дешёвый инструмент производительности, который есть на ролевом сервере. Остальное - схема, индексы, бэкапы - в статье о базах данных FiveM и oxmysql, которая без изменений относится к RedM.

Установка: рецепт или вручную#

Рецепты txAdmin. Deployer txAdmin может собрать сервер по рецепту: он скачивает ресурсы, пишет server.cfg, создаёт таблицы базы данных и заполняет строку подключения. Рецепты от сообщества есть и для VORP, и для RSG. Это самый быстрый путь к работающему серверу, с одной оговоркой: рецепт фиксирует те версии, под которые он был написан. Перед запуском проверьте, что рецепт поддерживается и свежий.

Вручную. Склонируйте или скачайте каждый ресурс из репозиториев фреймворка, импортируйте файл .sql каждого ресурса в свою базу данных и добавьте строки ensure в задокументированном порядке. Медленнее, но вы точно знаете, что установлено и откуда, а это важно, когда приходит время обновлений.

Импорт SQL - шаг, который пропускают, а потом тратят на него вечер. Каждый ресурс фреймворка, который хранит данные, поставляет файл схемы, и если его таблиц нет, ресурс падает - часто тихо, с ошибками nil позже. Импортируйте их все до первого запуска, с кодировкой utf8mb4, чтобы имена с диакритикой и эмодзи не ломали вставки. Импорт файла .sql и ошибки, которые вы увидите, разобраны в статье об импорте и экспорте в phpMyAdmin.

Порядок загрузки

Порядок в server.cfg - это порядок загрузки, а порядок загрузки - это порядок зависимостей. Типичная форма для любого из фреймворков:

ensure oxmysqlensure ox_libensure <framework core>ensure <framework inventory>ensure <framework character and appearance>ensure [framework]ensure [jobs]ensure [maps]

Ресурс работы, который запускается раньше ядра, запрашивает объект ядра, получает nil и до конца сессии ничего не делает, обычно без явной ошибки. Если что-то работает после ручного перезапуска, но не после полного рестарта сервера, значит, оно запускается слишком рано. Папки в скобках вроде [jobs] запускают все ресурсы внутри в порядке, который вы не контролируете, поэтому держите ресурсы с зависимостями друг от друга вне общей скобки или запускайте их явно через ensure.

Производительность#

Ни один из фреймворков обычно не бывает причиной медленного сервера. В RedM, как и в FiveM, скрипты сервера выполняются в одном основном потоке, а нагрузка идёт от ресурсов сверху: циклов, работающих в каждом кадре, запросов к базе данных внутри циклов, событий, рассылаемых всем игрокам гораздо чаще, чем нужно. Диагностика та же - resmon 1 в консоли F8 клиента, profiler record на сервере, hitch warning в консоли и график тиков в txAdmin, - и изложена в статье о производительности сервера FiveM.

Два замечания, касающихся фреймворков. Ресурсы инвентаря делают больше всего работы с базой данных из всего, что есть на ролевом сервере, поэтому проверьте, как они сохраняют: сохранение каждого изменения сразу безопасно и дорого, сохранение по интервалу дёшево и теряет данные при падении. А сохранение данных персонажей всех игроков разом по таймеру вызывает регулярные задержки; распределённые во времени сохранения этого избегают.

Обновления и актуальность#

Оба фреймворка развиваются, а ресурсы на них следуют за ними в собственном темпе.

• Фиксируйте версии. Знайте, какой релиз ядра и каждого крупного ресурса у вас работает. Обновляйтесь осознанно, а не повторным запуском рецепта.
• Обновляйте ядро вместе с его ресурсами. Обновление ядра часто требует соответствующих обновлений инвентаря и персонажей; читайте примечания к выпуску для всего набора.
• Держите тестовый сервер. Второй лицензионный ключ с того же аккаунта Cfx.re, копия server-data, копия базы данных. Обновляйтесь сначала там.
• Делайте backup базы данных перед каждым обновлением и знайте, что можете его восстановить. Аргументы - в статье о бэкапах, которые действительно восстанавливаются.

Платные ресурсы RedM часто находятся под escrow и привязаны к аккаунту Cfx.re, которому принадлежит ваш лицензионный ключ, ровно как в FiveM. Перед покупкой проверьте, что ресурс поддерживает ваш фреймворк и его текущую версию.

Защита событий фреймворка

Оба фреймворка открывают серверные события и колбэки, которые меняют деньги и предметы, а ресурсы на них добавляют ещё сотни. Любой подключённый клиент может вызвать любое серверное событие с любыми аргументами, поэтому каждый обработчик, который что-то выплачивает, должен проверять входные данные на сервере: используйте source, а не ID игрока, присланный клиентом, считайте суммы на сервере, проверяйте, что игрок находится там, где происходит действие, и действительно владеет тем, что заявляет к продаже, и ограничивайте частоту. Пример RSG выше удаляет предмет перед выплатой; пример VORP лишь отмечает место, где должна быть эта проверка, а многие бесплатные ресурсы пропускают её целиком. Метод подробно описан в статье о вариантах античита для FiveM, и он без изменений применим к RedM, включая sv_entityLockdown под OneSync.

Смена фреймворка в будущем#

Пути миграции нет. VORP и RSG хранят персонажей, предметы и деньги в разных таблицах с разной структурой, а каждый ресурс поверх них написан под один API. Смена означает новую базу данных, новый список ресурсов и вайп персонажей для ваших игроков. Некоторые серверы превращают это в событие - новый сезон, новый регион карты, - но это всё равно сброс. Это самый сильный аргумент за то, чтобы потратить на выбор вечер до того, как зайдёт первый игрок.

FAQ#

Что лучше для нового сервера RedM - VORP или RSG?

Однозначно лучшего нет. У VORP больше пул ресурсов, созданных для RedM, и более долгая история; RSG знаком разработчикам QBCore и повсюду использует ox_lib. Выбирайте по опыту своей команды и по нужным вам ресурсам.

Можно ли запускать ресурсы VORP и RSG на одном сервере?

Нет. Каждый ресурс написан под API и данные одного фреймворка. Запуск обоих ядер сразу даст вам два набора персонажей и инвентарей, которые ничего друг о друге не знают.

Нужна ли обоим фреймворкам база данных?

Да. Оба хранят персонажей, инвентари и деньги в MySQL-совместимой базе данных через oxmysql и импортируют свои таблицы из файлов .sql, поставляемых с каждым ресурсом.

Можно ли использовать ресурсы QBCore на RSG?

Напрямую - нет. RSG следует структуре QBCore, что сильно упрощает портирование, но ресурсы QBCore вызывают natives GTA V и собственные exports QBCore. Их нужно адаптировать под RDR3 и под RSG.

Можно ли потом перейти с VORP на RSG?

Только начав заново. Структуры данных разные, и поддерживаемой миграции нет, поэтому игроки теряют своих персонажей. Выбирайте до запуска.