OGSE: КБ разработчиков

[Malandrinus 624]

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

log3(fmt, ...)

при этом вместо конкретных типов в позициях формата рекомендуется ставить %s (как для строк). Пустые значения вместо аргументов всё равно вызывают проблемы. Чтобы это побороть надо парсить строку формата, на что я заморачиваться не стал.

 

Таблицы любой структуры

print_table_inlog(table, comment)

Хотя опять же мне кажется, это ещё из оригинала идёт.

 

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

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

 

Так же документацию по движку и шейдерам.

По движку смотри проект x-ray extensions. Какая документация нужна к шейдерам? Они работают, что ещё надо?

 

Добавлено:

К слову сказать, изрядная часть документации там уже есть:

ogse_signals.script - сигналы, описание в комментариях

ogse_unist.script - система хранения, описание в комментариях

ogse_qt.script - "быстрые" (несохраняемые) таймеры, описание в комментариях

ogse_st_mgr.script - сохраняемые (сериализуемые) таймеры, описание в комментариях

 

компоненты от xStream:

xs_stor.script - система хранения, описание в комментариях

xs_sandbox_manual.txt - описание сигналов ("песочница", почему такое название - не ко мне)

xs_netpk.script - работа с нетпакетами, описание в комментариях

xs_timers.script - таймеры, описания нет, но есть пример использования

 

Кроме того, там же есть редактор зон и телепорт. Активируте их сами, с этим помогать (по крайней мере сейчас) не буду.

Изменено 16 Января 2015 пользователем malandrinus

[Malandrinus 624]

@Карлан,

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

Немного по конкретным моментам.
 

где этот самый полный рефакторинг? Лично я его не увидел

А хотелось, чтобы был переписан вообще каждый скрипт? А зачем? Большинство скриптов из оригинала игры не требуют изменения, поскольку выполняют рутинную работу и отлично работают. С другой стороны боёвка сталкеров, к примеру, сделана новая. "Полный" рефакторинг, как я могу предположить, по большей части имелся в виду относительно нового и относительно предыдущей версии 6.9.2. Новшеств всё-таки довольно много.
 

большинство скриптов даже мой нубский глаз режут

Слишком общее утверждение, надо бы конкретики.
 

понимаю, что действительно хорошие скрипты писались не людьми из команды

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

а вот некоторые люди из команды какой-то ахинеи наделали

Вот не вижу там откровенной ахинеи, хотя я бы и сделал это иначе. Бросаясь такими эпитетами надо быть конкретнее, что и почему там "ахинея".
 

зачем у вас две системы ивентов?

Так получилось. Там ещё и два набора систем хранения (не считая родного пстора и основанной на нём АМКшной системы), три набора таймеров (считая АМКшные), два набора библиотек работы с нетпакетами. У всего своя история. Таймеры АМК я пытался изничтожить и почти преуспел, но потом появились новые люди и стали использовать их снова. Пришлось, скрипя зубами, оставить.
 

какие явные и существенные плюсы имеют ваши системы перед существующими в комьюнити уже продолжительное время модулями от Артоса?

Артос запилил свою систему по мотивам моей и xStream (или xStream и моей, не знаю), когда мы их выложили на этом форуме какое-то время назад. И почему теперь я должен доказывать, что моя система лучше? Там есть полное описание, к слову сказать. Возьми и сравни. Покритикуй конструктивно, буду только признателен.

 

В заключение скромно замечу. Мы не россыпь фишек в архивчиках предлагаем, а платформу, где все упомянутые компоненты уже интегрированы вместе, в том числе и с учётом многочисленных движковых правок (которые и делались во многом для реализации той или иной фишки). Мне кажется, что такая платформа всё таки имеет некую самостоятельную ценность.

[Malandrinus 624]

@Карлан, Эти слова имел в виду?
 

Сделан рефакторинг и оптимизация скриптового кода (а критические места кода полностью переписаны), что позволило добиться ещё большей стабильности работы, чем это было достигнуто в версии 0.6.9.2

 

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

 

Рефакторинг надо? Как насчёт унификации скриптового спавна с единой базой данных? Я уже и забыл, что это делал, больше года назад было. Как насчёт полностью переписанной системы сменных аддонов? Или новый менеджер погоды без необходимости создавать переходные циклы.

 

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

Изменено 23 Января 2015 пользователем malandrinus

[Malandrinus 624]

Не думаю, что скажу что-то совсем новое, но не могу оставить это замечание без ответа.

 

почему пропустили скрипты вроде "работает - и ладно".

Для этого есть масса причин:

1. Работает же. Есть ли на самом деле причина переписывать то, что работает? Вот упомянутый скрипт Жекана вполне рабочий. Ну сделал бы я его иначе, с одним классом окна и таблицей фраз, и что бы стало лучше? Ровным счётом ничего. С другой стороны пришлось переписывать модуль оружейных аддонов. Его сделал Дасти и сделал очень хорошо. Дасти вообще сильный скриптёр, очень жаль, что отошёл от разработки. Но делал он тот модуль ещё под стандартный движок. Там были принципиально нерешаемые проблемы, которые удалось преодолеть только движковыми правками. Соответственно, я и переписывал модуль, поскольку самолично вносил эти правки.

1.1. Как специальный случай этого пункта. Есть риск сделать не лучше, а хуже. Лично я не полезу в модуль, если не до конца понимаю, что и как там работает. А не понимаю я достаточно часто, в том числе по причине п.2. Бывает так, что руки чешутся переписать код, поскольку он выглядит страшно, но попросту нет ни времени ни сил, чтобы в этой лапше разбираться (и в том числе тяжело разбираться в плохом коде. Чем код лучше, тем он проще.)

2. Нет времени. Вот ты меня чуть ли не главным ответственным за код всея мода назначил, а я вообще-то больше по движку занимался, особенно года два назад и раньше. Дело это весьма трудоёмкое (причём к моей крайней досаде трудозатраты совершенно непропорциональны результатам). В общем, получалось, что либо пилить движок, либо скрипты - на то и другое времени уже нет.

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

3.1 Другой аспект человеческого фактора: почти нереально подвинуть разработчиков использовать вменяемые компоненты. Не скажу, что был абсолютно единственным пользователем своих модулей, но я наверное потратил больше времени на попытки объяснить, как пользоваться моими таймерами, нежели на их разработку =)

[Malandrinus 624]

 

 

за 64 может легко перевалить

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

[Malandrinus 624]

, функция просто суммирует, как ты верно понял. Нужно это потому, что при арифметических операциях Lua превращает целое число в число с плавающей запятой со всеми вытекающими. Объект - это текущая камера машины. Это отдельный объект, на который идёт указатель из объекта собственно машины.

[Malandrinus 624]

, а чего не в вики проекта пишешь?

[Malandrinus 624]

@k01jan, схему делал Dusty79 много лет назад, а я допиливал с учётом движковых правок, но не меняя общей идеи с конфигами. Модуль ogse_addons.script. Манипуляции с костями худовой модели описаны здесь.

[Malandrinus 624]

Хочешь скину? У меня есть такое.

Был бы признателен. А там в целом стандартные анимации есть? Стрельба, перезарядка и т.д.? Т.е. аддоны анимировать не надо, но всё остальное должно быть.

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

1. Кости для разных прицелов все используют в качестве корневой кость стандартного прицела "wpn_scope". По-моему, нельзя делать кость совсем без поверхности, поэтому в этом случае надо прицепить к стандартной кости хоть что-то, чтобы не было вылета.

2. Разных прицелы используют в качестве корневой кости корпус. На стандартной кости "wpn_scope" сидит один из прицелов (как обычно).

 

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

[Malandrinus 624]

для второго варианта прицелу дополнительному кость как называть? wpn_scope2?

Да

Её ж по имени скрывать/показывать скрипт будет?

Да

Какова будет глубина вложения скрипта? 3 кости ("средний", "дальний", коллиматор), больше?

Мне сейчас достаточно одного дополнительного прицела, чисто для эксперимента.

 

И прошу сразу предусмотреть в скрипте возможность смены магазина.

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

 

ИМХО достаточно будет 3 доп.костей для сменных магазинов разной ёмкости.

А может для начала обойдёмся двумя прицелами?

 

Первый вариант подойдёт?

По второму варианту так будет работать? Или 2-й (и очередные) прицелы (аддоны) скрытыми делать надо?

Я не могу ничего сказать по картинке. Мне рабочая в игре модель нужна. Что значит "скрытые"? Визуально все прицелы должны быть на своих местах, причём все разом.

 

 

И неплохо какой-то стандарт на скелет ввести (типа тех.задания) - они ж нестандартные.

Я выше, как мне кажется, довольно подробно описал два возможных варианта. Названия для доп. костей не имеют значения. Важно только оставить стандартную кость и её имя "wpn_scope". Это имя зашите в движке.

 

И ещё: есть ли в движке метод alpeta по смене текстуры?

По-моему нет.

 

Не прокатило.. Анимации *.skls от "старой" модели без долоднительной кости прицела ожидаемо не импортируются в СДК

Я себе представлял, что надо перегнать модель с анимациями из сдк в некий общий редактор (MilkShape, Maya, 3ds Max), там добавить кость и к ней поверхность, затем перегнать модель с новой костью обратно в сдк. В принципе понятно, что кость, которая стоит на месте относительно корневой, на самом деле тоже анимируется, просто никуда не едет. Но редактор как раз и должен взять на себя работу по включению доп. кости в существующую анимацию. Или я не прав? Ну не верится мне, что надо переанимировать вообще всё при добавлении одной неподвижной кости.

