Reverse Engineering

Custom RAGE

Приватний reverse-engineered replacement layer для інфраструктури Rage Multiplayer, зібраний після оголошення про закриття платформи, щоб зберегти робочий шлях для реального GTA RP-сервера.

Node.jsCEFLauncher FlowGTA V RPVoice ChatDLC Resources

Після того як 26 травня 2026 року Rage Multiplayer оголосив про закриття на вимогу Rockstar Games, GTA RP-серверам довелося думати про виживання без офіційної платформи. Custom RAGE став спробою зберегти повний шлях підключення через точну емуляцію офіційної інфраструктури.

ПЛАТФОРМА ЩЕ ВІДПОВІДАЛА, ТОМУ РЕАЛЬНУ ПОВЕДІНКУ МОЖНА БУЛО ЗІБРАТИ, А НЕ ВГАДУВАТИ.

May 26, 2026 / platform shutdown / custom infrastructure / 100% compatibility target / May 26, 2026 / platform shutdown / custom infrastructure / 100% compatibility target / May 26, 2026 / platform shutdown / custom infrastructure / 100% compatibility target / May 26, 2026 / platform shutdown / custom infrastructure / 100% compatibility target /
01 / deadline

Платформа ще жила, але таймер уже пішов

26 травня 2026 року Rage Multiplayer оголосив, що закривається після вимоги Rockstar Games. Для власників RP-серверів це було не просто новиною. Це означало, що офіційний server list, launcher flow, client connection path, CEF layer, voice chat, DLC loading та інші platform services отримали дату завершення.

02 / the bet

Ставка була на емуляцію

Я зв'язався з розробниками українського RP-сервера і запропонував серйозніший шлях, ніж новий скін для лаунчера. Ідея була reverse-engineer достатню частину інфраструктури Rage Multiplayer, щоб існуючий сервер міг жити без оригінальної платформи.

03 / reverse engineering lab

Лабораторія навколо всього ланцюга

Дослідження було не про один endpoint, а про поведінку всієї системи. Кожен шар треба було побачити, повторити і перевірити з наступним.

01

Request / response capture

Офіційні service calls досліджувались, поки вони ще були доступні, з фокусом на launch і server discovery flows.

02

Launcher behavior

Replacement layer мав підтримувати standard launch, direct connect, server list і branded wrapper scenarios.

03

CEF and resource flow

In-game interfaces, DLC packs і resources мали завантажуватись як один безперервний client experience.

04

Voice and sync

Voice chat і synchronization були proof points, бо вони швидко ламаються, якщо platform behavior скопійований лише частково.

04 / compatibility proof

Сумісність треба було довести, а не заявити

Мета була не зробити щось схоже. Емулятор мав поводитись як оригінальний ланцюг: launcher, platform service, game client, server resources, CEF UI, voice і in-game synchronization. Якщо будь-яка ланка відчувалася неправильно, весь серверний досвід переставав бути Rage Multiplayer.

100% ціль по core connection flow
CEF тестовані in-game interfaces працювали
DLC packs і resources вантажились коректно
Voice chat і synchronization були стабільними
Real RP тести в реальному серверному середовищі
05 / product shapes

Продуктові форми, які з'явилися під час тестів

Replacement launcher

Знайома оболонка, яка залишає шлях користувача близьким до того, що гравці вже знали.

Branded launcher

Server-owned client зі своєю айдентикою, посиланнями, новинами і connection state.

No giant master-list

Вужча версія, де лаунчер показує тільки сервери одного RP-проєкту або мережі.

Universal platform

Ширший напрям, де emulator стає базою для hosting, discovery і server migration.

06 / what worked

Що запрацювало в прототипі

Доказом був не один окремий feature. Важливо було те, що кілька platform-dependent систем працювали разом в одному реальному RP-середовищі.

CEF interfaces

Server UI відкривався всередині гри, а не ставав зламаною оболонкою після запуску.

DLC packs

Додатковий контент і ресурси проєкту доставлялись через replacement flow.

Resource delivery

Сервер міг продовжувати віддавати assets, потрібні для існуючих gameplay scenarios.

Voice chat

Voice залишався частиною compatibility target, а не необов'язковим бонусом.

Synchronization

Тестове середовище залишалось достатньо цілісним для реальних in-game scenarios.

Wrapper mode

Та сама база могла стати branded launcher для конкретного RP-сервера.

07 / hard part

Складність була не в одному API

Найважчим було повторити поведінку всього ланцюга: launcher -> platform service -> game client -> server resources -> in-game UI. Правильна відповідь з неправильним timing, resource assumption або launcher state все одно ламала б відчуття, що це та сама платформа.

08 / why private

Чому це не стало публічним

Прототип залишився приватним, бо GTA RP-сервер, під який він робився, закрився. Після цього сенс релізу змінився: вже не було живого ком'юніті для міграції, хоча емуляція дійшла до working proof-of-compatibility.

09 / if continued

Якби проєкт продовжився

Custom RAGE міг вирости в public master-list layer, white-label launchers для RP-серверів, dashboard для власників, branded launcher builder і migration path для старих Rage Multiplayer-ком'юніті.

Public master-list

Hosted discovery layer для серверів, яким потрібен post-RAGE home.

White-label launchers

Custom launchers для RP-ком'юніті з власним брендингом і server list.

Owner dashboard

Панель для status, resources, DLC config, news і connection settings.

Migration path

Tooling для старих Rage Multiplayer-ком'юніті, щоб зберегти server flow.

Custom RAGE унікальний тим, що був зроблений у момент, коли платформа зникала. Завдання було не придумати красивіший інтерфейс, а зберегти робочу поведінку цілої серверної екосистеми через точну емуляцію.