что имеется на данный момент ?
- пока только реализация функционала модуля аналога "хамсандвич" (моя любимая тема .. (: )

какие отличия от предыдущего варианта ?
1) продумана основная концепция АПИ клиентской части, т.е. функции обработчики событий будут иметь ссылку на интерфейс в качестве аргумента, при этом есть гарантия совместимости интерфейсов клиентской/серверной частей (достигается за счёт промежуточного слоя написанного в "С" стиле: "POD" структуры). 1но из "вкусных" нововведений - возможность использовать функциональные обьекты в качестве функций обработчиков событий на клиентской стороне (ну и "лямбды", естественно ..)

пример кода на стороне клиента для отлова события(аналог "хамсандвича"):

// "ing" окончания - признак "pre" событий, "ed" - для "post". (кстати, тоже идея Тёмы)

// можно будет внедрить "using" для сокращения записи.
// можно не создавать промежуточных переменных на вроде "playerManager" & "playerSpawnPre" ..
auto playerManager = lambdamod::entity::vtable::CManager("player"); // работает и с индексами энтитей
auto playerSpawnPre = playerManager.spawning([](ISpawning & api) {
// api. => call some methods ..
});
auto playerSpawnPost = playerManager.spawned([](ISpawned & api) {
// api. => call some methods ..
});
// ..
playerSpawnPre.disable();
playerSpawnPost.disable();

2) использован(ы) стандарт(ы) "с++": 14-17, что в частности побуждает клиента использовать нововведения в язык.
3) поддержка только линукс платформы (а какой смысл поддерживать другие ? практически всегда сервера крутятся на линях(в качестве основных систем), либо на виртуалках ..)
4) не будут требоваться к обновлению библиотеки в игровой директории, связано с включением зависимого кода непосредственно в бинарник.
5) планируется расширять мод возможностями подключения других языков, таких как к примеру java/python .. (точно пока не ясно какие из языков буду внедрять, но, главное что внедрить можно будет любой язык имеющий совместимость с "С")
6) полная совместимость с "амхх" пока под вопросом ..
7) пока планируется поддержка только: "half-life".
8) клиенты мода не будут иметь доступ к "edict_t" (по умолчанию .. конечно запрета на подключение в дополнение метамода (и активации режима - "let's rock!") - не будет, возможно даже по началу это будет хорошей альтернативой, т.к. имеющийся функционал пока скуден. Для этих целей предоставлю инклуд облегчающий использование "метамода") и аналогичным ему типам, всё взаимодействие будет
осуществляться через примитивы, такие как к примеру "int32_t", ну или "const char *" (на то 2 причины: I)упрощение II)издержки использования "POD" типов), но, с клиентской стороны будет красивенькое АПИ, разумеется ..
9) пока планируются к поддержке/реализации только основные события из "vtable", такие как:
спавн, тайк дамадж, киллед, тач, юзед, трейс аттак, финк .. другие, более редкие в использовании события будут добавляться по мере необходимости.
10) подключение мода к коду клиента сводится к подключению 1го лишь инклуда "lambdamod.hxx" (можно инклудить в более чем 1ну единицу трансляции, линк проблем не будет),
никаких дополнительных ".cpp"/".cxx" не требуется! (и объектников тоже ..)

почему тема в обсуждениях ? и где вообще код .. ?
- тема в обсуждениях, т.к. прежде чем что-то создавать конкретное, я бы всё-таки хотел поинтересоваться
мнением форумчан касательно некоторых из вопросов .. (о них в конце)

- промежуточный код (это даже ещё не бета! т.к. он постоянно обновляется) буду периодически скидывать сюда, для ознакомления (возможно кто-то что-то заметит для улучшения).
при этом - код компилироваться не будет, т.к. скидывать пока буду только основную часть кода (т.е. не весь код), а у самого меня код на данный момент в проекте "кьют криэйтора". Как возникнет определённость по возникшим у меня вопросам, и/или когда доделаю то что планирую к завершению в ближайшие сроки - приведу код к компилируемому состоянию, а пока буду выкладывать как расписал, возможно + "сошки" (для тестов).

мои вопросы к форумчанам:
- какие из основных событий из "vtable" я упустил ? (приводил список ранее ..)

- уточнение АПИ для функций обработчиков на стороне клиента:
на данный момент все передаваемые в качестве аргументов(пример: ISpawning / ISpawned) типы не имеют АПИ, вот собственно их("АПИ") то и нужно продумать
к примеру - "спавн пре" не имеет смысла суперсидить, соответственно в АПИ не будет этого метода, а вот в "тейк дамадж пре" - суперсид будет.
к основному методу можно отнести получение "id" объекта для которого обрабатывается событие (а так же получение "id" для других энтитей передаваемых через аргументы, как тот же "инфликтор").

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

собственно код: (время жизни ссылок около полугода)
- парсер хамдаты, возможно кому-то будет интересно (пока к основному коду не подключен)
https://pastebin.com/S3yM4ZXi
- основной код (код клиента и сервера тут вперемешку, т.к. пока тестовый вариант .. более того - подлом "vtable" пока закомментирован, связано с недавним обновлением кода. Уже на днях всё восстановлю)
https://pastebin.com/mKxm8FRk

что в ближайших планах ?
- выложить код бета версии, естественно, а для это нужно:
I) разделить код клиента/сервера (см. ссылки на код ..).
II) включить в код сервера парсер "хамдаты".
III) дореализовать код перехвата "спавн" события.
IV) обеспечить компилируемость проекта.

- когда планирую с этим закончить ? на этой неделе.

благодарности:
"ProstoTem@": именно его предложения были основой для чуть ли не всех нововведений(к примеру те же "лямбды" в качестве функций обработчиков). Так же очень активно помогал с поиском различного рода ухищрений связанных с новыми стандартами, либо вариантами обхода оптимизаций компилятора.