Хуки и sourcemod на cs2

Twelvee

Участник
Сообщения
75
Реакции
147
Привет!
Прошел уже месяц с прошлого треда про скриптинг в cs2 и я решил актуализировать информацию + рассказать чем занимается комьюнити AlliedModders в данный момент.

Начнем с главного - Sourcemod не портирован в кс2 и вероятно не будет. Активная разработка Sourcemod в кс2 не ведется, достаточно посмотреть коммиты и пулл-реквесты в репозитории sourcemod.
Metamod все так же работает на source2, что позволяет создать свой sourcemod сообществу, но судя по диалогам в дискорд сервере AlliedModders информации о таких наработках крайне мало, в основном люди просто спрашивают когда будет sourcemod.

Текущие проблемы, почему sourcemod и metamod до сих пор не портировали

1. Metamod и Sourcemod работают на библиотеке SourceHooks, которая в свою очередь позволяет цепляться к публичным интерфейсам Source (memory hook) через декларацию интерфейсов Valve в их SDK.
Самая последняя версия SDK позволяющая цепляться к cs2 серверу находится вот тут Update Dota & CS2 support by GAMMACASE · Pull Request #125 · alliedmodders/hl2sdk, за что огромное спасибо GAMMACASE
В данный момент ребята еще продолжают над ней работать.

2. Архитектура х64. Это критичное изменение для Sourcemod и Metamod, так как куча инструментов была написана под х86 архитектуру. В целом с этой проблемой начали знакомиться еще во времена перехода доты на source2, именно поэтому metamod можно установить к себе на сервер (достаточно сложно, но можно). С SourceMod все сложнее.

3. VSP (Valve Server Plugin). Подробнее обо всех вещах от которых Valve избавились во второй версии Source я напишу чуть ниже, но отказ от Valve Server Plugins становится критичным для AlliedModders проектов. Установка metamod больше не возможна с помощью обычного .vdf файла.

4. Поддержка других игр. Metamod и Sourcemod рассчитаны на множество игр Source, практически все игры Source, если быть точнее. Это добавляет кучу проблем с обратной совместимостью Source и Source2.

5. Мало людей, которые действительно готовы вносить вклад в портирование Sourcemod&Metamod в CS2. За время моего присутствия на сервере AlliedModders я заметил лишь 3-4 человека, которые что-то ковыряют в Metamod. Никто из них не портирует Sourcemod&Metamod в CS2.


Я начал строить сарай
Изначально я увидел что xtance пытался прикрутить к текущей системе скриптинга Javascript.
Меня действительно заинтересовала эта идея и я начал реализовывать свою версию Sourcemod, друзья в тимспике придумали идеальное название - SORAI (Вроде бы как "Небо" на японском, но на русском звучит забавно).
Название вероятно временное :)

Задумка была такой:
Я создаю dll, внутри которой использую metamod и сверху на это все пишу интерфейсы на Javascript для плагинов.
Вскоре узнаю что метамод это слишком жирная штука (она рассчитана сразу на все игры Source) и решаю использовать SourceHook.

Спустя несколько дней у меня получается подключить SourceHook и подписаться на интерфейсы Valve.
Sorai сейчас это dll пакет, который мы подключаем через кастомный dll-injector внутрь процесса cs2. В нем есть возможность подписываться на игровые события и прочие интерфейсы от Valve (CvarChanged, ServerInit, итд).
Проект на очень ранней стадии, его код - это набор тестов работы с движком Source2.

Различия от решений AlliedModders:
1. В Source2 полностью выпилили старую систему игровых событий (igamevents). На смену пришла новая - IGameEventSystem. Любимый и простой FireEvent больше не thing в новом Source. Ивенты теперь отправляются через grpc(?) в Protobuf формате.
2. х64 архитектура. Тут и добавить нечего, кс2 требует x64 dll.
3. Поддержка только CS2, для остальных игр есть Sourcemod.
4. Установка сарая через кастомный dll иньектор. Это временно, пока не придумал лучшего решения с учетом отказа Valve от valve server plugin.

Проблемы с которыми я столкнулся можно и не начинать считать, их действительно море. Однако самая главная, которую я не знаю как решить - отсутствие VGUI интерфейса во втором соурсе.
Менюшек - нет. Это критичная часть любого плагина, никто не любит писать все команды в чат или консоль. Если есть идеи как реализовать меню в cs2 - буду рад слышать.

Что в планах:

