Malandrinus

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

Stalker_AleX333, По этому вопросу могу только предложить перепроектировать все окна с использованием текстур большего размера. Для этого придётся везде, где только можно, использовать атрибут тега текстуры stretch="1", чтобы вписать их в размер окна. Тогда эти текстуры при увеличении будут ближе к своему естественному размеру. Ну а как ещё улучшить порчу при апскейлинге? Ты упомянул правки движка. Интересно, какие такие правки движка могут исправить порчу растрового изображения при апскейлинге?

Stalker_AleX333, Создаёшь дополнительный файл xml с описанием окна с добавкой к имени "_16". В этом файле настраиваешь все размеры под широкоформатный монитор. Движок сам выберет нужный файл в зависимости от текущего разрешения экрана.

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

Если уж вы собираетесь переделывать все локации, то тогда и надо поступать так, как делают разработчики игр: делать локации под сюжет. Это значит, что сначала пишется сюжет, из сюжета становится ясно, какие локации нужны и что на них должно быть.А здесь, как я погляжу, сюжетом даже не пахнет пока, а вы уже показываете какие-то скрины.

В ЧН/ЗП папки имеют приоритет для поиска игровых архивов движком в точности, как задано в файле fsgame.ltx. Этот файл святой коровой не является, и ничто не мешает завести свой каталог "my_super_mod", зарегистрировать его в конце fsgame.ltx, чтобы архивы из него читались последними и размещать там файлы своего мода.

Artos, при чтении параметра функцией r_bool, true вернётся при любом значении из набора: "true", "yes", "on", "1". Соответственно, false при всех остальных значениях.

Daemonion, Первое. Движок на самом деле не может играть стереозвук по-настоящему. Файлы с именами "_l" и "_r" читаются только в отдельных случаях: музыка в меню, саундтрек уровня, видеоролики. Однако, даже в этом случае движок лишь имитирует стерео, играя звук из точек слева и справа от актора. Таким образом, каналы в любом случае смешиваются. Это можно заметить, если сделать каналы существенно различными, к примеру взять для музыки меню две совершенно разные мелодии. Второе. Чтобы звуковая схема в sr_sound2d.script играла стереозвук надо в секции логики для этой схемы поставить параметр stereo = 1. Тогда только и будут читаться файлы обоих каналов. Третье. Звуковая схема в sr_sound2d.script пытается имитировать стереозвук таким же образом, как это делается для музыки в главном меню и видеороликов, но почему-то делает это не совсем так, возможно просто ошибочно. Для проигрывания стереозвука там делается так: self.snd_obj_l:play_at_pos (actor, pos_l, d / 1000.0, sound_object.s3d) self.snd_obj_r:play_at_pos (actor, pos_r, d / 1000.0, sound_object.s3d) В то время как сам движок использует sound_object.s2d В итоге оба канала практически неразличимо смешиваются. Чтобы имитировать движковое поведение более точно и уменьшить смешивание надо сделать следующее: 1. Эти две строки в функции action_sound2d:play_sounds заменить на self.snd_obj_l:play_at_pos (actor, vector():set(-0.5,0.0,0.3), d / 1000.0, sound_object.s2d) self.snd_obj_r:play_at_pos (actor, vector():set( 0.5,0.0,0.3), d / 1000.0, sound_object.s2d) 2. В функции action_sound2d:update убрать фрагмент if self.st.stereo == true then .... end Если этого не сделать, то звук будет сразу обрываться. После этих изменений и добавления параметра stereo = 1 звук будет играться практически также, как в главном меню. Как я говорил, определённое смешивание каналов будет присутствовать всё равно.

Проще всего получать все указанные выше данные из клиентского объекта, используя возможности x-ray extensions.

AndreySol, внешне всё нормально, должна быть лампочка. Как координаты задавал? Откуда их взял?

AndreySol, Откуда же мне знать, что у тебя не работает. Пример давай. У копируемого объекта визуал есть? У источников света иногда нет визуала, как у костров к примеру. В этом случае и не увидишь ничего.

AndreySol, на столе у Сидора стоит лампа. У неё одновременно есть визуал и она светит. Типичный источник света состоит собственно из источника света + ореола (тот самый glow) и обычно дополнительных светящихся поверхностей на отключаемой косточке (светящееся стекло и лучи света). Свет и ореол - это специальные внутренние объекты движка, точные названия сейчас не помню. Включение соответственно означает активацию света, ореола и включение видимости кости с лучами и стеклом. Положение и направление источника света, если он ориентированный, обычно привязывается к некой кости, которая прописана в параметрах секции спавна. Если визуала нет, то тогда источник тупо светит из координат объекта. Объект источника света можно заспавнить скриптом в любом случае, но если не прописать ему визуал в секции или в all.spawn, то он и будет просто источником света. Если прописать визуал, то такой объект будет и физику поддерживать. Собственно, класс так и называется CHangingLamp, поскольку на нём можно сделать подвесной светильник: пара сочленений и фиксированная кость позволяют сделать такую лампу. Есть ещё один класс CProjector, который можно использовать в таком же смысле, но без поддержки физики. Зато его направлением можно управлять скриптово. В принципе, обычной лампой тоже можно, но для этого придётся писать скриптовую обвязку как для дверей, а для прожектора есть готовые команды.

