Chyvachok писал: как точно этот UTIL_SetGroupTrace работает? Чет я туплю с ним, это надо обоим сущностям ставить одинаковый groupinfo? Просто я так и не понимаю результата конечного.
При svs.groupop == GROUP_OP_AND две энтити коллайдят, если у них одинаковый групинфо. При svs.groupop == GROUP_OP_NAND две энтити коллайдят, если у них разные групинфо. Вроде так. Ставь барнаклу и жертве одинаковый групинфо, например энтиндекс барнакла и svs.groupop GROUP_OP_NAND. Нужно число отличное от нуля, иначе механизм будет игнорить. После падения жертвы на землю делай UTIL_UnsetGroupTrace, и ставь жертве pev->groupinfo = 0.
if (pev->groupinfo && FBitSet(pev->flags, FL_ONGROUND))
11
{
12
pev->groupinfo = 0;
13
UTIL_UnsetGroupTrace();
14
}
Должно работать. Если я не ошибся, по умолчанию всегда GROUP_OP_AND, и pev->groupinfo всех энтить нулевые. Но, важно, чтобы groupinfo были ненулевые. Работает это со всеми энтитями, включая игроков. То есть можно отключить коллизию с тиммейтами, при том, что они смогут друг друга подстрелить.
Добавлено 09-12-2021 в 22:09:
Я сейчас сам попробую разные варианты. Тоже хочу, чтобы барнакл разваливался на куски.
Ku2zoff Вроде понял, в UTIL_SetGroupTrace в первую колонку идет номер группы, а во вторую тип коллизии, GROUP_OP_NAND или GROUP_OP_AND .
А вообще, обязательно ли изменять жертву? Просто это еще думать надо куда этот код всунуть еще, чтобы он точно вызвался, жертва ведь может быть кем угодно, и игрок и НПС-ы, это метод надо искать что у всех всегда вызывается.
В Теории достаточно снарядам выставить к примеру при спавне
pev->groupinfo с номером (как я понял любое число кроме 0) и UTIL_SetGroupTrace(this->entindex(), GROUP_OP_NAND);, это по идее должно предотвратить их коллиззию с друг другом и в тоже время оставить коллизию с монстрами? Допустим если я хочу сделать энергодробовик, и хочу быть уверенным что снаряды с собой не сколидят при выстреле.
С кусками тоже придумать надо, надо чтобы они вообще ни с чем кроме геометрии не колидили, можно хоть на клиенте сделать, но они вроде как будут сквозь брашевые энтити вроде лифтов и дверей проходить, тоже не хорошо. Плюс у меня есть еще куски что к стенам липнут, как их портануть на клиент и еще заставить колидить с брашевыми энтитями и чтобы они двигались тоже с дверями и прочим.
Chyvachok я тут покумекал. Короче, с барнаклом решается всё просто:
C++ Source Code:
1
if (HasMemory(bits_MEMORY_KILLED))
2
{
3
if (ShouldGibMonster(iGib))
4
CallGibMonster();
5
return;
6
}
7
8
Remember(bits_MEMORY_KILLED);
В самое начало функции CBarnacle :: Killed.
C++ Source Code:
if (ShouldGibMonster(iGib))
{
CallGibMonster();
return;
}
Туда же после закомментированной строки // CGib::SpawnRandomGibs( pev, 4, 1 );
C++ Source Code:
if (pev->solid == SOLID_NOT) pev->solid = SOLID_SLIDEBOX;
if (pev->takedamage == DAMAGE_NO) pev->takedamage = DAMAGE_AIM;
В самое начало функции CBarnacle :: WaitTillDead.
За 0.1 секунды, что проходят между Killed и WaitTillDead жертва успевает упасть. А там уже солидность и урон возвращаются. Может быть на высоких фпс или при низкой гравитации жертва не будет успевать выпасть, надо проверять.
Добавлено 09-12-2021 в 22:59:
Гибсы (человеческие, что выплёвываются в момент смерти) могут немного подзастрять в барнакле, но это некритично. Можно написать новую функцию, CBarnacle::SpawnRandomGibs, которая будет спавнить куски чуть ниже, чтобы они не застревали.
Кстати, а как сделать спрайт на клиенте который через ТриАпи рисуется чтобы на него влиял свет? Сделал себе следы крови за кусками, которые на Авроре сделаны, но на партикли не влияет свет, для плазмы какой нибуть или огня ракеты норм, но для дыма и кровяки надо напильником подпилить эту систему.
Дядя Миша а какие ключевые слова отвечают за освещение? CONTENT_SPOTLIGHT или m_iLightingModel?
Добавлено 09-12-2021 в 20:01:
Еще вот, в КсашХТ в triangleapi.h есть в void ( *LightAtPoint)( float *pos, float *value ); но ее нету в обычном ХЛСДК, оно будет работать в халве, если скопипастить? Там еще есть штуки что есть в КсашХТ но нету в обычной Халве.
Chyvachok писал: Еще вот, в КсашХТ в triangleapi.h есть в void ( *LightAtPoint)( float *pos, float *value ); но ее нету в обычном ХЛСДК, оно будет работать в халве, если скопипастить?
Тут жалуется на *=, пишет error C2676: binary '*=' : 'Vector' does not define this operator or a conversion to a type acceptable to the predefined operator
Да и честно я так и не придумал, как из вектора мне получит цвет в виде float.
Дядя Миша писал: FL_WORLDBRUSH - это хинт-подсказка, что по такому брашу можно смело ходить, чтоб монстры не тупили. В то время как монстерклип вертикальный и по нему обычно никто не ходит. Так что да, убирай смело.
Вследствие этого появилась другая проблема. Теперь монстры с Monsterclip не осознают, что не могут дойти до ноды, и постоянно перестраивают путь в FGetNodeRoute. Надо как-нибудь для связей выставлять флаг, что она недоступна для монстров с Monsterclip.
Там где рисуется партикля в ParticleSystem::DrawParticle всунул
Vector lightColor;
gEngfuncs.pTriAPI->LightAtPoint( origin, (float *)&lightColor );
И после вывод в консоль чтобы посмотреть что оно выдает, которая выводит lightColor.x, lightColor.y, lightColor.z по x и z всегда ноль, по y какое-то рандомное в зависимости от уровня число которое не зависит от освещенности никак.
Добавлено 09-12-2021 в 20:54:
В общем проблема с LightAtPoint, оно выдает вообще непонятные числа, то минусовые, то гиганские там 9946234623 такого вида, и по одной координате.
Ku2zoff кстати модешь подсказать как быть с освещением у партикли? Хочу сделать чтобы свет влиял на партиклю, но никак не могу сообразить как эту LightAtPoint использовать, она выдает странный результат. Потом как заставлю ее работать нормально завести еще одну опцию в текстовый файл авроры которая бы переключала бы, влияет свет на партиклю или нет.
Вот если что сам код рисования партикли, из Спирита или Паранои, не помню точно:
code:
void ParticleSystem::DrawParticle(particle *part, vec3_t &right, vec3_t &up)
{
// gEngfuncs.Con_Printf("DrawParticle: size %f, pos %f %f %f\n", part->size, part->origin[0], part->origin[1], part->origin[2]);
float fSize = part->m_fSize;
vec3_t point1,point2,point3,point4;
vec3_t origin = part->origin;
// nothing to draw?
if (fSize == 0)
return;
float fCosSize = CosLookup(part->m_fAngle)*fSize;
float fSinSize = SinLookup(part->m_fAngle)*fSize;
// calculate the four corners of the sprite
VectorMA (origin, fSinSize, up, point1);
VectorMA (point1, -fCosSize, right, point1);
VectorMA (origin, fCosSize, up, point2);
VectorMA (point2, fSinSize, right, point2);
VectorMA (origin, -fSinSize, up, point3);
VectorMA (point3, fCosSize, right, point3);
VectorMA (origin, -fCosSize, up, point4);
VectorMA (point4, -fSinSize, right, point4);
struct model_s * pModel;
int iContents = 0;
for (particle *pDraw = part; pDraw; pDraw = pDraw->m_pOverlay)
{
if (pDraw->pType->m_hSprite == 0)
continue;
if (pDraw->pType->m_iDrawCond)
{
if (iContents == 0)
iContents = gEngfuncs.PM_PointContents(origin, NULL);
if (iContents != pDraw->pType->m_iDrawCond)
continue;
}
pModel = (struct model_s *)gEngfuncs.GetSpritePointer( pDraw->pType->m_hSprite );
// if we've reached the end of the sprite's frames, loop back
while (pDraw->frame > pModel->numframes)
pDraw->frame -= pModel->numframes;
while (pDraw->frame < 0)
pDraw->frame += pModel->numframes;
if ( !gEngfuncs.pTriAPI->SpriteTexture( pModel, int(pDraw->frame) ))
continue;
gEngfuncs.pTriAPI->RenderMode(pDraw->pType->m_iRenderMode);
gEngfuncs.pTriAPI->Color4f( pDraw->m_fRed, pDraw->m_fGreen, pDraw->m_fBlue, pDraw->m_fAlpha );
gEngfuncs.pTriAPI->Begin( TRI_QUADS );
gEngfuncs.pTriAPI->TexCoord2f (0, 0);
gEngfuncs.pTriAPI->Vertex3fv(point1);
gEngfuncs.pTriAPI->TexCoord2f (1, 0);
gEngfuncs.pTriAPI->Vertex3fv (point2);
gEngfuncs.pTriAPI->TexCoord2f (1, 1);
gEngfuncs.pTriAPI->Vertex3fv (point3);
gEngfuncs.pTriAPI->TexCoord2f (0, 1);
gEngfuncs.pTriAPI->Vertex3fv (point4);
gEngfuncs.pTriAPI->End();
}
}
Crystallize писал: может такие вещи оформлять отдельными сниппетами-темами в туторах
Этим надо кому-то заняться и прошерстить за пару месяцев все темы по нубским вопросам, туторам, ксашу. Вообще всю ветку Half-Life SDK и частично Наши проекты. Долго это.
Цитата:
Chyvachok писал: Тут жалуется на *=, пишет error C2676: binary '*=' : 'Vector' does not define this operator or a conversion to a type acceptable to the predefined operator
Да и честно я так и не придумал, как из вектора мне получит цвет в виде float.
C++ Source Code:
lightColor = lightColor * (1.0f / 255.0f);
У класса Vector в халфе нету нужных операторов +=, -=, *=, /= для работы с флоатами. Если очень надо, можно стащить из ReGameDLL:
Ku2zoff тут даже не в *= дело - сам LightAtPoint не работает.
Добавлено 09-12-2021 в 22:21:
Он вместо освещенности в диапазоне 1-255 выдает некое число которое зависит от того куда смотрит игрок. pDraw->origin это ж позиция партикли? Хотя я пробовал и part->origin и что только можно. ХЗ почему в КсашХТ оно работает а тут нет.
| IP: 
09-12-2021 15:09