[Malandrinus 624]

что на счет вопросов?

Это насчёт set_ignore_game_state_update? Я уже смутно помню. Какая-то затычка от какого-то нежелательного эффекта при промотке времени. Если вспомню, напишу в вики.

[Malandrinus 624]

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

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

[Malandrinus 624]

,

по последнему вопросу https://code.google.com/p/xray-extensions/wiki/type_check

по create_light01 и к нему относящимся. Это была моя попытка создать источник света на худе. Создавался, но толку не дало, поскольку создавался в координатах игры, а худ рисуется со своим FOV,

По остальным вопросам уже не помню, что и зачем.

 

Ещё скажу. wiki проекта x-ray extentions является его официальной документацией. Формат wiki специально предназначен для совместной работы и модификации того, что сделали другие. Так что вся информация в первую очередь должна быть там.

[Malandrinus 624]

@V92, Это не исправить. Ограничение в 65536 объектов - это размер двухбайтового поля в каждом объекте + масса кода, завязанного на этот размер. Даже имея исходники с полной перекомпиляцией потребуется изрядно переписать часть кода, а просто бинарными правками там ничего не сделать.

[Malandrinus 624]

@k01jan, насчёт 64 костей ситуация к сожалению печальная. Самих то костей может быть 65536, и хранятся они в массиве переменной длины. А вот флаги их видимости хранятся в 64-х битной маске. Судя по используемым алгоритмам, даже если удастся загрузить модель с бОльшим числом костей в игру, то они попросту будут не видны.

 

Но я пытаюсь понять, откуда так много костей. Вот одна рука - 18 костей, две 36, ствол: корпус, затвор, патрон в патроннике, спусковой крючок, магазин, гранатомёт и его спусковой крючок, граната, глушитель, прицел, ещё + 10 костей. Итого 46 костей. На что можно потратить ещё 18?

[Malandrinus 624]

@BFG, ну что сказать, надо экономить кости =) На мой взгляд, на оружии здесь перерасход. Про руки не скажу, не знаю. Но даже запас в 10 костей даёт свободу для добавления как минимум пяти-шести аддонов.

 

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

[Malandrinus 624]

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

[Malandrinus 624]

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

[Malandrinus 624]

 

 

Расскажите пожалуйста подробности.

Скрипты здесь вообще ни при чём.

Во-первых, нужна была правка косяка рендера, из-за которой на чистом ТЧ неправильно рисуются шейдеры прямого освещения. Дело в том, что худ рисуется в своей очереди да ещё и со своим FOV. ПЫСы схалтурили, и поверхности прямого освещения вне зависимости от принадлежности к худу попадали в глобальную очередь. С соответствующей правкой такие шейдеры на худе стали возможны, а это в том числе шейдеры самосвечения и полупрозрачных стёкол.

Дальше можно делать более или менее сложные вещи уже без правок движка (за одним небольшим исключением). Например, сейчас можно разместить светящиеся маркеры на мушке/целике (типа люминесцентные или тритиевые). Для этого нужны поверхности со стандартными шейдерами самосвечения. Далее, можно сделать неподвижный светящийся маркер на стекле. Это не совсем натурально, но уже близко к коллиматору. Для этого стандартный шейдер самосвечения не годится. Сейчас не помню, но там были проблемы с одновременным включением прозрачности отложенного освещения (как на колючей проволоке или листьях) и самосвечения. По моему было что-то вроде того, что эффект свечения применяется ко всей поверхности без учёта дырок. Короче, для метки на стекле уже нужен шейдер специальный, где яркость метки задаётся вне зависимости от внешнего освещения + есть прозрачность.

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

Была ещё идея сделать переключаемые метки, как на реальном прицеле + регуляцию яркости свечения, но на это уже времени не хватило.

[Malandrinus 624]

За выходные физически не успел завершить систему аддонов, но вчерне всё работает. По результатам экспериментов самый удобный вариант схемы костей дополнительных аддонов получается такой (для случая прицелов. Для остальных аналогично, только имя стандартной кости другое):

wpn_body
    wpn_scope <== кость аддона со стандартным именем и без поверхностей
    wpn_scope1
    scope2
    ironsight

т.е. иными словами:

1. кости нестандартных аддонов растут от корпуса ствола (нет необходимости делать их дочерними к стандартной кости)

2. стандартная кость ВСЕГДА присутствует и она пустая

3. на именование костей нестандартных прицелов не накладывается никаких ограничений

 

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

 

В общем, по указанной выше схеме можно уже начинать делать модели с анимациями. Скриптовя база будет в самое ближайшее время.