Хуки и 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
 
Последнее редактирование:

lemeshovich

Участник
Сообщения
19
Реакции
6
По поводу приватных плагинов
сейчас бы про платные плагины для пока не существующего мода размышлять...
SM всегда был про открытый исходный код за редкими исключениями, а с таким подходом как у вас, даже название resourcemod зазорно использовать
 
Последнее редактирование:

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
сейчас бы про платные плагины для пока не существующего мода размышлять...
SM всегда был про открытый исходный код за редкими исключениями, а с таким подходом как у вас, даже название resourcemod зазорно использовать
Это я начал эту тему, но я уточнил что я забегаю наперед ибо мода по сути еще нет.
Мне просто стало интересно как автор хочет/планирует защищать JS (что по сути текст).
Разве что, можно еще делать как pkg (или его аналоги).
🤡?
 

UnrediKK

Участник
Сообщения
3
Реакции
3
Это я начал эту тему, но я уточнил что я забегаю наперед ибо мода по сути еще нет.
Мне просто стало интересно как автор хочет/планирует защищать JS (что по сути текст).
Разве что, можно еще делать как pkg (или его аналоги).
🤡?
Да начнётся новая эра перепрокражи плагинов
 

Twelvee

Участник
Сообщения
75
Реакции
147
забегаете не то что на перед, а гораздо дальше и не в ту сторону, чем нужно бы
А в какую сторону нужно?

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

По поводу названия - его предложили в этом треде, оно мне понравилось.

По поводу исходного кода - код resourcemod будет открыт и мало того, я очень надеюсь на пулл реквесты и issues с багами, одному тяжело уследить за такой системой. Закрытой будет архитектура регистри плагинов, чтобы нельзя было ее скопировать, затем поменять эндпоинт на свой и запускать любые плагины без лицензии. Сервер "авторизации" будет один и он будет закрыт от всех кроме меня и команды разработчиков (если такая будет, конечно).

Хотите использовать Sourcemod - не вижу пуллреквестов в гите sourcemod или sdk или metamod. Мы вроде бы все в одной лодке, а этот тред нужен чтобы координировать эту лодку и пытаться построить что-то на месте отсутствующего sourcemod.

Как только выйдет Sourcemod - пожалуйста, используй его, а еще можешь использовать И sourcemod И resourcemod, не вижу тут ничего зазорного. Название кстати не resourcemod, а resourcemod.

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

Задавайте свои вопросы, даже если они покажутся глупыми, в этот тред. Любая информация, абсолютно любая, позволяет сделать resourcemod более удобным для сообщества hlmod (Сообщества администраторов игровых серверов).

В данный момент нужно просто подождать, а если ждать совсем невозможно - Update Dota & CS2 support by GAMMACASE · Pull Request #125 · alliedmodders/hl2sdk
 

oleg_nelasy

Участник
Сообщения
664
Реакции
46
@Twelvee, Мне интересно по поводу быстро действия системы? В одной из тем тоже пытались что то делать но все уперлось в то что команды выполняются слишком долго.
 

Twelvee

Участник
Сообщения
75
Реакции
147
@Twelvee, Мне интересно по поводу быстро действия системы? В одной из тем тоже пытались что то делать но все уперлось в то что команды выполняются слишком долго.
Все зависит от команд)
На самом деле это работает достаточно быстро. Не уверен что будет работать быстрее чем Sourcemod, все же sourcepawn компилируемый язык, а не JIT, однако я нативно интерпретирую плагины через встроенный JS рантайм Duktape. Это вполне быстрый рантайм, так как он заточен под выполнение во встраиваемых системах и имеет 0 сторонних зависимостей. Чистый JS рантайм.

Это было бы долго, если бы javascript запускался как отдельное приложение и общался с ядром через любой доступный протокол, тем более если протокол был бы выбран не удачным (какой-нибудь http, ни дай бог).
Под нативным выполнением Javascript я как раз подразумеваю что само ядро выполняет Javascript код и тут же в этом же процессе общается с движком Source. А так как само ядро встроено (загружено как динамический dll) внутрь процесса игрового сервера - задержки просто нет.
Пока что не могу себе представить узких по производительности моментов, однако если они появятся - мы можем переписать часть интерфейса на c++, добавив скорости яваскрипту. Это тоже плюс собственного рантайма.

Duktape так же поддерживает модули на с++, примерно как нода со своим node-gyp. Однако в первой версии это поддерживаться не будет, для поддержки с++ модулей нужно проделать не маленькую работу)

Ответ: нет, это работает быстро, насколько быстро - посмотрим когда sdk полностью восстановят и мы сможем построить действительно большие плагины. Какой-нибудь wcs, например, и запустить его на 64 слотовом сервере. Если на этом моменте появятся проблемы с производительностью - уже есть варианты как их исправить
 
Последнее редактирование:

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
Страйкер восхитился

