dsh

@aromatizer,это меняет положение самого фонарика, как устройства, но не источника света относительно этого устройства. Куда бы я фонарик не поместил, источник света находится позади него и левее. При увеличенном угле пучка света видна тень ГГ.

Может ткнешь пальцем в конкретный файл? А еще лучше, в строки. Беглым взглядом - не нашел. О, кстати, по поводу фонарика. Я обратил внимание, что свет из него идет из точки за головой актора и немного левее, т.ч. видна тень головы в некоторых случаях. Отчего это зависит? Где настраивается точка, из которой бкдет идти свет? Или в x-ray extensions, когда включали тень ГГ, фонарик тоже как-то задели?

Именно так. Убирать не обязательно. Наличие этого параметра, с таким значением, просто ничего не меняет.

Разброс не увеличивается. Это очередной "городской" миф. Движок эти параметры обрезает снизу до 0 и сверху до 1.

Напомните пожалуйста. При получении хита ГГ спотыкается. Это где-нибудь настраивается? Хит радиоактивный, маленький, сотые доли.

Народ, кто скачал торрент файл с официального форума, опубликуйте его, пожалуйста, здесь. А то там без регистрации не скачивается.

@Romann, что бы не городить таблицы и использовать конфиги, см. пост 7341.

@Helgi, воспринимай это так, что через bones_koeff_protection ты указываешь класс бронежилета. А за подробностями смотри damages.ltx. Там настраивается эта, так сказать, бронезащита. Неписи костюмы не используют, поэтому у них этот параметр может быть прямо в модели указан или в конфиге, ссылка на который указана в модели.

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

Как минимум не нужно делать так, а нужно делать if not quest_npc[obj:section_name()] Это первое, что в глаза бросается. А вообще, что-то я не въезжаю, а зачем перебираются все объекты игрового мира? Что это вообще делает-то? Мутный какой-то скрипт.

Ой, какая большая таблица. Я бы посоветовал, для определения квестового персонажа, в первую очередь проверять наличие story_id, и только потом, если его нету, смотреть в таблицу. Это позволит уменьшить эту таблицу, если не избавиться от нее совсем. Всё-таки, наличие story_id с большой вероятностью будет означать, что этот персонаж квестовый. Обратное не верно.

Чисто гипотетически, на мой взгляд, это даже не так надо делать, а как-то вроде if get_bool( wpsec, script_name() .. ".ignore" ) then return end Ну и в секции оружия добавить ts_mod_soc.ignore = true Но что бы это стало работать не гипотетически, нужна хорошая скриптовая основа, где и get_bool() есть и много других хороших плюшек.

Ты ведь какая штука. И ты о ней упоминал. Один создал табличку с двумя элементами. А второй, потом, или вообще десятый, запихает в эту табличку еще сотню. Ну потому, что он не скриптер и т.д. Просто есть вещи, которые не понимающему человеку не нужно делать никогда. Лучше таким людям делать шаблонно и не задумываться, будет это быстрее вон того варианта, при двух элементах в таблице, или не будет. Тем более, что таких мыслей и не возникнет.

Народ, ну вот кто, кто вас учит так делать? for k, v in pairs(ex_sects) do if v == wpsec then return end end Так делать не надо ни-ког-да. Надо делать вот так if ex_sects[ wpsec ] then return end А в ex_sects естественно надо добавлять вот так local ex_sects = { [ "wpn_ognemet" ] = true, } И я, естественно, не стиль имею ввиду.

Сильно подозреваю, что это была очепятка. Лишняя была либо первая 7, либо последняя 8.

Хм странно. 777888 упорно не переваривает. Мгновенный вылет при запуске игры. Достаточно убрать одну цифру и игра запускается. Ну и фиг бы с ним.

А в story_ids могут быть значения больше 65535? Что-то мне сдается, что atoi() такое не переварит. Ну и у себя я немедленный вылет на старте получаю.