1. Я решил отказаться от идеи с простыми интерфейсами Javascript, так как по сути это будет являться socket-based архитектурой плагинов (общение через IPC), в дискорде AlliedModders мне дали понять что это не тру.
Поэтому я буду добавлять в сарай движок v8, чтобы дать возможность нативно разрабатывать плагины на Javascript.
2. Создать публичный репозиторий и простенький сайт с базовой информацией о статусе разработки.
3. Доделать базовый функционал ивентов (проверить работу компиляции protobuf).
4. Сделать возможным hot-reload плагинов на яваскрипте.
5. Сделать возможным на уровне движка проверки подлинности плагина. Чтобы облегчить жизнь создателям приватных плагинов.
6. Пакетный менеджер для плагинов. Установка плагинов через cli? Звучит интересно.

Если есть идеи по развитию данного проекта - буду рад их услышать. У нас появилась возможность избавиться от проблем Sourcemod и я знаю далеко не о всех этих проблемах.
Для c++ разработчиков:
Я открою исходный код Sorai как только добавлю в него v8. Сейчас и поддерживать его невозможно, так как не существует основной архитектуры. Просто куча кода которая тестирует взаимодействие с движком Source2.
Оффтоп

Для всех остальных:
Подскажите название, что ли. Я ж реально назову его сараем.

Ну и конечно же хотел бы сказать огромное спасибо сообществу AlliedModders, ребята всегда готовы прийти на помощь. Особенные благодарности двум людям - Core Team AlliedModders psychonic и создателю плагинов, активному участнику актуализации SDK - GAMMACASE
 
Последнее редактирование:

xstage

🏹
Сообщения
726
Реакции
754
А зачем там vite или webpack? С тайпскриптом тоже сомнительно.
Babel изначально создавался чтобы добавить поддержку нового яваскрипта в старые браузеры, разве нет? У нас окружение на всех серверах будет одинаковым, мы создаем единственный рантайм
Это сборщики ты им суешь новые приблуды, если хочешь можешь посыпать это еще типизацией в виде TypeScript, а он высирает все в чистый обратно совместимый js код. Но они работают не только с js, а еще и css, sass, scss, fonts, img, svg и т.д. Эту всю кашу минифицируют, оптимизируют, соединяют, разъединяют.
Сборщиков становится все больше, каждый гонится за скоростью, но в основном они основываются на Babel. Babel в свою очередь узкоспециализированный - он какает только JS. Кормить его можно TS, JS, JSX, TSX, а он все это переварит и сделает JS той спецификации, которая будет указана в настройках.
Все эти инструменты нужны только на стадии сборки, потом у нас появляется чистый JS.

1695486224854.png
 

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
Это сборщики ты им суешь новые приблуды, если хочешь можешь посыпать это еще типизацией в виде TypeScript, а он высирает все в чистый обратно совместимый js код. Но они работают не только с js, а еще и css, sass, scss, fonts, img, svg и т.д. Эту всю кашу минифицируют, оптимизируют, соединяют, разъединяют.
Сборщиков становится все больше, каждый гонится за скоростью, но в основном они основываются на Babel. Babel в свою очередь узкоспециализированный - он какает только JS. Кормить его можно TS, JS, JSX, TSX, а он все это переварит и сделает JS той спецификации, которая будет указана в настройках.
Все эти инструменты нужны только на стадии сборки, потом у нас появляется чистый JS.

Посмотреть вложение 114390
А зачем тебе css, scss, img и тд.?
 

Gazzi

Участник
Сообщения
84
Реакции
12
Не понимаю почему именно JS а не C++ или C#, или здесь акцент на переносимости между платформами? CoreCLR тоже кроссплатформенная, куча возможностей из коробки и Open source библиотек, есть и работа с указателями, один и тот же плагин не придётся компилировать под Linux/Windows или другие архитектуры, например ARM, главное написать нативную библиотеку которая будет запускать среду CLR и реализовать API
Сообщения автоматически склеены:

В s&box, который тоже на Source 2 весь скриптинг на C#, полностью его воссоздать не получится, но хотя бы использовать как эталон для некоторых функций
 
Последнее редактирование:

Twelvee

Участник
Сообщения
75
Реакции
147
Не понимаю почему именно JS а не C++ или C#, или здесь акцент на переносимости между платформами? CoreCLR тоже кроссплатформенная, куча возможностей из коробки и Open source библиотек, есть и работа с указателями, один и тот же плагин не придётся компилировать под Linux/Windows или другие архитектуры, например ARM, главное написать нативную библиотеку которая будет запускать среду CLR и реализовать API
Сообщения автоматически склеены:

В s&box, который тоже на Source 2 весь скриптинг на C#, полностью его воссоздать не получится, но хотя бы использовать как эталон для некоторых функций
Я тоже долгое время обдумывал разные варианты, но решил остановиться на яваскрипте из-за того что каждый 5-классник сможет написать свой плагин.
Порог входа в написание плагинов это очень важно, имхо.

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

QuickJS наконец-то заработал. Собрать его под винду было отдельным видом наказания, а разобраться как он работает без документации - вообще пыткой. Но, все работает.
1695728708611.png
1695728787128.png

Нужны ли CommonJS модули? Не понятно зачем, есть поддержка ES модулей (import {smth} from "plugin_name/file.js"). ES модули, кстати, изначально берут свое начало из папки plugins, чтобы иметь возможность писать аддоны к уже установленным плагинам. Каждый плагин - тоже запускается как ES модуль в своем собственном контексте. Контексты разные, но рантайм у них один - ядро.
Асинхронные операции, JSON, Даты, RegExp, MapSet, Proxy, TypedArrays, Промисы, Console.log - готово (большая часть шла из коробки).

Ивенты работают следующим образом:
1. Вы создаете обработчик ивента (js функцию).
2. Подписываетесь на ивент (если плагин не подписан на ивент - мы его не будем вызывать).
3. Через SourceHook мы хукаемся к ивентам и если видим что плагин подписан на него - вызываем его callback.
То есть яваскрипт не работает каждый фрейм (конечно же), он вызывается лишь раз. Однако при запуске плагин выполняется и мы имеем контекст выполнения, через который и выполняем callback.


Сейчас работаю над интеграцией curl (для реализации метода fetch) и модулем файловой системы. Как с этим закончу - открою доступ к репозиторию.
Сайт готов, поправлю инфу (там еще упоминается Duktape) и настрою дискорд сервер - раскачу. Отдельно еще отпишусь в этот тред как сделаю.

До первой юзабельной версии осталось:
1. curl и в целом сетевые методы (нашел библиотеку под названием minnet, проорал в голос)
2. FS и все что связано с FS. Планирую запретить ядру смотреть куда-то выше корня игрового сервера, чтобы плохие люди не могли написать fs.write в любую точку файловой системы. Это ок? Есть подводные?
3. Описать все ивенты в структуры. Думаю это необходимо сделать, сейчас ивенты в протобафах и в разных местах, хочу их унифицировать для API ResourceMod (порог входа важен).
4. Доделать регистри плагинов и загрузку плагинов по http.
5. Базы данных? Может перейдем на отправку данных по http с дальнейшей обработкой?
6. Локализация. В Sourcemod сделано не плохо, как сделать лучше - не знаю. Сделаю +- так же.
7. Таймеры и интервалы.

Вероятно будут еще подводные камни, которые нужно будет исправлять по ходу. Хотелось бы перед публикацией репозитория исправить бОльшую часть таких камней.
 

Grey83

не пишу плагины с весны 2022
Сообщения
8,537
Реакции
5,001
решил остановиться на яваскрипте из-за того что каждый 5-классник сможет написать свой плагин.
Может всё же лучше тогда на питоне: он вроде у них сейчас моднее яваскрипта.
Ну и был вариант плагинов на питоне под соурс (уже даже есть хоть немного плагинов на нём).
 

Gazzi

Участник
Сообщения
84
Реакции
12
По поводу API - это не так, если написать API и заставлять общаться игровой движок с движком плагинов через любой интерфейс, кроме как напрямую вызывать нужные методы из памяти, это приведет к socket-based архитектуре. Задержки, даже минимальные, это плохо в нашем кейсе. Либо я не совсем представляю себе о каком АПИ идет речь.
Под API я имел в виду написать обертку функций движка для C#, добавить поддержку событий и тп
 

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
Сейчас работаю над интеграцией curl (для реализации метода fetch)
Есть axios. Не подходит?
Сообщения автоматически склеены:

Описать все ивенты в структуры
Звучит как TypeScript
Сообщения автоматически склеены:

Базы данных? Может перейдем на отправку данных по http с дальнейшей обработкой?
Ты же не будешь делать сайт который будет глобально принимать запросы (со всех серверов / плагинов).
Можно оставить это решение за разрабочтиком плагинов.
Тем самым разрешить им использовать любые библиотеки для работы с БД, в том числе ORM (sequelize например) или использовать сторонние сервисы для работы с бд (работа через REST API с бд) ака сайты
Сообщения автоматически склеены:

6. Локализация. В Sourcemod сделано не плохо, как сделать лучше - не знаю. Сделаю +- так же.
Чет типо такого i18n
 
Последнее редактирование:

MaZa

Участник
Сообщения
1,732
Реакции
980
Я тоже долгое время обдумывал разные варианты, но решил остановиться на яваскрипте из-за того что каждый 5-классник сможет написать свой плагин.
Порог входа в написание плагинов это очень важно, имхо.

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

QuickJS наконец-то заработал. Собрать его под винду было отдельным видом наказания, а разобраться как он работает без документации - вообще пыткой. Но, все работает.

Нужны ли CommonJS модули? Не понятно зачем, есть поддержка ES модулей (import {smth} from "plugin_name/file.js"). ES модули, кстати, изначально берут свое начало из папки plugins, чтобы иметь возможность писать аддоны к уже установленным плагинам. Каждый плагин - тоже запускается как ES модуль в своем собственном контексте. Контексты разные, но рантайм у них один - ядро.
Асинхронные операции, JSON, Даты, RegExp, MapSet, Proxy, TypedArrays, Промисы, Console.log - готово (большая часть шла из коробки).

Ивенты работают следующим образом:
1. Вы создаете обработчик ивента (js функцию).
2. Подписываетесь на ивент (если плагин не подписан на ивент - мы его не будем вызывать).
3. Через SourceHook мы хукаемся к ивентам и если видим что плагин подписан на него - вызываем его callback.
То есть яваскрипт не работает каждый фрейм (конечно же), он вызывается лишь раз. Однако при запуске плагин выполняется и мы имеем контекст выполнения, через который и выполняем callback.


Сейчас работаю над интеграцией curl (для реализации метода fetch) и модулем файловой системы. Как с этим закончу - открою доступ к репозиторию.
Сайт готов, поправлю инфу (там еще упоминается Duktape) и настрою дискорд сервер - раскачу. Отдельно еще отпишусь в этот тред как сделаю.

До первой юзабельной версии осталось:
1. curl и в целом сетевые методы (нашел библиотеку под названием minnet, проорал в голос)
2. FS и все что связано с FS. Планирую запретить ядру смотреть куда-то выше корня игрового сервера, чтобы плохие люди не могли написать fs.write в любую точку файловой системы. Это ок? Есть подводные?
3. Описать все ивенты в структуры. Думаю это необходимо сделать, сейчас ивенты в протобафах и в разных местах, хочу их унифицировать для API ResourceMod (порог входа важен).
4. Доделать регистри плагинов и загрузку плагинов по http.
5. Базы данных? Может перейдем на отправку данных по http с дальнейшей обработкой?
6. Локализация. В Sourcemod сделано не плохо, как сделать лучше - не знаю. Сделаю +- так же.
7. Таймеры и интервалы.

Вероятно будут еще подводные камни, которые нужно будет исправлять по ходу. Хотелось бы перед публикацией репозитория исправить бОльшую часть таких камней.
Так если расчет на "школьников", не проще брать тот же C#? Во многих техникумах/вузах его преподают (может и в школах), да и язык не особо сложный.

Ну или как вариант провести голосование )
 
Последнее редактирование:

Twelvee

Участник
Сообщения
75
Реакции
147
Есть axios. Не подходит?
Сообщения автоматически склеены:


Звучит как TypeScript
Сообщения автоматически склеены:


Ты же не будешь делать сайт который будет глобально принимать запросы (со всех серверов / плагинов).
Можно оставить это решение за разрабочтиком плагинов.
Тем самым разрешить им использовать любые библиотеки для работы с БД, в том числе ORM (sequelize например) или использовать сторонние сервисы для работы с бд (работа через REST API с бд) ака сайты
Сообщения автоматически склеены:


Чет типо такого i18n
Javascript как движок - не понимает что такое файловая система или сеть, для этого рантаймы по типу ноды имплементируют свои методы для работы с сетью и файловой системой. Методы по типу setTimeout - тоже не нативны в яваскрипте.
За основу берется curl, а интерфейсы для работы с сетью уже совершенно разные в разных пакетах. Я постараюсь имплементировать интерфейс fetch, но вероятно он будет не полным. Нам не нужны синхронные методы, так как это будет тормозить рантайм.

