Malandrinus

steelrat, шестизарядник - это дробовик? У меня нормально стрелял. Кроме общеизвестного бага 5/6 патронов ничего больше не замечал. Только поначалу доставало, что для полной зарядки надо постоянно нажимать R, одного раза недостаточно (ещё одна дурость из той-же оперы, что и "быстро нажимайте E").

AK74, Ограничений на количество объектов быть не должно, кроме общего ограничения в 65535 объектов. По сравнению со стандартной секцией физического объекта не вижу поля object_flags. Вообще, откуда взят шаблон для секции? Что за версия acdc?

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

sapsan, странно, у меня эта же проверка стабильно выдаёт nil. Но если есть статик, то можно попытаться проверить видимость или положение окна, связанного с ним.

В диалогах можно завести тег action. Вписываешь туда свою функцию и делаешь там что надо. Можно и счётчик завести. 1. Уточнить бы вопрос. Надет прицел на текущем оружии или оружие в состоянии прицеливания? Если установленность прицела, то в ТЧ это только через нетпакеты. Начиная с ЧН есть вроде функция у ствола weapon_is_scope 2. Для манипуляции элементами худа можно использовать консольные команды (через get_console():execute()): hud_crosshair on/off hud_crosshair_dist on/off hud_info on/off hud_weapon on/off и функции: level.hide_indicators() level.show_indicators() Что из этого заменяет +/- уже не помню.

mikelik, Я вообще-то пытался ответить на твой вопрос. Должна быть либо ссылка на кого-то в логике рестриктора, либо ссылка на рестриктор в чужой логике. Если бы ты привёл пример такого рестриктора, то я просто вбил бы его в поиске по всем файлам игры, и тогда быть может точно сказал, где и как он используется, а не приводил пространные рассуждения =)

mikelik, Может быть запросто мусор. Этого добра в ТЧ хватает с избытком. Сам по себе рестриктор объект очень простой: у него есть некий объём, заданный набором примитивных шейпов, и функция, которая позволяет узнать, находится какоё-либо объект в пределах этого объёма. Больше ничего, даже апдейты для рестриктора не вызываются. Используется он в двух вариантах. Либо вписывается в качестве ограничения на вход/выход конкретному неписю либо работает как триггер. Но и в том и другом случае он должен быть куда-то явно вписан. Особенно в качестве триггера, поскольку у ресртиктора нет своего апдейта, то он "паразитирует" на апдейте актора. Естественно, это устанавливается специальной логикой. Т.е. если рестриктор не содержит логики и сам нигде не упомянут ни в чужой логике ни в коде - значит это почти наверняка мусор.

С одной стороны, в движке существенных изменений нет. Все базовые функции, конфиги и т.д. остались по большей части без изменений. Т.е. скорее всего ничего не мешает добавить в all.spawn сталкера и скорее всего он создастся. С другой стороны, сейчас там на самом деле нет ни одного живого существа (кроме актора=). Все сталкеры, в том числе и квестовые, прописаны в сквадах. Сквадов в all.spawn в свою очередь тоже нет. Похоже, что создание сквадов теперь завязано на скриптовую логику. Но я в этом не большой спец, так что с уверенностью сказать этого не могу.

Darien, В ТЧ даже через нетпакет бы не вышло, а в ЗП у серверного объекта есть свойство angle, с типом vector. И не нужно никаких извратов с нетпакетами.

Kolmogor, Метода у меня появилась как побочный результат моих изысканий. Я выяснил природу функций level.set_call и захотелось применить на практике. Интересно, кстати, что природа этих функций та же, что и fastcall-ов. И, как мне кажется, они ставят колбек на шаг решателя физики. Это вероятно для более точного управления физическими объектами, но можно использовать для организации независимых от апдейта актора периодических событий. Вот здесь на этом сделан сторожевой таймер, что на мой взгляд удобнее, чем делать это на апдейтах монстров.

Проверь, на месте ли колбеки на обучающие сообщения в файле _g.script. Их имена: on_actor_critical_power on_actor_critical_max_power on_actor_bleeding on_actor_satiety on_actor_radiation on_actor_psy on_actor_cant_walk_weight on_actor_weapon_jammed Может какого-то нет или там что-то не в порядке.