Artos, измерения я проводил года четыре назад. С тех пор сменилось несколько поколений компьютеров, и мне сейчас физически не воспроизвести те условия. В то время слайдшоу на ТЧ у меня начиналось при средненьких параметрах динамики и разрешении 1024х768. Сейчас я даже на ЧН/ЗП не могу обеспечить просадку FPS до заметно низких значений ни на каком разрешении экрана при самых выкрученных настройках. Или может имело значение, что тогда у меня был однопроцессорный компьютер. Я не знаю точно, чтобы узнать, надо лезть в движок и разбираться, как синхронизируются отрисовка кадров, такты просчёта физики и обновления игровой логики. Тем не менее тогда, несколько лет назад, я совершенно достоверно получал разницу между частотой апдейтов и FPS рендера. Тогда же я измерял частоту fastcall и тоже получал, что она в несколько раз выше частоты апдейтов. Тогда это для меня вполне объяснило название этого колбека и вообще необходимость в нём. Он действительно работал быстрее, чем просто апдейт. Что касается того, что fastcall и add_call связаны с физикой движка. Это можно понять по внутренним названиям функций и классов.

Artos, обновления актора если и связаны с FPS рендера, то опосредованно, и уж точно их частота не одинаковая. Это совершенно точно. Более того, рендер и все его дела, в том числе и обновления с независимой частотой, как раз происходят в отдельном потоке Windows. Это в сущности единственный многопоточный момент в движке - отдельный поток для рендера. Что же касается апдейтов актора и их связи с частотой апдейтов level.add_call. Я давно не занимался этими измерениями, но смутно помню, что частота апдейтов актора может быть равна или меньше частоте вызовов от level.add_call. Вроде как на старом компьютере и под патчем 1.0004 апдейты шли медленней, а сейчас (весьма быстрая машина и 1.0006) вроде как равны. Кроме того, частота апдейтов актора вообще говоря подчиняется общему правилу для апдейтов всех объектов, т.е. чем дальше от актора, тем медленней. Соответственно актор и его инвентарь обновляются с одной и той же, максимальной, частотой. И более определённо я могу сказать насчёт природы вызовов level.add_call и также колбека fastcall. Они вызываются с одинаковой частотой и, насколько я знаю, эта частота просчёта игровой физики. Есть основания думать, что оба этих вызова исходно предназначались для скриптовой обвязки управления физическими объектами.

proger_Dencheek, не может найти костюм. Пишет же в логе "obj (a nil value)"

Залил недостающие файлы.

Clayman, я имел в виду не геймпоинты глобального графа. Их можно добавлять только в SDK. Я имел в виду, что есть такой тип игровых объектов, cse_alife_graph_point. Я могу только предположить, что объекты этого класса имеют отношение к этому параметру в левелченджере.

Callisto, Clayman, при скриптовом спавне этот параметр вроде как и не требуется. Там есть несколько параметров, которые исчерпывающе определяют точку перехода: dest_game_vertex_id, dest_level_vertex_id, dest_position, dest_direction, dest_level_name graph_point - есть такой специальный объект. Возможно, здесь подразумевается его использование, хотя я не уверен и сам никогда с такими объектами дела не имел.

Igor88.89, Справедливости ради замечу, что описание вполне соответствует балансу чистой игры. Так что вряд ли можно объяснить отсутствие искомых фич неким глубоким замыслом. Скорее, создатели не предполагали, что народ будет играть в игру в стиле фриплея, даже проходя основной сюжет =) SGV, для начала имеет смысл как минимум задействовать перепаковщики пачек патронов, что несколько снижает остроту проблемы. Затем, приложить усилия по выправлению баланса. К сожалению, изменения движка в части окошек/кнопочек по ряду причин крайне муторное дело. Теоретически можно, но лично я бы раньше балансом занялся, нежели такой фичей.

Artos, Я отреагировал на фрагмент кода, который неправилен вне зависимости от контекста. Неважно, как, где и когда создавался объект. Ставить в одном фрагменте выведение в онлайн и после этого получение клиентского - неправильно в любом случае. Впрочем, косяков там хватает и без этого. Судя по всему, главный косяк я пропустил. Как ты верно заметил: С большой вероятностью это и есть причина проблемы. Т.е. попросту лампочка на другом уровне. Я однако замечу, что использование имени в основном стало глупой затеей благодаря модостроителям, которые пихают объекты в аллспавн копипастой. Ещё замечу, что это может вызывать проблемы достаточно серьёзного плана. Вот у нас недавно выловили проблему с объектами костров. Наличие на одной локации двух костров с одинаковым именем вызывало вылет. Однако, вылет происходил не сразу, а при переходе на другую локацию, после определённое времени нахождении на проблемной локации. И в логе ничего вменяемого не было. Из-за такого эзотерического характера вылета первое подозрение было, что заканчиваются некие ресурсы. Только долгие и мучительные эксперименты позволили установить истинного виновника.

