RayTwitty

Тут я подразумевал, что команду можно использовать не только как передачу железно между актором и собеседником, но и например между другими НПС. Конечно, такие случаи редки, но мало ли... Если упрощать, то можно ввести одну команду "to" принимающую два значения - ГГ или собеседник. to10 = actor|second_talker -- кому? transfer_item10 = vodka.5, antibodun.10

@Zander_driver, надо бы стандартизировать названия команд - при разнобое могут быть ошибки во время написания: give_item\lost_item\has_item\donthas_item, give_info\lost_info\has_info\donthas_info, give_money\lost_money\has_money\donthas_money и т.п. Еще можно ввести команды transfer_item и transfer_money для передачи между ГГ и НПС. Например from10 = actor to10 = sidor transfer_item10 = vodka.5, antibodun.10 Имхо, но тоже нужно заменить на полные аналоги (action и precondition), дабы визуально не сливалось с другими командами. Исключительно для удобства.

Не буду писать про то, насколько наглядно или нет выглядит данная система по сравнению xml-ветками - это субъективное мнение, но вот новые команды распространенных действий добавить бы не помешало - has/give/lost_item и т.п.

Штатных функций для проигрывания без онлайного объекта в сталке нет, но можно попытаться через дополнительные библиотеки для луа запустить какой-нибудь mp3-трек прямо в плеере фоном. Помнится в каком-то билде, амбиент-музыка на локацях именно так и была реализована))

@vampirnik77, ну тогда используй скриптовый аналог))

@Zander_driver, а причем тут ? Я построчное чтение файла предлагал вообще-то. Проще поставить xray-ex и заюзать трассировку лучей RayPick.

Так просто наверно не получить. Я думаю, надо пропарсить system.ltx и все его вложения, найти все строки, которые обозначают секцию (по заданному шаблону), после чего, найденную секцию на всякий случай проверить при помощи section_exist, ну и добавить её в табличку. Далее, пройтись по этой табличке и посмотреть наличие нужного параметра в секциях. Правда, для чтения файла наверно понадобятся расширения RvP (io namespace).

Ранее говорилось про перебор объектов, я же написал про перебор _секций_. Секций всегда будет меньше, следовательно меньше нагрузка + их нельзя изменять\добавлять без перезагрузки игры. Ну проверишь в начале уровня, дальше что? Если какой-нибудь новый объект в игре появится, снова проверка? На апдейте будешь делать?))

Ещё такой вариант - перебрать вообще все секции и посмотреть у них параметры биндинга, ну и потом проверить наличие всего необходимого. Другими словами, отладка ещё до выхода объектов в онлайн.

@UnLoaded, не у всех объектов, выходящих в онлайн, должен быть биндер. Без чтения конфига не обойтись.

По хорошему, на бы в самом движке перед созданием биндера проверять, а существует ли такой файл\функция вообще. Но если движок не вариант, значит на выходе в онлайн читаем секцию у объекта, в этой секции читаем параметр script_binding, разбиваем строку на [файл].[функция], далее известными способами проверяем наличие и вылетам если чего-то не хватает. В случае если всё окей, добавляем секцию в табличку "проверенных секций", чтобы несколько раз не сканировать одно и тоже.

У меня двиг ТЧ 1.0007 за 10-11 минут с отключенной оптимизацией компилится на i5 3570 3.4GHz.

@Outlaw, автор наверняка не в курсе, что такое "Уровень 12". Дал бы линки на статьи какие-нибудь...

Визуальные свистоперделки, которые не имеют практического смысла. А вот компиляция за две минуты, допустим, ui или ai-классов, которые занимают добрую часть xrGame и часто правятся - почему нет?..

@BlooderDen, если нужно настроить худ оружия и не хочется сильно заморачиваться, можешь скачать ЛА - там полноценно работают все режимы + есть настройка позиции и ориентации. Формат с ТЧ вроде одинаковый, так что можно уже готовые настройки перетаскивать в нужный мод. @DDamian724, https://xp-dev.com/sc/204486/HEAD/

Если используешь ХЕ, там есть метод получения текущего стейта худа оружия: uint<state> get_hud_item_state() - возвращает номер текущего стейта. пример: local weapon_states = { idle = 0, fire = 1, fire2 = 2, reload = 3, showing = 4, hiding = 5, hidden = 6, misfire = 7, mag_empty = 8, switch = 9 } local state = db.actor:active_item():get_hud_item_state() if state == weapon_states.reload then ... end

Очевидно, слетели матрицы трансформации. Попробуй перекомпилить спавн. Важно, чтобы в исходных моделях, стекла были с правильным материалом и шейдером. Ставишь меш, компилишь спавн - туда пишутся координаты и размеры прямоугольника. Если не боишься, можешь распаковать спавн и самостоятельно задать параметры новой лестницы, но это будет долго и нудно

Интуитивно понятных там только несколько, остальные имеют специфические значения и действия. Плюс, никто не отменял подводные камни, которых тоже хватает.

Да, перепутал)) Не группирует, если различие больше 0.01.

Полное описание есть в движке)) На самом деле, давно есть идеи описать все параметры и атрибуты UI-классов, там есть довольно интересные вещи. А на счет complex_mode - именно он включает форматирование строк. Причем, это не только перенос, но и работа других спецсимволов, например раскраска части текста (см. статик веса в инвентаре). В скриптах задается методом SetTextComplexMode(bool) (в ЗП и в ТЧ+ХЕ).

В сталкере юзердаты так нельзя сравнивать. Не уверен, что именно это тебе нужно, но попробуй нечто вроде tostring(CUIStatic) == tostring(CUIStatic).

Двиг не группирует предметы с различием состояния менее 0.01, т.е. если изменишь его на 0.0099 то ничего не выйдет. Просто для справки.

@dsh, насколько я помню, прыжок находится в CActorCondition - это другой класс и для него есть отдельный хак. Попробуй db.actor:set_actor_condition_float(nil, value, 276)

Так вроде давно же перенесли все правки (или почти все) в сырцы ._.

Там все ссылки на паки умерли... Перезалил: http://rusfolder.com/43744644 В одном архиве всё.