Заборол ложный писк при паузе игры. В функции function watch_condition() надо заменить if db.actor and then на if db.actor and not device():is_paused() then Кроме того, имеет смысл ставить порог счётчика не пять, а 10 (см. ниже). Похоже, что период апдейта зависит от: - типа рендера - общей производительности компьютера - производительности видеокарты (может даже больше, чем от процессора) Также похоже, что частота апдейта и fastcall-ов могут не совпадать на слабых конфигурациях. От патча это не зависит. Я перепроверил. На моём текущем компьютере период совпадает на всех патчах. А первые эксперименты по замеру тайминга я делал на другом компьютере и отчётливо помню, что на четвертом патче период был чётко 40 мс, а fastcall шёл раза в 2-3 быстрее. В общем, стабильности никакой. Рассчитывать на какие-то постоянные цифры нельзя. Ну и значит алгоритм проверки имеет смысл оставить так, как есть сейчас (со счётчиком) и не упрощать. P.S.: можно и не предотвращать ложный писк. Его наличие показывает, что механизм жив. Но скорее всего скоро надоесть слушать =)

Хм. Писк не должен прекращаться, если уж начался (исключая переходов между уровнями) Попробуй, если не влом, увеличить порог счётчика с 5-и до скажем 20-и. У меня есть подозрение, что частота апдейтов и соотношение с частотой fastcall-а связано с производительностью.

Shadowman, Полагаю не больше, чем пара строк примитивного кода в том же апдейте. Учитывая, сколько там в апдейте уже напихано, это будет капля в море. Да, всё так. На самом деле при том, что сторожевой таймер работает синхронно с апдейтом, вообще нет необходимости в счётчике. Достаточно просто сравнить. Я ввёл счётчик потому, что был уверен, что апдейт актора идёт с частотой 40 мс, т.е. раза в два-три медленнее, чем fastcall. Но оказалось, что это не так. Число 5 взято с потолка. В расчёте на ситуацию с несинхронной работой апдейта и сторожевого таймера этого хватило бы с запасом, и начало срабатывания будет практически сразу (через 1-2 десятых секунды). почти неотличимо одинаково, я измерил.Но мне так больше нравится =) Добавлено через 114 мин.: sapsan, По ЧУ у меня одни вопросы. Реализация там откровенно мутноватая. Но вот это самый большой вопрос. Я хотел бы ещё раз уточнить, что именно мне не нравится. Там в течении двух игровых минут непрерывно запускается звук сирены. Это означает, что он начинает играть с каждым очередным апдейтом. Это в свою очередь должно означать, что за минуту будет запущено несколько тысяч звуков. Столько звуков одновременно слышать невозможно, и они превратились бы в простой шум. Однако, насколько я понял, есть некий лимит на количество одновременно играющих звуков и этот лимит довольно быстро исчерпывается. В итоге от начала проигрывания первого звука до исчерпания очереди проходит что-то в районе секунды или меньше. Далее мы слышим все эти звуки (которые влезли в лимит) одновременно. Поскольку они смещены по фазе не очень сильно, то сирена всё-таки различима, хоть и весьма искажена. Это так задумано? На мой погляд - как-то это неправильно. Так было сделано изначально и этого я не менял. Можно обратится в тему озвучки за помощью. Думаю там "организуют" нормальную сирену и обратный отсчет. Но проблемы с сохранением во время начала ЧУ я больше подозреваю в начальном "пугании" неписей. Пока не могу заняться ЧУ... sapsan

magnit, Если только мне пришлют два упомянутых файлы и номер версии солянки и под какой патч. У меня к сожалению всё в полуразобранном состоянии, и я это настраивал не под солянкой. Shadowman, Я это стал делать тогда, когда словил несколько вылетов подряд. Тогда просто поставил вывод в биндер и понял, что он останавливается, что само по себе вылет объясняло, но непонятно было в какой момент начинается подвисание. Тогда и сделал сигнализацию. Если писк начнётся после определённого действия - взятия/сдачи квеста, убийства монстра и т.п., то хотя бы станет ясно, где копать. Дальше надо ставить отладочный вывод на это место и ловить вылет ещё раз, но уже с подробной трассировкой проблемного места. Как-то так.