Глянул особенности этого вашего @d4Ck Tape (Duktape)
И мне стало плохо. ES5? Частичная поддержка ES6 и ES7
Можно, что по новее? 👀
1695300001928.png


Из того что поддерживает хотя бы ES6 вижу jerryscript, но возможно оно не подходит по задачам ... смотреть надо...
 
Последнее редактирование:

Twelvee

Участник
Сообщения
75
Реакции
147
Страйкер восхитился

Глянул особенности этого вашего @d4Ck Tape (Duktape)
И мне стало плохо. ES5? Частичная поддержка ES6 и ES7
Можно, что по новее? 👀
Посмотреть вложение 114328
А с какой целью? ECMAScript спецификации лишь стандарты которые поддерживают рантаймы
es5 более чем достаточно для плагинов cs2, а с учетом отсутствия поддержки модулей ноды - вообще не вижу смысла тащить более новый рантайм

Из новых рантаймов, кстати, подходит только spidermonkey, но он создан в первую очередь для Firefox. Эксклюзивный саппорт нам не дадут, как v8 дали ноде, это значит что они будут делать патчи в первую очередь ориентируясь на то как запустить яваскрипт быстрее в их браузере, а не на наших серверах.

Каких-то конкретных вещей не хватает в es5? Если таких вещей не много - могу добавить их нативную поддержку. Дактейп реализовал поддержку наиболее важных изменений в es6, как мне кажется https://wiki.duktape.org/postes5features

Пока не поздно - могу попробовать интегрировать рантайм spidermonkey, однако действительно не вижу в этом какого-либо киллер-преимущества.
Есть еще QuickJS, но от его документации становится плохо, и опять же - не вижу преимуществ по сравнению с рантаймом на спецификации ES5.

Имхо лучше взять проверенный, хорошо задокументированный, созданный специально под embedded решения рантайм, а потом добавить свой сахар, который необходим для быстрой работы скриптов (которые и без сахара будут отлично работать).
А вы что думаете, попытаться в другой рантайм с поддержкой более новых ECMAscript стандартов? Желательно еще ответить на вопрос "зачем"
 

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
А с какой целью?
Синтаксис.
Вот берете вы почти любой js код из ответа на stackoverflow.
Пихаете в плагин и "магическим" образом оно работает.
В ES6 есть куча функций которые очень удобно использовать.
И большинство разрабов привыкло к ним.
Заберете даже банальные возможности ES6 и сразу будет ощущение неполноценности RMD. Потому-что пишешь, как обычно, а оно не работает.
Каких-то конкретных вещей не хватает в es5? Если таких вещей не много - могу добавить их нативную поддержку. Дактейп реализовал поддержку наиболее важных изменений в es6, как мне кажется https://wiki.duktape.org/postes5features
Map не вижу и это как минимум. Если просмотреть все возможности ES6 мне символов не хватит.
1695303730752.png


@Twelvee пока не поздно, посмотрите хотя бы на JavaScript engine for Internet of Things
Возможно он подойдет. Если нет — просмотреть все возможные варианты.
Ибо писать на ES5 будет мега неудобно. Особенно тем кто пишет активно на Node 20+ версии.
А тут им скажут мол "хрен вам", пишите по синтаксису из далекого ES5.

Можно, наверное, пытаться подключать какие-нибудь полифилы, но они не везде смогут вырулить.

Upd:
Суть в чем, если вы сделаете движок, который будет обрезан (в плане синтаксиса / возможностей), много кто может отказаться делать плагины ибо зачем им писать на каком-то обрезке из JS-а вместо полноценного, а те кто все таки захочет чет писать, будет плеваться каждые пол метра потому-что "как обычно" написать не получится. Нет половины функционала, нет Map, Set, нет некоторых операторов и тд.
В идеале, конечно же, брать как можно выше. Так как в том же условном ES2017 добавили async/await что очень часто используется.
Так что зависит. Очень сильно.
 
Последнее редактирование:

Twelvee

Участник
Сообщения
75
Реакции
147
Синтаксис.
Вот берете вы почти любой js код из ответа на stackoverflow.
Пихаете в плагин и "магическим" образом оно работает.
В ES6 есть куча функций которые очень удобно использовать.
И большинство разрабов привыкло к ним.
Заберете даже банальные возможности ES6 и сразу будет ощущение неполноценности RMD. Потому-что пишешь, как обычно, а оно не работает.

Map не вижу и это как минимум. Если просмотреть все возможности ES6 мне символов не хватит.
Посмотреть вложение 114332

@Twelvee пока не поздно, посмотрите хотя бы на JavaScript engine for Internet of Things
Возможно он подойдет. Если нет — просмотреть все возможные варианты.
Ибо писать на ES5 будет мега неудобно. Особенно тем кто пишет активно на Node 20+ версии.
А тут им скажут мол "хрен вам", пишите по синтаксису из далекого ES5.

Можно, наверное, пытаться подключать какие-нибудь полифилы, но они не везде смогут вырулить.

