Scrama писал: Смысл в добавлении in_out событий всем триггерам, если не ошибаюсь.
И к чему это привело? К неработающим триггерам и вылетам. На мой взгляд достаточно одного trigger_inout. Если же всё-таки переписывать всю систему, то нужны дополнительные поля для всех триггеров, активирующих или изменяющих что-либо. Например, trigger_gravity изменяет гравитацию на входе и восстанавливает на выходе. Но этого сделано не было, появилось только новое поле у trigger_multiple, то есть по сути он заменил собой trigger_inout. Но тут же начались проблемы с Delay before reset и т.п.
Если и создавать подобную систему триггеров, то нужно разделить их на категории:
1). Одноразовые, public CTriggerOnce (которые в принципе не имеют повторной активации, или она бессмысленна, например trigger_once, trigger_endsection и т.п.), у которых есть только функция Touch(срабатывают один раз и кирдык).
2). Многоразовые public CTriggerInOut (trigger_gravity, trigger_inout, короче что-то что определяет условия внутри некоторой зоны, они могут быть активированы несколько раз, имеют функции FireOnEntry и FireOnLeave, т.е. когда нужно могут работать как при входе, так и при выходе из них).
3). Многоразовые триггеры с задержкой перед сдедующим срабатыванием public CTriggerMultiple(trigger_multiple, trigger_hurt, когда задержка заканчивается они снова активируют цель, имеют только Touch).
Смешивание категорий 2 и 3 в спирите 1.7 привело к нехорошим последствиям, в частности, неправильной работе trigger_multiple, а также вылетам связанным с работой zone_register. Предложенный мной вариант я считаю оптимальным, т.е. функции срабатывания(Touch, FireOnEntry, FireOnLeave) мы декларируем не в классе CBaseTrigger, во избежание того, что произошло в спирите 1.7, а делаем достоянием подклассов, для которых собственно и нужны эти функции, чтобы не было путаницы, какую функцию триггеру использовать.
З.Ы. Если кто-то будет за поддержку этого вырианта, то я постараюсь написать такую систему на основе системы триггеров из SoHL: CB1.7 и SoHL: CB1.6 Если же нет, то будет старая система из версии 1.6.
Ku2zoff писал: На мой взгляд достаточно одного trigger_inout.
Согласен.
trigger_endsection вообще вещь суть тупая. Я бы сделал ее точечной и нафиг убил бы распознавание текстового параметра типа "_oem_end_logo". Как бред же выглядит.
Вообще volume-триггеров достаточно двух - multiple и inout, но с кучей полей. Т.е. надо расширить существующие, остальные взять из SDK2.3 и убрать из fgd или закомментить, чтоб глаза не мозолили.
Всякие hurt'ы и gravity можно реализовать как поля с допустимым нулевым значением.
Еще вот мысль. Я вчера по дороге домой обдумывал систему адресации для Спирита. Надо дописать функцию UseTargets, чтоб она парсила строки вида Target.Parameter=Value, например есть у тебя ентитя с именем MyPretty и значением поля speed 300, есть триггер, в котором в поле target записана конструкция MyPretty.speed=600, и включение триггера будет у этой ентити не Use дергать, а просто устанавливать новое значение скорости. По идее сделать не сложно, а возможностей даст много. Просто представь себе multi_manager такой )
Ku2zoff писал: Ещё один вопрос назрел. Как вы относитесь к тому, что барнаклы дёрганно поднимают жертву(по моему 16 юнитов за один тчинк(точно не помню)). Стоит ли сделать это поднимание плавным? Или лучше сглаженными рывками как в хл2?
Лутше как в ХЛ2 - они ж поднимают жертву мышцами, а не єлектроподъёмником
Итак, я сделал промежуточную версию SoHL: RB1.5. Работает стабильно, по крайней мере можно пройти мод Unholy без вылетов и ошибок. И оригинальная хл вроде не лагает(просто не было времени проходить её целиком). Остался вопрос, куда залить архив.
Зря, ой зря вы это. Я со своим кастом-билдом старался не нарушать нумерацию версий, т.е. народ всегда знал, что 1.3 следует за 1.2.
А с вашими ревизиями теперь вообще хрен разберешься, тем более что они хаотичные. Ну и назвали бы Spirit 1.8 RB и Spirit 1.9 RB.
Дядя Миша, 1.8 основан на коде 1.2 и все последующие нововведения были выкинуты оттуда просто по причине, что Лори оказалось пофиг на русских друзей и их баги, кроме того за спирит с той стороны взялась куча народу, мешающего код с аррандж модом и прочим креативом, так что пытаться вникнуть в их текущую нумерацию, где куча всяких бет и альф, перебилдов и недокомпилов просто нереально. RB же отталкиваются от версии 1.7, образуя свою ветку и не пытаясь синхронизироваться с западными разработками. Можешь считать это отдельным тулкитом.
Scrama уголок авантюриста вполне подойдёт. Если народ путается в нумерациях версий, то когда я всё доделаю и будет RB2 тогда и назовём его SoHL: Revision Build 2.0 (Custom Build 1.8) В скобках надо будет писать кастом билд, чтоб люди понимали от какой версии он происходит.
Да в том-то и фишка, что просто в readme напишешь: базируется на версии SoHL Custom Build 1.7 by Дядя Миша, а нумерацию нужно своей оставлять - RB2.0 и все, иначе труба, все будут вычислять, какое отношение он имеет к спириту 1.8а.
В данной ситуации мне непонятно следующее - Лаури взял за основу свойже спирит 1.2, но продолжил нумерацию согласно принятой.
Т.е. он вполне мог назвать спирит 1.3 (без приставки CB) и это проканало.
Но товарищ легких путей не искал - во первых он накопипастил много кода из SoHL:CB 1.7, во вторых народ один фиг остался недоволен, поскольку в связи с этой инициативой они лишились кучи фишек спирита 1.7 и теперь умоляют Лаури прикрутить и их тоже, на что он гордо им заявляет - у меня нету времени.
Тут возникает вполне уместный вопрос - если спирит 1.8 такой глючный и в нем половины фишек из спирита 1.7, зачем же его юзать?
А я отвечу - его юзают те идиоты, на которых магическое влияние оказывает более старший номер версии. Именно по той же причине разные идиоты качают самую последнюю версию ZHLT, свято веря, что она гораздо лучше прошлой.
Но у нас-то ан форуме орудуют настоящие профессионалы (с), которые понимают, что хорошо не то, у чего версия выше, а то, что сделано лучше.
Лично мое мнение: переименовать нашу ветку спирита во что-то типа Extended. Тогда Half-life Extended будет звучать как Расширенный Half-life, чем по сути и является. А все эти духи и запахи навевают ассоциации с шаманизмом, бубном и камланиями, от которых мы как раз и пытаемся уйти, сосредоточившись сейчас на исправлении багов, а не добавлении новых хитрых систем и фишек.
| IP: 
06-03-2009 04:57
