[SoC] Ковыряемся в файлах

[Malandrinus 611]

как сие сделано

сделано, как я и предлагал, на основе торговца. Обычный визуал физического объекта чайника, к нему добавил недостающие кости. Для головы добавил ("bip01_head") и ещё три для руки с оружием ("bip01_r_hand", "bip01_r_finger2", "bip01_l_finger1". В коде они упоминаются, но нужны ли реально не знаю. На всякий случай добавил). Добавлял в MilkShape, просто добавил безо всякой настройки  + в SDK добавил шейп всему чайнику, чтобы его можно было юзать. Собственно и всё. Остальное - обычные конфиги/диалоги торговца. Скриптов никаких нет, даже напротив биндер ему отключил, чтобы не пытался анимации играть.

Изменено 8 Апреля 2015 пользователем Malandrinus

[Malandrinus 611]

 

 

Удалить косточки в Милке - это я могу, а вот добавить

Да ладно прибедняться. На закладке "Model" сперва выбираешь "Select" и выбираешь ту кость, от которой должна расти добавляемая. Затем там же выбираешь "Joint" и кликаешь на виде, добавляя сочленение в нужном месте. Затем идёшь на закладку "Joints", в списке выбираешь новую кость двойным кликом, вводишь новое имя и жмёшь "Rename", чтобы задать имя.

[Malandrinus 611]

 

 

поставить в логику типа camper, и собственно ни каких костей ни куда добавлять не надо

Подход с трейдером имеет ряд преимуществ:

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

2. никакой логики вообще не надо, даже биндера нет.

3. как производное от п.2. Поскольку скриптовой части нет, расходы в игре будут меньше.

4. в случае чего не попытается убежать или обвалить игру из-за отсутствия путей и т.п.

[Malandrinus 611]

 

 

проникся идеей рисования

Я не очень тебя понял. Прозвучало как идея рисовать окна исключительно скриптами. Но при чём здесь тогда dialog_manager, который вроде как отвечает за диалоги?

[Malandrinus 611]

 

 

ну и в таком вот духе.

Стандартные движковые диалоги вполне это покрывают. Зачем делать что-то ещё? Кстати, а чем плохи XML? Особенно, если есть оболочки для их написания?

[Malandrinus 611]

Статикой. Это вчерашний день.

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

 

пока Вы не представите сколь-нибудь приемлемого метода перезаписи и перезагрузки файлов xml в процессе игры

Зачем? XML - это статика, как ты сам  верно заметил выше. Любое окно, даже самое супердинамичное, обязательно имеет в своей основе статическую часть. Используй для этого XML, а что не получается - допиши скриптами.

 

Народ, не занимайтесь ерундой. Хотите тратить свой время на поиски "серебряной пули" от всех проблем - ваше дело, но не вводите в заблуждение новичков. Надо всегда решать проблему максимально рациональным и простым способом, но к этому не относится неумение чем-то пользоваться. Я тоже какое-то время не умел пользоваться XML для создания окон по причине элементарного отсутствия информации. Сейчас такой проблемы нет, поскольку есть исходники, посмотреть что означает тот или иной параметр не составляет труда. Так вот XML - это отличная вещь. Экономит кучу времени. Позволяет выделить данные из кода и менять многие параметры окна, не меняя код. Сам код становится более структурированный и лаконичный.

 

иллюзия достойная всеобщей поддержки, но... всё равно иллюзия.

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

 

возможна-ли реализация динамической перезагрузки диалога? Внеся правки в движок разумеется. Вообще что из себя представляет диалог? Это объект чего?

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

[Malandrinus 611]

@Сталкер-Стрелок, вопрос понятен. На текущем движке динамически формируемый диалог не сделать. Я это подробно описывал в статье справочника. Если коротко, то диалоги кешируются один раз за всё время запуска программы, поэтому обращение к диалогу с заданным id второй раз, пусть даже этот второй раз будет после загрузки другого сейва, даст в точности тот же граф. При этом не имеет значения формировался ли диалог на основе XML или скриптами, поэтому скриптовое формирование имеет чрезвычайно узкое применение. В той же статье я приводил некоторые способы это ограничение частично обойти.

Можно ли это изменить? Точечными правками, как в x-ray extensions, нельзя. Надо менять на уровне исходников, выкидывать кеширование (которое на мой взгляд и изначально не нужно вовсе) и расширять скриптовые средства формирования диалога.

[Malandrinus 611]

Кеширование имеешь ввиду выбрасывать из GamePersistent?

Я не помню уже точно где именно, но там имеется глобальный массив, где распарсенные диалоги хранятся по ключу-id. Сохраняются они там при первом обращении и затем уже используются распарсенные из этого массива. Я понятия не имею, зачем это было надо, поскольку экономия скорости совершенно мизерная, да ещё и на сугубо разовое действие. Ну парсился бы этот диалог из файлов при каждом обращении, и что с того? Можно подумать, что в 2000 году, когда это всё начинали ваять, компьютеры были настолько медленные, что время парсинга пары килобайт XML могло составить сколько-нибудь заметное время. Смешно даже. Да и происходит это при открытии окна диалога, что сама по себе некая пауза, на фоне которой долей секунды на парсинг (если не меньше) никто не заметит. Могу также заметить, что это - типичнейший случай того, что буржуи называют "over-engineering", ненужное переусложенение.

 

