Open 0x4E69676874466F78 opened 6 months ago
For this to work a lot more is needed:
Animated|WithChangingEmissive
and Switchable|WithChangingEmissive
.func_wall
can be switched (based on targetname
logic above).Вроде бы что-то на эту тему уже было сделано базовое, но не помню что.
Вроде бы что-то на эту тему уже было сделано базовое, но не помню что.
ЕМНИП: мы там ходили по цепочкам текстур и выясняли, одинаковые ли они там, или нет. И, вроде, большую часть не-анимируемых-анимированных текстур сумели-таки привести к статике. Но остались случаи, когда там потенциально разные кадры в цепочке есть, но в реальности стейт-машина игры их никогда достичь не может. И по мотивам как раз этого случая данная ишья и была создана. И ей именно в этом варианте мы не занимались.
У нас существует проблема что все
func_wall
с +0/+A текстурами надо добавлять каждый кадр что даёт какие-то штрафы по производительности. Мы могли бы проанализировать список энитити на наличие связиfunc_wall
с любыми другими энтитями, для этого надо проверять что вот конкретнаяfunc_wall
имеет ключtargetname
и значение этого ключа (имя) используется какой-то другой энтитей, обычно целевое имя у ссылашющихся энтитей лежит в ключеtarget
, но для страховки можно перебрать все ключи (хотя это может давать ложные срабатывания).targetname
нигде упомянут то эта статическая модель.targetname
уfunc_wall
вообще не указан или пустой, то искать ничего не нужно и это статическая модель гарантировано (безопасно можем сразу добавить такое поведение).Теоретически 1 вариант может сломать какие-то моды которые прямо из кода в обход энтитей перелючают
func_wall
, поэтому стоит оставить квар исключающий этот первый вариант. 2 вариант сломать ничего не должен (99,999%), но при желании тоже можно добавить квар (или сделать режим в рамках одного квара, типа значения 1, 2).