Malandrinus

есть такая фича! Находишь файл в архиве. Далее контекстное меню -> свойства. Будет список архивов, в которых есть такой файл. При распаковке естественно берётся наиболее приоритетный. Если надо вытащить старую версию, то нужен архиваторный плагин. см. в моей подписи.

lex017, проблема в квиксейве. Не пользуйся ими. квиксейвы портят сохранения. Неприятность в том, что последствия видны не сразу. Поэтому иногда приходится переигрывать с очень ранней сохранёнки. Не хочешь проблем - забудь, что есть квиксейв

Пытался вытащить скриптами иконку неписей. В итоге разобрался, как работает система профайлов, но задачу так и не решил. Хитрая система:

Phantom1305, что из сказанного можно: модель или партиклы?

TREWKO, для начала, volume - это вроде не функция, а свойство. так что snd_obj.volume = ... (работает или нет не проверял). Далее, зачем тебе несколько функций установки громкости? Зачем вообще паковать в функцию действие из всего одной однотипной строки?

кровоSTALKER, Есть тег code. Его использование + форматирование кода - это элементарное уважение к людям на форуме. Это не считая того, что аккуратное форматирование - на самом деле серьёзное средство выявления ошибок, типа лишних или недостающих end-ов. function have_tema_eda2() return sak.have_item_namber("bread",20) or sak.have_item_namber("konserva",10) end

Phantom1305, Ну так может и партиклы к ним есть, только поискать. Хотя не факт, что найдёшь. Модель сможет отзеркалить любой новичок, сумевший открыть макс или майку, а с партиклами это сложнее. Но может и есть, хотя нафига - не понятно. Ну ведь не видно же справа ни затвора ни гильз!

xStrangerx, Labus, как раз убрать не проблема. Надо закомментить или убрать параметр shell_particles в конфиге ствола. А вот поменять сложнее. Надо переделывать соответствующий партикл. Но опять же, а смысл? Ведь затвор со стороны актора, а делать его с другой - его попросту будет не видно.

Да, это так. Есть и другой момент. Вот только что лазал по файлам сталкера, там в диалогах на Агропроме неиспользованная ветка про Крысолова. Мелочь, но занимательно. А таких вырезанных мелочей и не очень мелочей в сталкере масса: диалоги, звуки, анимации, партиклы, текстуры, монстры и машины и даже целые локации. Это была беда для игры, но счастье для модостроителей. Здесь такого не будет, поскольку игру делали так, как собственно и надо делать: в срок, по плану, делая то, что надо и не больше. Не будет ни материала для модостроителей, ни той особой мифообразующей основы, когда не без оснований веришь в то, что "там ещё есть что-то, что можно раскопать". З.Ы.: я разумеется ни в коем случае не хочу сказать, что игра плохая

Комрады, такой вопрос. Нет ли у кого простой тестовой локации? Я имею в виду нечто очень простое, типа пол,4 стены, без объектов и с all.spawn в придачу, чтобы актор там появлялся при старте игры. Смысл в том, чтобы игра стартовала минимальное время. Просто при экспериментах со скриптами приходится часто перезапускать игру, а загрузка любой игровой локации занимает значительное время. Такая простая локация сэкономила бы кучу времени.

А я себе настроил телепорт на метр вперёд. Очень удобно и можно ходить через стены. Что то вроде такого вешаешь на главное меню: db.actor:set_actor_position(db.actor:position():mad(device():cam_dir, 1))

Monnoroch, Можно сделать проверку как-либо стандартно оформленной, чтобы потом убирать все проверки автоматизированно, к примеру регулярными выражениями. Правда при этом возникает отладочная сборка, которая требует дополнительной поддержки. Насчёт проверок - это вообще тема бездонная, о которой пишут толстые книги

Класс такой есть vector. Объект такого класса возвращается методом :position(). Математически это три числа, представляющие проекции некоего направленного отрезка. log не работает. printf по идее можно перенаправить в файловый вывод. Под ТЧ наиболее удобным способом является вывод в консоль игры. Можно смотреть результат прямо в игре и остаётся лог на диске. get_console():execute("текст для вывода") Я это подробно излагал здесь нет, ну можно же и так: вектор - это тензор первого ранга. Кому от этого стало бы легче?

TREWKO, Как можно вообще что-то делать, проверяя только по конечному результату? Отлаживать надо. Ставь отладочные выводы в консоль. Проверяй тип объектов, значения. Проверяй, что вообще та или иная ветка алгоритма работает. Это за тебя никто не сделает.

TREWKO, вот ведь меня переклинило-то! distance_to вообще нет у game_object, а есть у vector. Правильно так: z:position():distance_to(db.actor:position())

TREWKO, у тебя obj - это строка. distance_to надо вызывать для z

Ray, если тебе нужна аналогия из С++, то это будет нет так: for (int i=1; i <=10; i++) { int y = 0; ... } а вот так: for (int i=1; i <=10; i++) { int *y = new int(0); ... } Ну и что? Просто новый кадр стека при очередной итерации попал в точности на место старого. Так уж вышло из-за того, что старый кусок стека был в точности того же размера, что и новый. Добавлено через 3 мин.: Ray, нет, в этот раз fun инстанцирована всего один раз

