Malandrinus

@DDamian724, the major issue, if I remember correctly, is that using the vanilla engine it is not possible to open the PDA window from a script. When using extensions, x-ray extensions for instance, it is possible but for the specific version of engine (SHOC 1.0006). The script itself shouldn't be very difficult to make: perform a periodical check of the current item and, depending on it, show the PDA window. The periodical check can be performed using update event in the actor's binder.

Вернусь к разговору насчёт визуального переключения режимов огня. Кто понимает в анимациях, объясните мне такой момент. Вот у меня есть скажем три режима огня, соответственно есть рычажок, который может находиться в трёх положениях. Но ведь получается, что надо иметь анимации, которые будут переходными от каждого состояния к каждому, т.е. 1-2, 1-3, 2-1, 2-3, 3-1, 3-2 итого шесть штук. Кто может прокомментировать? Я правильно понимаю ситуацию? Кто экспериментировал с анимациями? Для финального положения рычажка требуется отдельная анимация? Т.е. после окончания нециклической анимации кости сохраняют своё конечное положение или возвращаются в исходное до анимации?

, не вижу ни малейшего смысла тратить время на эту команду. Во-первых, самый главный аргумент против - а собственно куда телепортироваться то? Как выбирать точку перехода? Куда-то на нулевой вертекс? Невелик выбор. Во-вторых, а чем плохи скриптовые средства? Возьми хотя бы читовый телепорт из OGSE. Можно даже сохранять свои точки со скриншотами, да и использование ну просто для конкретных лентяев: горячей клавишей вызвать окно с выбором точек и потом красиво кликнуть мышой.

В игре есть читовый спавн, вызываемый из главного меню нажатием 'S'. Список того, что спавнится, находится в файле test_spawn.script Ещё, в игре есть тестовый полигон - файл personal_test.lua, который можно менять без перезагрузки игры и запускать. Переключаетесь по Alt-Tab в текстовый редактор, меняете скрипт в этом файле, выходите в меню и жмёте 'N' для выполнения изменённого скрипта.

Вот выкладываю некий предварительный скрипт для аддонов на комбинированных моделях. https://yadi.sk/d/YWR_7SrberWAf Пример слеплен на модели ВАЛа и пока только заточен под прицелы. Вкратце система секций такая: Для теста надо заспавнить себе ствол wpn_val_pso1 и прицелы wpn_addon_acog и wpn_addon_scope. Если так принцип организации секций непонятен, то позже выложу формальное описание.

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

@killersan6, да ясно, что не силой мысли. Какую схему переключения предлагаешь? Кнопки мыши все заняты.

@killersan6, допустим. Как предлагаешь этим управлять?

@killersan6, подразумевается смена всех трёх типов аддонов, поскольку разницы между ними практически нет - всё делается одной и той же подменой секции. В принципе возможны и ещё аддоны, типа магазинов и тактических рукояток. Гибридные - это что? У меня вопрос ко всем. Не прямо сейчас, но на будущее есть одна мысль. Насколько я понял, при включении зума сам худ зуммируется тоже. На мой взгляд, это неправильно. У худа есть своё приближение, в том смысле, что руки со стволом приближаются в режиме прицеливания, и на мой взгляд зум зуда уже совершенно лишний. В принципе, это можно убрать, задав для худа свой постоянный fov, можно даже настраиваемый отдельной консольной командой. Т.е. сцена будет наезжать в соответствии с настройкой зума из секции прицела, а худ - нет, точнее будет только смещаться, как для ironsight. Для прицелов с текстурой никакой разницы не заметим, поскольку там худ вообще скрывается, а вот для коллиматоров и прицелов на основе модели на мой взгляд должно смотреться более естественно. Что думаете? Ещё раз, это задумка на чуть позже.

Я сейчас не могу сказать больше. Займусь вопросом дополнительных фишек не раньше, чем закончу систему переключения аддонов.

Этот параметр отвечает за увеличение в режиме гранатомёта при пристёгнутом прицеле. Если прицела нет, то в режиме гранатомёта увеличение такое же, как и в обычном режиме. Короче, явно какая-то недоделка.

@TIGER_VLAD,Смотря зачем надо. На событие выдачи инфопорции в современных модах навешано куча кода (о котором даже и не знаешь), поэтому лучше избегать использования инфопорций, если в них нет реальной нужды. Нужда есть, если инфопорции используются по прямому назначению - для сюжетных целей, или если их выдаёт/забирает движок. Почти во всех остальных случаях можно заменить инфопорции обычными переменными, глобальными или локальными по ситуации. Собственно, если рассмотреть инфопорцию отстранённо, то это не что иное, как специфическая переменная с типом bool. Инфопорция однако - это сохраняемая переменная. Если нужно значение сохранять, то можно использовать системы хранения, коих уже немало (хотя бы АМК).

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