Не, ну я не знаю, что там у тебя раньше было-то. Может предыдущий скрипт, ltx в цикле каждый раз заново читал или еще что-нибудь подобное. Я вижу только то, что есть сейчас, а в нем ничего ускорительного не нахожу. Вот и пишу, может у меня взгляд замылился и я чего-то в упор не замечаю. Ты словами и конкретными строками поясни, в чем именно ускорение? И это я не просто что-бы поспорить, а что бы понять. Вообще, насколько я себе представляю кухню npc:add_sound(). Да, сделано не красиво с точки зрения искусства. В непися загружаются все звуки, в том числе и те, которые он использовать не будет. Типа речей Сахарова или что там еще есть. Но что происходит внутри? Выходит в онлайн первый непись. В него загружается все. А на самом деле, загружаются звуки в некоторый, назовем его так, кэш. А в непися грузится табличка с id этих звуков. Далее выходит в онлайн второй непись. В него загружаются все звуки опять. Но так как они уже загружены в тот "кэш" первым неписем, то самой загрузки уже не происходит, а во второго непися загружается только табличка с id звуков. И так далее для каждого следующего. Что тут можно ускорить? Даже если убрать загрузку всех звуков в непися и оставить только те, которые он может использовать, это ускорит процесс только на время однократного чтения тех, лишних, звуков. Стоит-ли оно того? А может у меня неверное представление и все происходит совсем по другому?

Ну вот, собственно. Самая лучшая оптимизация - это разгребание этих самых звуков, как ты и писал про конюшни.

Две минуты. 40 секунд. Во первых, это же зависит от кол-ва загружаемого, да? А во вторых, насколько я вижу, основное время тратиться в npc:add_sound() и что-то я не вижу никакого способа это ускорить. Ведь ему нельзя передать уже загруженный звук. Да и не имеет это смысла. Насколько я вижу в исходниках, он сам звуки кэширует и не загружает с диска уже загруженный звук. Что касается скрипта, так у меня, к примеру, он не дал никакого ускорения. Как было около 14 секунд на звуки при холодном старте, и примерно 4 при повторной загрузке сейва (в Баре), так и осталось. Мне собственно не понятно даже, а как там что-то может ускоряться. Насколько я вижу, по сути, скрипт кэширует результаты check_prefix() и чтение ltx-а. Ни первое, ни второе кэшировать нет смысла. Первое - это string.sub() и второе такое же движковое. Миллисекунды максимум. Совершенно не в обиду сказано. Может я чего не заметил? Тогда ткните меня носом, где именно там ускорение должно происходить?

Не ты первый ТАК сильно ошибаешься. Настолько не первый, что я уже устал повторять. Эти, как ты их называешь, поделки, я делаю для себя и только. А все остальные хотят играют, хотят - не играют. Я только оказываю тех. поддержку и помогаю советом.

@phorumer, да. Это собственно и взято из скрипта Нанобота. Но код я что-то не узнаю. Не мой стиль. Наверное кто-то другой делал по подобию. У меня в подписи ссылка на репозиторий. Там, в том-же скрипте, немного по другому сделано, в фунции configure_rpm().

@phorumer, существует. Поищи в какой-то оружейной теме скрипт для Абакана от Нанобота, там как раз это делается. Если не найдешь, я позже покажу этот момент.

@Zander_driver, мне кажется, полезно будет сделать snd_ini = system_ini() вместо snd_ini = ini_file("misc\\script_sound.ltx") В самом script_sound.ltx добавить определенный префикс ко всем секциям. Я использую "script_sound.". Конечно не забыть этот ltx за-include-ить в системные конфиги. А в самом скрипте добавить этот префикс везде, где используются имена секций. Какой смысла загружать script_sound.ltx при загрузке каждого сейва, если это можно сделать один раз, при первом запуске игры. Это, на мой взгляд, полезно сделать вообще для всех таких конфигов, типа death_generic, treasure_manager и т.п.

Не так это страшно. Когда снимаем/одеваем оптику оружие тоже исчезает и возвращается. @gameshark, так, как на скринах, просто настрой прицеливание через железный прицел, что бы было, как на первом скрине. И включи съемный оптический прицел. Тогда будет и второй скрин, при подключенной оптике. Самый простой вариант.