ILZM
Эвенты тоже ненадёжные, если не указан флаг FEV_RELIABLE.
Главное отличие от мессаг в том, что они могут предиктиться на клиенте, и в этом случае будут проиграны даже в случае, если потеряются по дороге.
Можно использовать vuser-ы. В каждом из них содержится целых 3 поля, в которые можно записывать float. + к этому iuser3 и iuser4 ни чем не заняты. fuser3 и fuser4 тоже вроде бы не заняты. Вполне достаточно для каких-нибудь фич, типа стамины, ползания и вектора разброса пуль.
XaeroX писал: ~ X ~
У тебя каждый кадр посылается один бит информации "поле health не изменилось". Каждый кадр, Карл! Так уж устроена дельта.
А т.к. health меняется относительно редко, то не логичнее ли посылать его именно отдельной мессагой? Вот и в Valve так рассудили.
Не правильно.
Мессага "здоровье" появилась до дельты. Когда был entvars_t и всё. Для защиты от читерства, скорее всего. Потом появилась возможность фильтровать, что и кому слать, но в вальве ленивые кодеры для сохранения совместимости они это оставили.
Побуду добрым, сообщу любителем мессаг, что их ждёт тотальный облом в их колчиестве, пока те не нагородили...
Кстати, на кол-во зарегистрированных евентов абсурдных ограничений нет?
~ X ~ писал: Побуду добрым, сообщу любителем мессаг, что их ждёт тотальный облом в их колчиестве, пока те не нагородили...
128 штук максимум, кажется. Не так уж мало. Но, думаю, что мессаги нужно при любой возможности заменять энтварсами. К примеру: нам нужно отображать здоровье и броню игрока в режиме наблюдателя, кода мы наблюдаем данного игрока. Для этого придётся завести новую мессагу (см. сорцы отреверсенной дллки кс 1.6). А если мы допишем передачу энтварса pev->health, то сможем избавиться от мессаг gmsgHealth, gmsgBattery и нам не придётся заводить новую мессагу для спектаторского здоровья и брони. Сейчас я как раз изучаю дельту, и думаю, что передавать для игрока, а что нет. Ну и для других энтить тоже. XDM, кстати, очень полезен для изучения в этом плане
~ X ~ писал: Мессага "здоровье" появилась до дельты. Когда был entvars_t и всё. Для защиты от читерства, скорее всего.
И как же это поможет защитить от читерства?
Цитата:
~ X ~ писал: для сохранения совместимости они это оставили.
Совместимость там всё равно была нарушена, так что - не аргумент.
Цитата:
~ X ~ писал: Побуду добрым, сообщу любителем мессаг, что их ждёт тотальный облом в их колчиестве, пока те не нагородили...
Посмотри, как вальва запихала добрую сотню TE_сообщений в одну-единственную мессагу SVC_TEMPENTITY.
Цитата:
~ X ~ писал: на кол-во зарегистрированных евентов абсурдных ограничений нет?
1024 эвента.
Добавлено 22-07-2015 в 16:02:
Цитата:
Ku2zoff писал: Но, думаю, что мессаги нужно при любой возможности заменять энтварсами.
Во-первых, далеко не при любой. Но при описанной тобой ситуации это разумно, да.
Во-вторых, надо очень внимательно смотреть, каким энтитям разрешать их передачу. Для чего на сервере есть всякие DELTA_UNSETBYINDEX.
если конкретно
1) как всё таки посылаются новые статы (деньги, опыт, уровень)
2) как сделать чтобы появившиеся монстры сразу охотились за игроком
3) каким образом реализованы скилы
4) инвентарь
demoth
1. Через vuser. Туда я с горяча засунул информацию, которая не так часто обновляется, буду переделывать потом.
2. Этого у меня нет. Они могут найти игрока только если его видели хоть раз.
3. Функция UsePlayerSkill проверяет класс и переменную m_iCurrentSkill, в зависимости от них при вызове и активирует скилл, но там тонкости есть, ибо ауры сделаны отдельно и пассивки тоже. Пассивки активируются там где тебе нужно (например увеличение урона при каждом попадании в монстра).
4. Инвентарь сделан по тутору для хл2, оттуда брал проверку наличия места в инвентаре при подъеме шмотки. У меня получилось 3 структуры, состоящие из информации (айди шмотки, тип, защита, 3 параметра) и так для 11-ти вроде слотов (0, 1, 2, 3 - эквипы на игрока и остальные 8 - сам инвентарь). Почему три структуры: первая серверная для игрока, вторая серверная для вещей и третья клиентская для игрока. Вещи имеют свой полноценный инвентарь, можно сказать, а сделано это для возможности паковать все вещи из инвентаря при смерти в рюкзак, который дропается, чтобы поднять при респауне. При манипуляциях любых с вещами мы отправляем мессагу на клиент, состоящую из всех параметров шмотки, перечисленных выше, и слота, в который мы все это будем заносить/обновлять. Когда мы одеваем новую шмотку взамен старой, то в коде это выглядит просто как сохранение шмотки из первого слота в буфер, копируем в первый слот содержимое второго слота, после этого из буфера копируется шмотка из первого слота во второй. С клиента, графической оболочки идут команды такого типа: moveitem "slot1" "slot2", dropitem "slot1", upgradeitem "slot1" и т. д.
С линуксом не дружу. Однако, друг запускал на линуксе и мы успешно играли по сети. Вайн что ли, не знаю, он разбирается в этом, а я нет. Факт есть фактом, что играли по сети без каких-либо проблем.