У нас нет поддержки плагинов ноды, поэтому пакеты ноды по типу i18n или sequelize не подходят. Про обработку данных по http имел ввиду каждый себе напишет свой обработчик данных, которые ему нужно как-то положить в базу. Не каждый же плагин обязательно что-то должен класть в базу. Как облегчить процесс записи в базу - еще предстоит подумать, но я не очень бы хотел реализовывать поддержку записи в базу на прямую из плагина. Это не эффективно по ресурсам, не понятно как смотреть выполнилась ли транзакция, не понятно как обеспечить поддержку ВСЕХ необходимых баз данных итд.
То что я видел в коде плагинов sourcemod, которые работают с базой - это кошмар. Вот думаю что можно с этим сделать.

Тайпскрипт не совсем то о чем я говорил, скорее унифицировать внутреннюю часть вызова ивентов.
По тайпскрипту - есть варианты реализации, но их сложно интегрировать. Есть компилятор тайпскрипта, однако это бинарь на линукс. Документации как обычно - нет. Признаюсь честно - я ненавижу тайпскрипт. Компиляция кода яваскрипта с типами в код яваскрипта без типов и потом запуск этого кода - какой-то треш. Лучше уж аддон для VScode написать который будет показывать все параметры глобального объекта.

ДЛЯ ТЕХ КТО ПРЕДЛАГАЕТ ПЕРЕЙТИ НА ДРУГОЙ ЯЗЫК ПЛАГИНОВ
нет.
 
Последнее редактирование:

R1KO

fuck society
Сообщения
9,457
Реакции
7,786
  • Команда форума
  • #75
5. Базы данных? Может перейдем на отправку данных по http с дальнейшей обработкой?
может sqlite и хватит
Оффтоп
 

Twelvee

Участник
Сообщения
75
Реакции
147
может sqlite и хватит
Оффтоп
Тогда уж можно что-то no-sql засунуть, для небольших проектов с одним сервером. Что-то вроде mongodb. Он еще проще и нет проблем с блокировками/транзакциями, а запись в монгу можно сделать асинхронной.
Если хотите SQL - шлите асинхронные http запросы. Я бы больше озаботился очередью, чем базами данных. Было бы круто просто положить в Rabbit данные, чтобы скрипт их обработал, так было бы еще проще. Я себя стараюсь сдерживать, если бы этого не делал - все логи шли бы в грейлог, создавался бы kubernetes кластер с ингрессами на AWS и для каждого сервера туда деплоилась бы своя обертка хелм-чартами вместе с эластиком куда бы логи из грейлога попадали - короче ResourceMod не вышел бы никогда)
 

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
Тогда уж можно что-то no-sql засунуть, для небольших проектов с одним сервером. Что-то вроде mongodb. Он еще проще и нет проблем с блокировками/транзакциями, а запись в монгу можно сделать асинхронной.
Если хотите SQL - шлите асинхронные http запросы. Я бы больше озаботился очередью, чем базами данных. Было бы круто просто положить в Rabbit данные, чтобы скрипт их обработал, так было бы еще проще. Я себя стараюсь сдерживать, если бы этого не делал - все логи шли бы в грейлог, создавался бы kubernetes кластер с ингрессами на AWS и для каждого сервера туда деплоилась бы своя обертка хелм-чартами вместе с эластиком куда бы логи из грейлога попадали - короче ResourceMod не вышел бы никогда)
Зачем тебе там/тут NoSQL база данных?
У тебя в 99% случаев хранится какой-то юзер + связанные с ним данные (как например в LR юзер + статистика по оружию прочее)
Да и что мешает сделать асинхронно запись/чтение в/из SQL базы данных в таком случае?
Сообщения автоматически склеены:

все логи шли бы в грейлог, создавался бы kubernetes кластер с ингрессами на AWS и для каждого сервера туда деплоилась бы своя обертка хелм-чартами вместе с эластиком
Несите девопсов!
 
Последнее редактирование:

Lev

Добрая душа
Сообщения
360
Реакции
319
@Twelvee,

Доброго времени суток

А будет возможность не использовать систему веб привязки плагинов, сделать альтернативу, локальную для людей, которые сами хотят контролировать свои плагины, не передавая данные на ваши сервера.
Некий вариант для параноиков, если можно так сказать. Грубо говоря использовать систему локально, как старый добрый SM. Сделать вариативность для тех, кто например не планирует покупать приватные плагины и т д, (по сути человек при желании всегда сможет вернуться к системе с веб привязкой, если ему это потребуется)