Смастерил сигнализацию на предмет зависания биндера актора. Нашёлся способ организовать альтернативное периодическое выполнение функции и за счёт этого поставить сторожевой таймер. При зависании биндера по идее должен сразу раздаться непрерывный противный писк. [spoiler=в файле _g.script] counter = 0 prev_watch = 0 function watch_condition() counter = (bind_stalker.watch_value == prev_watch) and (counter + 1) or 0 prev_watch = bind_stalker.watch_value if counter > 5 then if db.actor then local snd_obj = xr_sound.get_safe_sound_object("detectors\\da-2_beep1") snd_obj:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 2.5) end end return false end function dummy_action() return false end function start_game_callback() level.add_call(watch_condition, dummy_action) --- ... end [spoiler=в файле bind_stalker.script] watch_value = 0 function actor_binder:update(delta) watch_value = game.time() ... Вот только протестировать не удалось. Промучился с несколькими зависаниями подряд, а как только настроил сигнализацию - не смог словить ни одного. Наверное оно меня испугалось =) В общем, если есть желание - потестируйте плиз методу. При переходе на другой уровень раздаётся писк. Это происходит потому, что апдейты в этот момент останавливаются, а вызовы ловушки почему-то продолжают работать. Вероятно, возможны и другие ситуации ложного срабатывания, но если идёт нормальная игра и пошёл писк, то это однозначно должно означать подвисание.

Это странно. Я отчётливо помню, что экспериментировал именно с ТЧ на кордоне и тайминг апдейтов был железно стабильный: у актора 40 мс, у остальных больше, в зависимости от расстояния. Не приснилось же мне это!

Обнаружил поистине странную вещь. Патч 1.0006. Апдейты идут не с периодом 40 мс, а существенно быстрее. Если точнее, идут синхронно с fastcall-ами, что соответствует сильно меняющемуся периоду 10-25 мс. Запустил ЗП - там как и положено 40 мс. Я без понятия, чем это может быть вызвано. Хотелось бы прояснить, это так только у меня или у всех. Если не сложно, сделайте кто-нибудь простую проверку. Надо вставить в апдейт актора одну строчку и посмотреть в консоли, что идёт в вывод. Только обязательно скажите, какой патч. Мне бы собрать информацию по патчам 1.0004 - 1.0006 файл bind_stalker.script в функции actor_binder:update: function actor_binder:update(delta) object_binder.update(self, delta) get_console():execute(""..delta) -- <<== вставить вот такую строку

AK74, Масса складывается из отдельных масс частей физической оболочки, которые прописаны в визуале и задаются в SDK. Сдаётся мне, что этот параметр просто игнорируется. Я видел ещё такой ph_mass, но он тоже не влияет. Это эскейп-последовательности, которые означают соответственно "перевод строки" и "одиночный бэкслеш". Всё здесь нормально.

Сдаётся мне с Яндекс Диском какие-то проблемы. Я два раза скачал оттуда файл (довольно стабильно и на хорошей скорости), это был до байта один и тот же файл, но при этом битый. С сендспейса скачался без проблем. Может стоит удалить это зеркало? Судя по всему не у меня одного такие проблемы были. Всё-таки 150 Мб перекачивать - это для многих не так уж мало (а я в итоге скачал его три раза, т.е. почти полгига).

grey_wolf, всё там, и текстуры и видео. Ты как ищешь? Моими плагинами для TC воспользовался?

Ирбис, 1. Скриптами. Например, после использования аптечки отнять все аптечки, после 10 секунд отдать обратно. Может и ещё как-то можно. 2. Редактировать соответствующую текстуру. 3. Никакой. Скриптами 4. Смотри, как это сделано в огнемёте АМК 5. Смотри как это сделано в АМК

grey_wolf, рекомендую использовать плагины для Total Commander. Ссылки в моей подписи. Сможешь спокойно зайти в архивы и искать там с помощью встроенного поисковика тотала. Хотя вроде как все видео, что ты ищешь, находятся в папке textures\ui\.

Arhara, А как может точка пути находиться вне сетки? Ведь один из параметров каждой точки - вертекс уровня. Или я чего не понял?

Overlord, Затраты на производство игры с открытым миром существенно больше. И технических проблем поболее будет, что на примере Сталкера было хорошо видно. Разрабы в своих интервью надували щёки, что типа у них SDK более продвинутый и благодаря этому они и сделали игру вовремя. Но на мой взгляд основных проблем, что были при разработке Сталкера, они и не встретили, и SDK тут не при чём. Они отказались от сетевого движка (и правильно сделали, в Сталкере надо было поступить так же), нет здесь больших локаций, нет множества персонажей, нет симуляции и даже тактический AI довольно посредственный, нет большого числа физических объектов и вообще объектов мало. Есть неплохой графический движок, замечательный дизайн (хотя опять же дырки в дизайне умело прикрыли, прогоняя игрока по уровню галопом, толком и осмотреться то не дают). Есть хороший сюжет и сеттинг, основанный на популярной книге. Что ещё забыл? И что имеем в сухом остатке? Рядовой шутер с упором на дизайн. Хватит ли команде пороху на что-то более масштабное? Посмотрим..