sapsan, то, что локальные переменные живут в стеке из документации понять можно. Загляни в часть, где описывается интерфейс с СИ. Хотя это и так довольно очевидно. Локальные переменные в стеке - это настолько очевидная идея, что делать на этом акцент никому даже в голову не придёт, разве что на особенностях реализации. Вот например здесь стек реализован свой, а не используется процессорный. Что они точно удаляются там конечно не пишут, поскольку это самоочевидно. Ты представляешь себе, что такое стек? Как может там остаться значение, когда мы его освободили? Я пытался донести мысль, что есть переменные и есть значения. Переменные типа не имеют, живут в стеке и представляют собой ссылки. Значения имеют тип (и не могут его менять) и живут в динамической памяти. Сборщик мусора удаляет значения. Это согласуется с цитатой, поскольку говорится об объектах, не переменных. Нигде нет утверждения, что сборщиком мусора удаляются переменные. Конечно, в документации нет такого уж акцента на этом разделении, поскольку это в сущности детали реализации. Опять же многословность не помогает новичкам в освоении нового языка. по примеру. на каждой итерации: (1) создаётся ссылка на y (в стеке) + значение "0" (в динамической памяти) (2) создаётся (инстанцируется) новая функция (в динамической памяти), внутри функции идёт ссылка на значение "0" (3) освобождается стек тела цикла, ссылка из (1) теряется, но значение остаётся, поскольку на него есть ссылка из функции, а сама функция остаётся потому, что на неё есть ссылка из массива всё это повторяется 10 раз: десять разных стеков, 10 дубликатов функций, 10 дубликатов значения "0" Все ссылки на значение x естественно ссылаются на одно и то же значение "20"

sapsan, это не так. Рассмотрим простой пример: local b = 1 -- (1) do local a = {1,2,3} -- (2) local b -- (3) ... b = 2 -- (4) end -- (5) print(b) -- (6) В этом примере есть блок, который ограничивает область существования переменной a. Теперь по порядку: в точке (2) происходит создание двух сущностей: локальной переменной a и таблицы {1,2,3}. В этой же строке в переменную a пишется ссылка на эту таблицу (переменная инициализируется таблицей). Таблица создаётся в динамической памяти и за её удаление отвечает сборщик мусора, а переменная a создаётся в стеке блока и существует до конца этого блока. Поскольку стек по выходу из блока освобождается, то переменная a прекращает своё существование в точке (5). Именно в этой точке, не раньше и не позже. И память освобождается в этот же момент. И это не имеет вообще никакого отношения к сборщику мусора. Ещё пример. Переменная b, которая создаётся в точке (3), не инициализируется ничем, а значит принимает значение по умолчанию nil. И она опять же живёт в стеке, а значит существует до конца блока. То, что она существует и никто её не удаляет подтверждает простой эксперимент. В точке (4) я пишу в переменную b значение. Если бы b удалялась, то я бы писал в переменную, объявленную в строке (1), но если проверить, то в строке (6) выводится по прежнему значение 1, а не 2. Т.е. я писал в b из строки (3), которая всё ещё существует, но в точке (5) удаляется и вместо ней становится видна b из строки (1).

sapsan, всё же сборщик мусора освобождает только память под значения переменных. Если переменные (т.е. ссылки) локальные, то они хранятся в стеке функции и без всякого сборщика мусора погибают вместе с завершением функции (точнее своего блока). Как раз факт гибели ссылки и может запустить сборщик мусора, если на значение больше нет ссылок. Кроме того, для переменных типа userdata всё не так просто как для скажем таблиц или строк. Таблицы и строки создаются самим Lua, им же и удаляются (с помощью сборщика мусора). А userdata как выясняется бывают двух типов full userdata и light userdata. Разницу видно со стороны хост-программы. Со стороны скрипта заметить сложно. full userdata - это такой объект, память для которого выделяет Lua, соответственно и освобождает он же с помощью сборщика мусора. light userdata - это в чистом виде указатели на объекты, созданные вне Lua. Для Lua - это просто указатель, о природе которого он ничего не знает, и никакого удаления он естественно не делает. Как созданием так и удалением в этом случае занимается хост-программа. Я попробовал выяснить и получилось, что вроде как все объекты userdata - это full userdata, поскольку они имеют метатаблицу и в ней поле __gc, что указывает на собираемость этого объекта сборщиком мусора. С другой стороны, это ничего не значит, поскольку для экспорта классов здесь используется технология Luabind, где походу для всех реальных объектов создаются дополнительно обёртки, и объекты userdata, которые мы наблюдаем - это не внутренние объекты, а эти Luabind-овые временные объекты. Они и впрямь собираются сборщиком мусора, но что происходит при этом с "настоящими" объектами не вполне ясно. Это в данном случае зависит от Luabind. Там есть соответствующая настройка при экспорте класса. Естественно, что именно включено при экспорте конкретного класса - не известно. Остаётся полагаться на здравый смысл и известное поведение: vector и прочее в этом роде создаётся из Lua и собирается сборщиком мусора, когда не нужен. game_object и серверные объекты создаются вне Lua и соответственно их удаление явно (alife():release()) или неявно (выход в оффлайн) выполняется в движке. Не вполне понятно, как себя ведут объекты типа звуков и партиклов. К примеру particles_object. Вроде создаётся из скрипта наподобие того же vector. Но потом можно запустить его играть и забыть о нём. Вот не помню, надо ли хранить ссылку на объект в этом случае. Если не надо, то кто тогда займется его удалением? И когда?

