Дядя Миша писал: если энтить не видна - то и декаль не рисуем
да уж. И как я сразу не сообразил? Дядя Миша, я же просто скопипастил за французами, а они там удаляют декали насовсем. Удалять не надо, только спрятать от глаз игрока. Проблема с пропаданием при выпадении энтить из PVS решена. Осталось избавиться от трассы.
Ну можно же в движке посмотреть как декали устроены, вместо того чтобы у французов копипастить.
Добавлено 12-10-2020 в 21:25:
Ku2zoff кстати. А ты сделал так, чтобы декаль, выпущенная на границе двух различных энтить, ложилась на обе?
Ну скажем декаль взрыва, которая ложится и на мир и на дверь. Меня в халфе это всегда бесило, но там архитектурный принцип не позволял иначе сделать. А в кастомных декалях - запросто.
Глупый вопрос. Есть два массива декалей в классе CDecalManager:
C++ Source Code:
spritedecal_s m_pDecals[MAX_DECALS];
spritedecal_s m_pTempDecals[MAX_DECALS];
Сам менеджер разумеется имеет конструктор и деструктор, которые вызываются соответственно из HUD_Init:
C++ Source Code:
if (!g_pDecalManager)
g_pDecalManager = new CDecalManager();
И HUD_Shutdown:
C++ Source Code:
if (g_pDecalManager)
{
delete g_pDecalManager;
g_pDecalManager = NULL;
}
Надо ли удалять с помощью delete эти массивы в деструкторе CDecalManager? Сейчас довольно много гуглил, и с большим трудом нашёл инфу, что delete необходимо вызывать лишь для объектов, созданных с помощью new. Получается, память из-под этих массивов автоматически высвободится при выходе из игры? И функцию деструктора для CDecalManager мне можно оставить пустой?
Добавлено 14-10-2020 в 00:51:
Цитата:
Дядя Миша писал: А ты сделал так, чтобы декаль, выпущенная на границе двух различных энтить, ложилась на обе?
Нет, я ещё не добрался до косметики. Но зато решил проблемы с "отваливанием" декалей от энтить после чейнджлевела. Дело было так: возвращаюсь на предыдущую карту, где ранее оставил декали на стенах и дверях. Те двери, что на момент чейнджлевела находятся в PVS, остаются связанными с декалями, и декали вместе с ними ездят. А вот те двери, что не находятся в PVS на момент чейнджлевела, теряют свои декали: те просто перестают двигаться и висят в воздухе. Пришлось завести функцию, которая заново аттачит декали к энтитям, если они попадают в PVS.
Ужос, сколько нюансов.
Статические массивы (с заранее заданным размером) не нужно удалять отдельно. Их элементы уже в составе памяти, выделенной под объект. Удаляешь объект - высвобождается память выделенная под его составляющие.
Цитата:
Ku2zoff писал: память из-под этих массивов автоматически высвободится при выходе из игры?
При выходе из игры вообще вся память процесса высвободится
А как ты добился вылетов? В итоге у тебя iuser4 никуда не делся, просто теперь называется по-другому: iJumpTime. Так делать крайне не рекомендуется.
Кстати, все эти иузеры, фузеры, вузеры и еузеры надо вручную сохранять. То есть заводить соответствующую переменную для энтити, и оперировать ей в сейв/ресторе.
Вылеты потому, что есть лимит на переменные, а этот iJumpTime новая переменная для playermove_s, она необходима, т.к я изменил прыжки игрока. Так что тут либо жертвы, либо, хз, хак какой-нибудь.
Vadiman писал: Вылеты потому, что есть лимит на переменные, а этот iJumpTime новая переменная для playermove_s, она необходима, т.к я изменил прыжки игрока. Так что тут либо жертвы, либо, хз, хак какой-нибудь.
Не новая переменная это у тебя. Ты стёр iuser4 и вместо неё написал iJumpTime. С таким же успехом можно было везде где надо вписать iuser4 вместо iJumpTime. Ты новую переменную не создал. Ты старую переименовал. А это лишний геморой.
Добавлено 14-10-2020 в 10:51:
Цитата:
Дядя Миша писал: я и говорю, народ боится с памятью работать.
Я проштудировал твою статью по работе с оперативной памятью, и пришёл к такому же мнению.
Цитата:
FreeSlave писал: При выходе из игры вообще вся память процесса высвободится
Ну только если в деструкторе не накосячишь, и оно не зависнет намертво
Цитата:
Дядя Миша писал: они же статически объявлены.
Вот кто бы об этом удобочитаемо написал. Если объявлены статически, значит удалятся вместе с удалением класса-родителя. Какие ужосы советуют на stackoverflow, это кащьмар. Я целые сутки убил впустую, пытаясь что-то вразумительное по этой теме отыскать.
Даже не вопрос, а скорее просто наблюдение. Ну, если вопрос, то тогда - почему не работает?
Проблему-то я решил, но суть в чем: у монстров есть функция TakeDamage. В нее я по образцу из зомби добавил коэффициенты в зависимости от типа урона и даже от установленного skill. Ну например:
C++ Source Code:
if ( (g_iSkillLevel == SKILL_MEDIUM) && (bitsDamageType == DMG_BLAST) ) // half-dmg from explosions in medium mode
{
flDamage *= 0.5;
}
Это было прописано в функции монстра. В конце нее там всегда идет return CBaseMonster::TakeDamage. Как я предположил, измененный в монстре flDamage уйдет в основную функцию и там продолжится выполнение. Но он не уходит. Я задолбался отлаживать, выставил алерты в консоль, но коэффициент не применялся. И тут я сделал по-другому. Я пошел прямехонько в combat.cpp и заменил
C++ Source Code:
flTake = flDamage;
на такую конструкцию:
C++ Source Code:
1
if (FClassnameIs( pev, "monster_barney" ))
2
{
3
if ( (g_iSkillLevel == SKILL_MEDIUM) && (bitsDamageType == DMG_BLAST) ) // half-dmg from explosions in medium mode
4
{
5
flDamage *= 0.5;
6
}
7
else
8
{
9
flTake = flDamage;
10
}
И оно работает как часы.
А у зомби ведь прописан коэффицинт дамага от пуль. Я проверил алертами - тоже не работает. Нужно в комбат переносить вот таким макаром. В обычной халфе тоже не работает. Проверить в халфе никак нельзя, поэтому я проверял по количеству пуль. Одинаково. А коэффициент там 0.3, то есть в 3 раза больше должен был потратить пуль.
Интересно, почему так.
В конце функции CTalkMonster::TakeDamage все равно идет переадресация на CBaseMonster::TakeDamage. Там просто проверяется наличие дамага, чтобы например ученый комментировал. Само повреждение там не выполняется, так что это без разницы. У барни вроде окей все, я там почти все подчистил под себя.
Так или иначе, вот здесь у зомби коэффициент не работает - я его вообще не трогал.
C++ Source Code:
1
int CZombie :: TakeDamage( entvars_t *pevInflictor, entvars_t *pevAttacker, float flDamage, int bitsDamageType )
В халфе тоже никакого 30% дамага от пуль не заметил. Еще не совсем понимаю, для чего эти векторы тут стоят.
Алерты я ставил, flDamage выводился и менялся. А в итоговом дамаге не учитывался, пока я все в комбат не перетащил.
По поводу эффектов, интересно есть ли вообще описание какое либо как их делать? В оригинальной халве они примитивные, и самое противное - зашиты в движок, их переделать поэтому не получится, только кодить с нуля, хотя взять тот же BloodTrail из кваки - годный был бы эффект если поменять точки на спрайты.
Рендерсистем выглядит интересно, в Tyrian GS эффекты на ее основе неплохие, много чего интересного, кольца в стиле матрицы для гаусс пушки и прочее, правда моя попытка прикрутить чисто ее к халве не увенчалась успехом, уж сильно код там перелопачен, да и если в сервере с горем пополам более менее понятно, то на клиенте для меня вообще тихий ужас, смотря в код абсолютно не понимаю как он вообще работает.
Добавлено 24-10-2020 в 10:08:
По мелочи еще, в сети есть некие попытки воссоздать код ОпФора, с боссами и прочим, интересно какая из них лучше? Где те же боссы нормально работают с веревками.
Chyvachok писал: правда моя попытка прикрутить чисто ее к халве не увенчалась успехом, уж сильно код там перелопачен
Всё прикручаемо. Нинада. Вот сорцы HLSDK 2.4 (с гитхаба) с прикрученной RS от XDM 3.0.3.4. Компилится без ошибок. Пробегись виндиффом, я там мог кое-что закомментить, т.к. прикручивал чисто для проверки по-быстрому. Ну и из эффектов - только взрывы, естественно, остальное надо копипастить из XDM.
Вложение: cdll_dll.7z (595.3 кб)
Этот файл был скачан 73 раз.