Upd:
Суть в чем, если вы сделаете движок, который будет обрезан (в плане синтаксиса / возможностей), много кто может отказаться делать плагины ибо зачем им писать на каком-то обрезке из JS-а вместо полноценного, а те кто все таки захочет чет писать, будет плеваться каждые пол метра потому-что "как обычно" написать не получится. Нет половины функционала, нет Map, Set, нет некоторых операторов и тд.
В идеале, конечно же, брать как можно выше. Так как в том же условном ES2017 добавили async/await что очень часто используется.
Так что зависит. Очень сильно.
Хм..
Действительно, вы правы, я гляну в сторону других рантаймов с поддержкой актуальных es спецификаций
 

Twelvee

Участник
Сообщения
75
Реакции
147
QuickJS / Deno / MuJS

бенчмарк производительности рантаймов, вдруг что-то с этого пригодиться
Я скорее всего останавливаюсь на QuickJS, он очень схож с Duktape, но поддерживает актуальные спецификации ES
JIT в любом случае приходилось бы дописывать в дактейпе, тут просто это будет сделать чуть сложнее.
Но документация прям печальная, однако домены те же что и в дактейпе, но с другими названиями.

P.S. ору с предложений назвать мод который я делаю EventScripts :D
 

September

Участник
Сообщения
5,238
Реакции
2,742
  • Команда форума
  • #54
Я скорее всего останавливаюсь на QuickJS, он очень схож с Duktape, но поддерживает актуальные спецификации ES
JIT в любом случае приходилось бы дописывать в дактейпе, тут просто это будет сделать чуть сложнее.
Но документация прям печальная, однако домены те же что и в дактейпе, но с другими названиями.

P.S. ору с предложений назвать мод который я делаю EventScripts :D

EventScript Rework :D
 

SAZONISCHE

Участник
Сообщения
405
Реакции
232
Я скорее всего останавливаюсь на QuickJS, он очень схож с Duktape, но поддерживает актуальные спецификации ES
JIT в любом случае приходилось бы дописывать в дактейпе, тут просто это будет сделать чуть сложнее.
Но документация прям печальная, однако домены те же что и в дактейпе, но с другими названиями.

P.S. ору с предложений назвать мод который я делаю EventScripts :D
Стоит еще рассмотреть Hermes и SpiderMonkey, мб и GraalVM, ибо наличие JIT компиляции дает многократное преимущество в скорости в отличии от QuickJS.
 

Reiko1231

AlexTheRegent
Сообщения
508
Реакции
1,335
Можно, наверное, пытаться подключать какие-нибудь полифилы, но они не везде смогут вырулить.
Хм..
Действительно, вы правы, я гляну в сторону других рантаймов с поддержкой актуальных es спецификаций
Ничего нового в современных спецификациях не появилось, только лишь синтаксический сахар. Я бы не стал ориентироваться на что-то новое, что не опробовано\не до конца реализовано в погоне за новыми спецификациями, а лучше бы просто в этап билда добавил использование babel (а ещё лучше webpack или vite + поддержку typescript). Потеря в производительности будет ничтожной, но если инструмент хороший и проверенный временем, то результат разработки будет надёжнее, да и сама разработка будет быстрее, если инструмент уже знаком или предлагает гораздо больше нужного.
 

Twelvee

Участник
Сообщения
75
Реакции
147
Ничего нового в современных спецификациях не появилось, только лишь синтаксический сахар. Я бы не стал ориентироваться на что-то новое, что не опробовано\не до конца реализовано в погоне за новыми спецификациями, а лучше бы просто в этап билда добавил использование babel (а ещё лучше webpack или vite + поддержку typescript). Потеря в производительности будет ничтожной, но если инструмент хороший и проверенный временем, то результат разработки будет надёжнее, да и сама разработка будет быстрее, если инструмент уже знаком или предлагает гораздо больше нужного.
А зачем там vite или webpack? С тайпскриптом тоже сомнительно.
Babel изначально создавался чтобы добавить поддержку нового яваскрипта в старые браузеры, разве нет? У нас окружение на всех серверах будет одинаковым, мы создаем единственный рантайм
 

Black_Yuzia

Зарабатываю на жизнь Мемами про Крузю.
Сообщения
693
Реакции
372
тайпскриптом тоже сосомнительно
Лично от себя скажу что после работы с TS на JS вам будет неудобно.
Потому, желательно, поддержку TS добавить.
Так как вы сможете прописать все API глобально без необходимости заглядывать в документацию лишний раз (условно можно будет полностью типизировать все глобальные методы, классы, переменные прочее (GetClients, GetPlayers и тд.).

Хотя это можно сделать и просто через d.ts Documentation - Creating .d.ts Files from .js files но поддержка полноценного TS все же будет лучше. Но повторюсь, не критично если её не будет. Просто придётся лишний раз заморачиваться с билдингом из ts в js в таком случае.
 
Сверху Снизу