Не всем хочется зависеть от доступности серверов, не говоря уже о передаче и возможной утечке своих наработок, как пример

P.S. Без камня в ваш огород.
 

Twelvee

Участник
Сообщения
75
Реакции
147
@Twelvee,

Доброго времени суток

А будет возможность не использовать систему веб привязки плагинов, сделать альтернативу, локальную для людей, которые сами хотят контролировать свои плагины, не передавая данные на ваши сервера.
Некий вариант для параноиков, если можно так сказать. Грубо говоря использовать систему локально, как старый добрый SM. Сделать вариативность для тех, кто например не планирует покупать приватные плагины и т д, (по сути человек при желании всегда сможет вернуться к системе с веб привязкой, если ему это потребуется)

Не всем хочется зависеть от доступности серверов, не говоря уже о передаче и возможной утечке своих наработок, как пример

P.S. Без камня в ваш огород.
Хм, в целом такое можно реализовать. Однако это будет проблемно для безопасности приватных плагинов.
Плагины и так будут загружаться через файловую систему, те что бесплатны, но вот как быть если человек каким-то образом получил приватный плагин и сказал конфигу что он "бесплатный", чтобы мод его пропустил и запустил без проверок из файловой системы..

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

Вообще мне и самому не хотелось бы принимать миллиарды запросов на свой сервер, думаю это будет не дешевым удовольствием если каждый сервер кс2 при старте будет слать мне по N запросов на каждый плагин для валидации. Нужно найти баланс между безопасностью и удобством и потребностям пользователей.

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

Зачем тебе там/тут NoSQL база данных?
У тебя в 99% случаев хранится какой-то юзер + связанные с ним данные (как например в LR юзер + статистика по оружию прочее)
Да и что мешает сделать асинхронно запись/чтение в/из SQL базы данных в таком случае?
Две причины - контекст яваскрипта и уродство текущей реализации общения с базой от sourcemod.
Транзакции долгая и комплексная штука, главный вопрос - как передать интерфейсу яваскрипта инструменты для решения конфликтов. Можно конечно на самом деле синхронно выполнять транзакции, но не нагружая контекст яваскрипта этим - EventLoop, но с монгой таких проблем бы не существовало.
Про уродство текущего решения - посмотрите на любой +- большой плагин sourcemod - там будет все смешано в кучу: транзакции, инстанс таблиц, запросы, игровая логика, слушатели ивентов, куча менюшек и регистрации команд. Хочется сделать как-то по другому, чуть более правильно разделить на домены код плагинов. Огромные транзакции в данную логику не очень хорошо подходят. Можно было бы и ORM реализовать, но я скорее сойду с ума чем реализую !нормальную! орм своими руками. Как минимум я не могу ответить на очень простые вопросы: какой паттерн использовать для ОРМ: active-record или сделать что-то вроде доктрины с ее репозиториями и ручными геттерами-сеттерами. Мы все еще говорим о плагинах для кс2, думаю ОРМ тут оверхед. А вот простенький интерфейс над монгой - вполне сойдет за решение. Пока что к базам не переходил, думаю еще есть время все обдумать и обсудить.

Запустил сайтик с посадочной страницей и информацией об основных преимуществах ResourceMod, пока что только на английском. На нем же разместил ссылку на дискорд AlliedModders, это для тех кто хочет помочь с SDK.
На сайте есть дискорд сервер и ссылочка на донатики (совсем не обязательно, это не сбор средств, я энивей закончу и выпущу этого монстра).
Буду всех ждать в дискорде, там более удобно можно будет обсудить те или иные этапы реализации + предложить свои идеи.

P.S. не вчитывайтесь сильно в описание на сайте, там то что будет актуально на релизе (по типу rich documentation). Поэтому назвал Main goals and features

Темку на этом форуме думаю стоит поддерживать в плане информации об обновлениях, для тех кто пришел с поисковика
 
Последнее редактирование:

pchelovek

Добрая душа
Сообщения
76
Реакции
71
Вы сами говорите, что выбрали JS, т.к. плагины сможет писать каждый пятиклассник, может действительно не стоит сильно замарачиваться насчет приватных плагинов, пусть эта забота будет на плечах их разработчиков, если таковые будут.
 
Сверху Снизу