@kamikazze, да, но там довольно топорно сделано прямо через глобальный FOV, а хотелось бы, чтобы ствол этим управлял. Ну т.е. подменять то значение зума, что прописано в прицеле ствола. Понимаешь, тогда движок всё сделает сам: плавный наезд/отъезд и пр.

Хочу добавить немного информации по организации AI сетки на уровне формата файла. Думаю, что это может дать представление о принципиальных ограничениях.

@k01jan, речь насчёт дочерних костей шла только в одном смысле, нет резона делать организацию костей так: wpn_body wpn_scope wpn_scope1 scope2 ironsightА увеличительная насадка в виде дополнительной кости к одной из нестандартных костей прицела - это уже другая история. Ещё раз, я бы сейчас не хотел в это лезть, хотя принципиально это (скорее всего) возможно. Нужна будет циклическая анимация откинутого/примкнутого стекла и разумеется налаженное управление увеличением. По идее должно получиться. Но не прямо сейчас.

Единственное железное ограничение: стандартная кость должна быть и быть пустой (без поверхности). Т.е. выходит, что её использовать для одного из аддонов нельзя. Это связано с тем, что движок форсирует её видимость/невидимость. При этом никто не мешает использовать стандартные модели, если прицел всего один. Если ты имел в виду располагать дополнительные кости дочерними к стандартной, то это можно, хотя и нет особого смысла. Я рассматривал такой вариант, надеясь упростить себе жизнь и использовать движковое скрывание при снятии аддона в инвентаре, но вышло так, что сильно это не помогает. А с точки зрения модели вероятно более упорядоченно и проще располагать все аддоны от корпуса. Прикол в том, что для снимаемого прицела движок показывает вместо него текстуру этого прицела в режиме увеличения. Поэтому коллиматоры все делают не просто несъёмными, а вообще как интегрированный ironsight просто хитрой формы. Да, конфигом и скриптом с использованием хака. Всё по той же причине, у движка по умолчанию такой вариант не возможен и независимая настройка смещения худа для прицела отсутствует (он просто скрывается). Будет своя настройка, надо будет соответственно настраивать. Разумеется будет. Собственно, если ничего не прописывать, то планируется, что будет работать как обычно. Система конфигов ещё дорабатывается. Детали опишу позднее. Наверное это можно сделать, но это отдельная фишка. Сейчас только минимум того, что необходимо для работы системы в принципе. Думаю, ответ здесь в ключе предыдущего вопроса. Если будет контроль FOV, то можно будет и переключать его скриптом для конкретного ствола. Но не прямо сейчас.

Обновлённой? А она вообще есть? Помнится, на заре существования проекта я сделал пак, но потом отказался от этого по многим причинам, да и нет больше хостинга файлов на гуглкоде. Основная причина - сейчас, я думаю, нет такого человека, который знал бы весь проект целиком =) Усё пашет. А зачем? Там нужен не masm32, а ассемблер от студии. И даже если бы была portable версия, в неё не было бы никаких коммерческих утилит. А это по-любому делают все под себя.

@Mirage2000, Этим сейчас заниматься не буду, но вообще возможно. Переключение - это просто анимация. Для скриптового управления анимациями сейчас всё есть: проверка их наличия, проигрывание, проверка длительности. Также есть колбеки на нажатия клавиш и проверка режима бега/прицела и т.п. Так что визуальное переключение режимов стрельбы реализуется довольно просто: 1. добавляем анимацию к модели худа, имя прописываем в секцию худа 2. по колбеку на нажатие клавиши, связанной с командой переключения режима стрельбы, проверяем наличие оружия в руках, и отсутствие проигрывания других анимаций, запускаем анимацию переключения, блокируем ввод на время проигрывания. С раскачкой (во время ходьбы) всё сложнее. Если это сделать анимацией как для спринта, то собственно, а как стрелять? Ну т.е. как одновременно махать стволом и прицеливаться? Если актор в спринте и начинает стрелять, то переходит в режим бега (хода). Хотя проиграть анимацию при ходьбе (точнее беге, поскольку у всех и всегда включён "всегда бег" =) несложно по описанной выше схеме. Даже ещё проще, поскольку блокировка ввода не нужна. По идее там есть что-то, связанное с инерцией худа, которая вместе с эффектором камеры для раскачки при ходьбе (который боббинг) может дать нужный эффект. Я туда сильно не лазил, но может быть это задействовать или даже просто настроить должным образом. Кто-нибудь пытался играться с этими настройками?