AndreySol, А при чём здесь создание? В одном фрагменте стоит инициирование выхода в онлайн (функцией set_switch_online) и дальнейшее получение онлайнового, что как раз и есть неправильно. Да, кстати, цитатами слабо пользоваться? Совершенно непонятно, кому отвечаешь и на какой вопрос. Artos, Ну почему не может? А вдруг объект на другом уровне?

AndreySol, Сразу после инициирования выхода в онлайн онлайнового объекта ещё нет, надо ждать несколько апдейтов. Это же основы, такие вещи надо знать.

Artos, в том-то и дело, что сам ~finalize срабатывал, однако вылетало при удалении окна, вызванном из него. При этом, удаление из иного места в том случае работало нормально. Впрочем, тогда системы так и не выяснил, посему достоверность информации неполная. Я могу предположить, что проблема с ~finalizeв том, что это метод, вызываемый при работе сборщика мусора, а для глобальных объектов типа актора сборщик срабатывает не во время игры, а где-то между завершением и загрузкой. Насколько в этот момент можно заниматься оконными операциями и вообще чем-то, сказать сложно. С этой точки зрения никакой иной объект не имеет особенных преимуществ перед ~finalize биндера актора, поскольку все они окончательно удаляются в одно и тоже время.

Добавлю от себя к дискуссии по окнам. Я лично столкнулся с определённой проблемой, которая заключается в том, что не всегда удаётся определить родительское окно для данного. Точнее, не всегда удаётся его сохранить. Поскольку штатных методов для определения родительского окна нет, то его приходится хранить от момента прикрепления к нему дочернего до отсоединения. Уже не помню подробностей, но в ряде случаев по так и не выясненным причинам ссылку на родительское окно не удавалось сохранить. Доходило до совсем уж мистических вещей, а а итоге всё заканчивалось вылетом или лишним неудаляемым окном при следующей перезагрузке. Помучившись, я пришёл к тому, что добавил в класс окна метод DetachFromParent, который позволяет скрипту не знать родительское окно при операции отсоединения. Также могу сказать, что есть не один вариант решения задачи с добавлением элементов на движковые диалоги. Варианты различаются: в какой момент добавлять, в какой момент удалять, в какой момент создавать и физически удалять добавляемое окно. Можно попытаться создать добавляемое окно один раз и до конца игры. Вопрос, когда именно делать то и другое. Вопрос с созданием в сущности не так и важен, это можно попросту сделать при первом использовании, используя функцию в таком стиле: local added_wnd local function get_my_wnd() added_wnd = added_wnd or create_my_wnd() end потом надо везде получать это окно только с помощью этой функции, и проблем не будет. Однако вопрос с удалением уже не так тривиален. К какому из событий игры привязаться, чтобы оно произошло с гарантией? На самом деле, есть куча сценариев, когда ни один из вариантов не является в полной мере надёжным. На мой взгляд метод биндера актора ~finalaze - самый подходящий, поскольку срабатывает при любом штатном сценарии завершения игры. Одна только проблема, иногда удалением в нём по невыясненным причинам даёт сбой. Другой вариант, если присоединяемое окно - не банальный статик, а окно на основе скриптового класса, то можно попытаться отсоединить его в его же собственном методе ~finalize. Надо только убедиться, что он вызывается, а для этого надо ненароком не сохранить ссылку на себя в этом окне, чтобы сработал уборщик мусора. Другой вариант - создавать добавляемое окно всякий раз при присоединении и удалять при отсоединении. Этот вариант ничем не хуже остальных. Никакой нагрузки на ресурсы здесь нет, поскольку создание в данном случае - разовая и с точки зрения игры весьма редкая операция. Может даже оказаться, что это более надёжный и менее запутанный вариант, поскольку все начальные и завершающие действия с окном делаются в одном месте (т.е. создали и присоединили, а потом отсоединили и там же удалили). Если окно создаётся один раз, то в этом случае вопрос с моментом присоединения тоже на самом деле неоднозначный. Как и в случае с физическим созданием я могу решить присоединить один раз и до конца игры. Всегда ли это срабатывает, уже не помню. А можно присоединять при открытии диалога и отсоединять при закрытии. В этом случае, как и для создания, важно, чтобы открытие/закрытие всегда срабатывало парой. Вот с этим тоже есть проблема. Опять же не помню подробностей, но для какого-то из движковых диалогов извещение об открытии/закрытии срабатывает нестабильно, поэтому насколько это подходящий вариант надо решать по ситуации.

amik, Это электра необъяснима? Как по мне, так самая объяснимая аномалия. Копится статическое электичество, потом разряжается. Неужели гравитационные аномалии выглядят более правдоподобно? Или та же жарка, вот что там в ней горит?