Короче, выкинул бы я этот массив и оставил бы парсинг диалогов каждый раз. Заодно пару мегабайт изрядно фрагментированной памяти бы сэкономил и избавился бы от кучи ненужного кода. Вот тогда и полностью скриптовое формирование диалога получило бы реальный смысл (при разумном использовании конечно, а не так, как здесь некоторые проповедуют).

 

Способ добавления диалогов НПС останется прежним в таком случае? Инклюды нужны все равно в таком деле.

Да, я вижу это так, что убирание этой внутренней структуры не потребует ничего менять с точки зрения конфигов.

 

Но это всё в теории, и кстати оффтоп здесь, в теме про ТЧ.

 

Про лаконичность и читаемость кода - гм, этот самый dialog_manager, особенно в его исходном виде - хорошая иллюстрация, да.

Это, кстати, следствие вышеописанной кривой внутренней архитектуры, которая навязала кривую же скриптовую обвязку. Формировались бы диалоги действительно динамически, не нужно было бы и мутить тот огород с длиннючим скрытым списком квестов и кучей предусловий для выбора из них всего нескольких. Но это кстати не отменяет XML для большинства диалогов, которые, как и большинство окон, вполне статичны и отлично вписываются в идею статичного дерева (с минимальными вариациями с помощью предусловий).

 

Впрочем, не об том хотел сказать. А о том, что дерево диалогов - от нормального общения, которое таким образом пытались и изобразить, бесконечно далеко. Именно тем, прежде всего, что в нормальном разговоре всегда можно выбрать интересующую тему СРАЗУ, и в любой момент к ней вернуться. А не "привет - привет - у тебя пнв есть ? - есть - а к костюмам прикручиваешь - прикручиваю - а цветные есть - есть - тогда дай зеленый - тебе его на пальто красное прикрутить, или на синее - мне на трусы - тогда их надо было с самого начала на себя надеть - досвидания."

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

 

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

 

 

делается табличкой разрешенного и сканом инвентаря + чтение дескрипщенов у найденных трусов. И из этого формируется текст для кнопки. То есть, ни каких развесистых древ не нужно заранее прописывать.

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

[Malandrinus 611]

 

 

даже не знаю, как это охарактеризовать... Может муть? или потуги на защиту чего-то? или другое?

Что именно муть? Разделение кода и данных? Или идея о том, что задачу надо решать наиболее подходящим способом?

Кстати, а что не так с грамматикой в моём предыдущем посте?

 

 

значит xml это всё же статика?

Я повторю вопрос. Чем плоха статика?

 

муть.

Знаешь, а это уже п.2.1.1. Изволь добавить внятное изложение своей точки зрения.

[Malandrinus 611]

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

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

Даже можно создать подобие некой динамики, но с обязательными заготовками, допустим 100 диалогов зависящих от разных условий, ...

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

Про xml это дело вкуса.

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

Аналогично, коллега. И собственно так и делаю, если открыть скрипт моего инвентаря и набрать в поиске "xml" - ничего не находит. Я не пользуюсь никакими обращениями к xml-конструкциям вообще.

Вот я могу подробно объяснить, чего именно я добиваюсь, разделяя код и данные:

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

Можешь привести похожую аргументацию со своей стороны?
 

А я не могу написать свое окно, у которого можно будет менять все-какие-захочу параметры, вообще никак не меняя код?

Не уверен, что до конца понял вопрос.

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

Да неужели. Может потому что для 99% авторов сделать другие - не представляется возможным?

Может всё-таки потому, что большинство окон - просто статические? Это как из параллельного разговора про организацию диалогов. Большая часть диалогов - простые и вполне себе линейные/статичные (и вполне описываются статичными же XML). Ну вот так получается.

 

 

Изменено 10 Апреля 2015 пользователем Malandrinus

[Malandrinus 611]

@Fagot.,

с каких это пор в ТЧ появился сон?

[Malandrinus 611]

Вот новая логика, тоже не работает...

 

Тебе @Карлан совершенно верно сказал, ты пытаешься приделать к двери схему кнопки, которая разумеется никаких анимаций открывания/закрывания делать не умеет. Схема определяется по началу названия секции логики. Для двери это будет соответственно ph_door. Возьми готовый пример для двери Сидора, это файл config\scripts\esc_trader_door.ltx. Изучи его внимательно, там в общем-то типовая дверь. В той же папке ещё много схем с дверями.

[Malandrinus 611]

@Tayler, да, был неправ. Тогда действительно схема ph_door не подходит.

 

В случаях таких непоняток, но при наличии рабочего примера я обычно беру и сравниваю свой объект с тем, который работает. Как настроены кости рабочего объекта и твоего в акторедиторе. Нет ли там случаем каких-то конфигов в модели. Как он добавлен в спавне. Нет ли там чего дополнительного в кастомдате. Здесь можно попытаться распаковать спавн в текстовый вид и сравнить буквально построчно.

 

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