За выходные физически не успел завершить систему аддонов, но вчерне всё работает. По результатам экспериментов самый удобный вариант схемы костей дополнительных аддонов получается такой (для случая прицелов. Для остальных аналогично, только имя стандартной кости другое): wpn_body wpn_scope <== кость аддона со стандартным именем и без поверхностей wpn_scope1 scope2 ironsightт.е. иными словами:1. кости нестандартных аддонов растут от корпуса ствола (нет необходимости делать их дочерними к стандартной кости) 2. стандартная кость ВСЕГДА присутствует и она пустая 3. на именование костей нестандартных прицелов не накладывается никаких ограничений Что ещё добавить к этому. Будет возможно делать съемные прицелы не текстурой, а моделью. В этом случае надо будет также настроить положение худа, которое в этом случае отличается от того, что прописано в секции худа. В общем, по указанной выше схеме можно уже начинать делать модели с анимациями. Скриптовя база будет в самое ближайшее время.

Тут непонятно. ООП или не ООП, а количество строк будет ровно тоже самое, т.е. в каждом нужном колбеке надо будет вызвать соответствующих метод класса / функцию из модуля. Кстати о птичках. Это как раз тот пример, где крайне уместно было бы применение системы событий. Вместо прописывания этих прямых вызовов, модуль погоды (или объект класса погодного менеджера) можно было бы подписать на соответствующие события. При этом собственно не потребовалось бы менять биндер вообще, так что и вопрос с простынёй бы не стоял. В OGSE так и сделано.

Я тут совсем не понял тебя. Что за "простыня" тебе не нравится? Судя по всему, ты противопоставляешь менеджер, сделанный на уровне модуля, такому же, сделанному в виде объекта класса. Я правильно понял? Или не нравится что-то другое?

Ну нет, твои правки - ты и документируй. Включить тебя в проект?

Скрипты здесь вообще ни при чём. Во-первых, нужна была правка косяка рендера, из-за которой на чистом ТЧ неправильно рисуются шейдеры прямого освещения. Дело в том, что худ рисуется в своей очереди да ещё и со своим FOV. ПЫСы схалтурили, и поверхности прямого освещения вне зависимости от принадлежности к худу попадали в глобальную очередь. С соответствующей правкой такие шейдеры на худе стали возможны, а это в том числе шейдеры самосвечения и полупрозрачных стёкол. Дальше можно делать более или менее сложные вещи уже без правок движка (за одним небольшим исключением). Например, сейчас можно разместить светящиеся маркеры на мушке/целике (типа люминесцентные или тритиевые). Для этого нужны поверхности со стандартными шейдерами самосвечения. Далее, можно сделать неподвижный светящийся маркер на стекле. Это не совсем натурально, но уже близко к коллиматору. Для этого стандартный шейдер самосвечения не годится. Сейчас не помню, но там были проблемы с одновременным включением прозрачности отложенного освещения (как на колючей проволоке или листьях) и самосвечения. По моему было что-то вроде того, что эффект свечения применяется ко всей поверхности без учёта дырок. Короче, для метки на стекле уже нужен шейдер специальный, где яркость метки задаётся вне зависимости от внешнего освещения + есть прозрачность. Если нужно, чтобы было как у взаправдашнего коллиматора, т.е. виртуальная метка висит где-то перед стволом по линии прицеливания, то надо уже ваять шейдер с математикой. Здесь тоже есть разные пути. Самый правильный, это пытаться делать как это выглядит в реальном коллиматоре, т.е. метка находится на каком-то заданном расстоянии (скажем 50 метров) точно по оси стекла, т.е. поверхности шейдера. Это можно, но довольно напряжно. Поэтому сделали проще. Метка на стекле рисуется просто между своим исходным положением на стекле и центром экрана. При этом, когда ствол выравнен на линию прицеливания, метка одновременно совмещается с центром и своим исходным положением, всё остальное время плавает где-то посередине (пропорция тоже задаётся). Это получается некая имитация совсем правильного подхода, но зато гораздо проще в реализации. У нас так и сделано. А, и здесь ещё потребовалась небольшая правка движка, для того, чтобы в шейдер передать разрешение экрана. Без него там не получалось сделать нужные вычисления. Была ещё идея сделать переключаемые метки, как на реальном прицеле + регуляцию яркости свечения, но на это уже времени не хватило.

Несколько застрял с аддонами. Дело в том, что при планируемой системе, комбинаций аддонов получается немало, и просто уже нереально прописывать все комбинации вручную. Придётся делать какую-то утилиту по генерации набора секций. Этим и занимаюсь.