Нет там ничего подобного. Предмет не создаётся заново, а ему меняется состояние. Кстати, это означает, что в момент вызова death_manager, т.е. фактически в колбеке на смерть непися, предмет ещё в инвентаре. В оригинальной игре вообще нет почти ни одного вызова drop_item для неписей. В паре мест встречается, но всё это какие-то специальные квестовые ситуации и то, вроде как не задействованы. Опять же, предмет исправно выпадает из рук непися, у которого биндер не прописан вовсе, т.е. привязка к скриптам отсутствует, и поведение определяется исключительно движком. Значит, дроп активного предмета - фича движковая, и искать почему иногда не срабатывает - смысла нет. Оно так, но речь то шла о том, чтобы это сделать незаметно с целью временного включения регдолла =)

Monnoroch, Сначала по второму вопросу со стволами. Ствол в руке - это результат работы метода game_object.set_item(...) или связки объект object и entity_action + метод game_object.command(...). Полагаю, движок тоже может устанавливать предмет в руках, но в итоге где-то внутри вызывается одна и та-же функция. Предмет само-собой должен быть в инвентаре непися. При смерти непися предмет выкидывается, но я так и не нашёл где именно. Похоже это движковое действие, хотя может плохо искал. Но скорее всего движковое, поскольку объект выпадает из рук непися даже если у него вообще никакого биндера нет, и соответственно с ним не связаны никакие скрипты. Если предмет остался в руках, значит он скорее всего остался в инвентаре и просто продолжается действие метода game_object.set_item(...) (проверить бы). Если бы это было скриптовое действие, то можно было бы предположить, что это следствие подвисания биндера, а так - без понятия почему иногда предмет не выкидывается. По воскрешению. Ни разу мне не удалось воскресить дохлого непися. Я видел функцию, где переписывается нетпакетом здоровье, но у меня она ни разу не сработала. Был либо вылет, либо просто никакого эффекта. Для меня сейчас смерть выглядит как некий внутренний флажок, который устанавливается движком и к которому нет доступа скриптами. Самому хотелось бы этот вопрос прояснить. Если у кого-то есть сейв с дохляком, которого точно можно воскресить, был бы премного благодарен. Опять же с практической точки зрения для мгновенного перевода непися из регдолла обратно "к жизни" такой метод всяко бы не сгодился, поскольку манипуляции с нетпакетом подразумевают предварительный перевод в оффлайн. С другой стороны необратимость смерти выглядит логичной со всех сторон в том числе и с точки зрения смены способа анимации. Подумай сам. Ну вот допустим можно сменить на короткое время анимацию на регдолл и обратно. Скажем, я хочу пнуть непися взрывом, а он упадёт, а потом встанет. Это крайне сложно технически реализовать при современных возможностях. Вот непись стоит в определённом положении, я отключаю анимацию, включаю физику, даю хит. На самом деле это уже не совсем натурально, поскольку не дохлый человек даже падая ведёт себя не как кукла. Но допустим. Вот упал. Совершенно в произвольном положении, заметь. Теперь надо решить как минимум две задачи: первое - определить момент, когда можно переключаться обратно, второе - реализовать вставание, что подразумевает плавную и естественную анимацию из совершенно произвольного положения с учётом весьма произвольного профиля поверхности к одному из "стандартных" вариантов. Конечно, нет ничего невозможного, но в сталкере такого не реализовано.

Юра Семецкий, по второму вопросу ответ однозначно нет. Когда объект живой, он под управлением анимации, и тогда на него физика не действует. Когда умирает - включается регдолл анимация (т.е. собственно физика) и отключаются анимации обычные. Либо так - либо этак, но никак вместе. Да и если подумать, как это можно вообще совместить?

Unnamed Black Wolf, не совсем понятно, можно подробнее насчёт полётов в падении?

Увы, синтаксически это корректно. В случаях, когда бэкслэш комбинируется с символом и это не означает специального действия, получается эскейп-последовательность, означающая "сам символ". Это фактически означает, что бэкслэш просто игнорируется. "A\MK" == "AMK" Добавлено через 13 мин.: Что-то вы, товарищи, маетесь кое-чем. Строки "actors\\hero\\stalker_novice" и [[actors\hero\stalker_novice]] равны. Неужели я так путано написал? Длинные строки - это не ещё один строковый тип, а способ задания строковых литералов или иными словами строковых значений. Когда мы значение запишем в строку, это будет по-любому просто последовательность символов, такая же строка, как любая другая.