HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Half-Life SDK (https://hlfx.ru/forum/forumdisplay.php?forumid=8)
-- Вопросы по коду (https://hlfx.ru/forum/showthread.php?threadid=4636)
Отправлено demoth 17-07-2015 в 08:35:
Вопросы по коду
Всем добрый день
Накопилось несколько вопросов по коду (добавляю потом ещё):
1) где можно (и можно ли) установить pev->renderfx для v_ и p_ моделек? (Хочется поставить glowshell). У меня получилось сделать glowshell у монстров и итемов на полу
2) куда добавить новые поля монстрам и игрокам? (К примеру в entvars или CBaseMonster) Надо добавить уровень и XP
Спасибо
Отправлено XaeroX 17-07-2015 в 08:44:
1) Да, можно. Применять его надо в вьюмодели на клиенте.
Например, скопировать с игрока вот так:
C++ Source Code:
1 | void V_CalcGunAngle ( struct ref_params_s *pparams ) |
5 | viewent = gEngfuncs.GetViewModel(); |
9 | // ...оригинальный код... |
12 | cl_entity_t *ent = gEngfuncs.GetLocalPlayer(); |
15 | viewent->curstate.renderfx = ent->curstate.renderfx; |
16 | viewent->curstate.renderamt = ent->curstate.renderamt; |
17 | viewent->curstate.rendercolor.r = ent->curstate.rendercolor.r; |
18 | viewent->curstate.rendercolor.g = ent->curstate.rendercolor.g; |
19 | viewent->curstate.rendercolor.b = ent->curstate.rendercolor.b; |
2) Можно добавлять новые поля в класс, либо же использовать какие-либо незанятые поля в entvars. Последние можно передавать по сети на клиент, например.
Отправлено demoth 17-07-2015 в 21:55:
у вьюмодели получилось установить эффект.
а как быть с p_ моделькой? та которая отображается в руках у других игроков?
Добавлено 18-07-2015 в 00:55:
вопрос по хаду:
я создал VGUI менюшку, хочу для примера вывести туда хп игрока (мультиплеер), как получить указатель на entvars игрока (если он вообще есть на клиенте)? пробовал через gEngfuncs.GetLocalPlayer()->curstate.health, но там 0
Отправлено XaeroX 17-07-2015 в 23:15:
Цитата:
demoth писал:
если он вообще есть на клиенте
Нет.
Цитата:
demoth писал:
пробовал через gEngfuncs.GetLocalPlayer()->curstate.health, но там 0
Смотри содержимое gHUD.m_Health.
Отправлено Ku2zoff 17-07-2015 в 23:38:
Цитата:
demoth писал:
gEngfuncs.GetLocalPlayer()->curstate.health, но там 0
Потому что не передаётся по сети. В функции AddToFullPack соответствующая строчка есть, а в delta.lst в секции Player_Encode нету. Зато есть в секции clientdata_t. Но! При обработке входящих энтварсов на клиенте в функции HUD_ProcessPlayerState здоровье не обрабатывается. В HUD_TxferPredictionData тоже. Поэтому pev->health на клиенте получить невозможно. Но если дописать по строчке в нужные функции на клиенте, и добавить строчку в delta.lst, то всё будет приходить. Это полезно для всяких vuser'ов и iuser'ов, которые не передаются пользовательскими мессагами. И для нелокальных игроков. Для локального же игрока, удобнее брать инфу из ХУДа, как и подсказал XaeroX.
Добавлено 18-07-2015 в 05:38:
Цитата:
demoth писал:
а как быть с p_ моделькой?
C++ Source Code:
1 | int CStudioModelRenderer::StudioDrawPlayer( int flags, entity_state_t *pplayer ) |
6 | if (pplayer->weaponmodel) |
8 | cl_entity_t saveent = *m_pCurrentEntity; |
10 | model_t *pweaponmodel = IEngineStudio.GetModelByIndex( pplayer->weaponmodel ); |
12 | m_pStudioHeader = (studiohdr_t *)IEngineStudio.Mod_Extradata (pweaponmodel); |
13 | IEngineStudio.StudioSetHeader( m_pStudioHeader ); |
15 | StudioMergeBones( pweaponmodel ); |
17 | IEngineStudio.StudioSetupLighting (&lighting); |
19 | [color=orange][b]StudioRenderModel( );[/b][/color] |
21 | StudioCalcAttachments( ); |
23 | *m_pCurrentEntity = saveent; |
Перед строчкой StduioRenderModel(); вставляешь:
C++ Source Code:
m_pCurrentEntity->curstate.renderfx = pplayer->renderfx; |
m_pCurrentEntity->curstate.renderamt = pplayer->renderamt; |
m_pCurrentEntity->curstate.rendercolor.r = pplayer->rendercolor.r; |
m_pCurrentEntity->curstate.rendercolor.g = pplayer->rendercolor.g; |
m_pCurrentEntity->curstate.rendercolor.b = pplayer->rendercolor.b; |
Должно заработать.
Отправлено ~ X ~ 18-07-2015 в 09:16:
Пора уже давно избавиться от говноедства в виде передачи здоровья и батареек через ж...мессаги. Вальва ж нам дельты дала. Вот и заполняйте их...
__________________
Минутка полезного:
Бесплатный UT-подобный Half-Life mod.
Бесплатный редактор для 32-битных текстур. Без дотнета.
Бесплатный IDE для любых компиляторов и ЯП.
Бесплатная Windows-подобная ОС.
Проверка грамматики русского языка.
Чат по hl[fx]: [email protected]
Отправлено demoth 18-07-2015 в 19:40:
ок, спасибо за разъяснения
>Вальва ж нам дельты дала
>упаковка энтитией
>дельты
буду признателен если подскажете где почитать про эти вещи (можно на английском). Сам ничего не нагуглил
Отправлено XaeroX 18-07-2015 в 20:15:
demoth
Файл "NetworkEntity.doc" в Half-Life SDK.
Если у тебя его нет, могу выложить.
Отправлено demoth 18-07-2015 в 20:21:
XaeroX,
есть)
Отправлено ~ X ~ 18-07-2015 в 20:23:
В двух словах, "дельта" (да, из математики пошло) - это каждый кадр просчёт разницы между состояниями одной структуры данных и пересылки разницы адресатам. Поскольку во всех entity_state/clientdata (или как их там) есть health, то лучше здоровье передевать через них, а не городить MESSAGE_BEGIN() как было в ХЛ 1015. Я у себя в XDM это запилил и оно работает. Сэкономило мне парочку message index-ов и избавило от шелухи в виде отдельных пакетов с их заголовками, обёртками, задержками, порядками... В общем, чего и вам желаю 
__________________
Минутка полезного:
Бесплатный UT-подобный Half-Life mod.
Бесплатный редактор для 32-битных текстур. Без дотнета.
Бесплатный IDE для любых компиляторов и ЯП.
Бесплатная Windows-подобная ОС.
Проверка грамматики русского языка.
Чат по hl[fx]: [email protected]
Отправлено XaeroX 18-07-2015 в 20:28:
~ X ~
У тебя каждый кадр посылается один бит информации "поле health не изменилось". Каждый кадр, Карл! Так уж устроена дельта.
А т.к. health меняется относительно редко, то не логичнее ли посылать его именно отдельной мессагой? Вот и в Valve так рассудили.
Отправлено demoth 18-07-2015 в 23:44:
да, после такого чтива не поспишь..
допустим хочу видеть какое то кастомное поле в окошке
1) я добавляю в какую то из этих сущностей поле
clientdata_t ( в эту скорее всего да?)
entity_state_t
entity_state_player_t
custom_entity_state_t
2) добавляю необходумую дельту в delta.lst
3) как то манипулирую новым полем на сервере
4) основной вопрос - как и на что мне надо получить указатель в соответсвующем Update() окошка чтобы увидеть новое поле (допустим у локального игрока)?
Отправлено XaeroX 18-07-2015 в 23:48:
Цитата:
demoth писал:
я добавляю в какую то из этих сущностей поле
В них ничего нельзя добавлять - по крайней мере, без исходников движка.
В дельту можно добавлять только уже существующие поля, которых по какой-то причине в оригинальной дельте нет.
Отправлено ILZM 19-07-2015 в 15:21:
Не понел. Разве не посылается ли delta в момент, когда она изменилась, а не во время каждого кадра? Например, добавил я в дельту pev->iuser4. Теперь оно каждый кадр отправляться будет что ли, даже если оно меняется раз в 3 секунды? Может ли быть, что оно не дошло до клиента?
И ещё. Попробовал я в моде убрать все клиентские события выстрелов оружия и собрал все сообщения MESSAGE в одну. Там же отправляется аж 3 сообщения при выстреле (анимация оружия, TE_bounceshell и количество патронов). Может ли быть, что это окончательно не дойдёт до клиента?
Отправлено XaeroX 19-07-2015 в 15:48:
Цитата:
ILZM писал:
Разве не посылается ли delta в момент, когда она изменилась, а не во время каждого кадра?
Дельта - это разница между кадрами, а не между значениями переменных.
Мне лень вдаваться в детали (я же не Дядя миша), но часто бывает так, что нужно посылать информацию типа "переменная не изменилась, Карл", и это один бит. Либо "изменилась", это тоже один бит, а потом новое значение переменной.
Цитата:
ILZM писал:
Может ли быть, что оно не дошло до клиента?
Конечно, может быть. Дельта - ненадёжное сообщение. Но т.к. она шлётся каждый кадр, то рано или поздно таки дойдёт.
Цитата:
ILZM писал:
Может ли быть, что это окончательно не дойдёт до клиента?
Зависит от типа мультикаста. Если тип надёжный (MSG_ONE), то дойдёт наверняка (по крайней мере, будет пересылаться раз за разом при потерях, и если уж совсем не доходит - клиент будет дропнут). Если ненадёжный (MSG_BROADCAST), то ничего не гарантируется, двиг пошлёт сообщение один раз и забудет как про страшный сон.