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

[Dennis_Chikin 3 658]

Ковыряемся в файлах ТЧ

Прежде чем писать в тему - внимательно читаем первый пост, и пользуемся поиском.
Возможно, ответ на Ваш вопрос уже есть.

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

[abramcumner 1 157]

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

Не очень понял в чем здесь проблемы дерева диалогов. Проблемы у составителя этого диалога. Как бы можно сразу проверить наличие пнв, трусов и чего там еще. И добавить в диалог одну фразу: "поставь мне пнв на красные трусы".

[Serge! 127]

Это не ответ.

Это единственное, с чем я мог бы согласиться в Вашем ... даже не знаю, как это охарактеризовать...

Может муть? или потуги на защиту чего-то? или другое?

Изменено 9 Апреля 2015 пользователем Black Hawk

[Dennis_Chikin 3 658]

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

То есть, ни каких развесистых древ не нужно заранее прописывать.

[Malandrinus 615]

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

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

 

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

 

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

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

 

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

 

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

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

 

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

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

 

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

 

 

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

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

[Serge! 127]

а не так, как здесь некоторые проповедуют).

Давайте лучше без намёков!

Я не про себя.

 

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

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

 

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

муть.

Изменено 9 Апреля 2015 пользователем Black Hawk

[Malandrinus 615]

 

 

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

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

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

 

 

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

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

 

муть.

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

[Сталкер-Стрелок 12]

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

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

 

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

 

Про xml это дело вкуса. Можно использовать Dialog Manager, в любом случае если сделать новую скриптовую обвязку, то можно будет само описание увести и на ltx и на script. Либо в общем уже писать какой-то модуль по обработке фраз (из каких-нибудь имен, описаний и т.д.) и составления предложений.

Изменено 9 Апреля 2015 пользователем Сталкер-Стрелок

[Dennis_Chikin 3 658]

Графом по-определению является все, что может быть представлено набором вершин и связей между ними.

Но это может быть "дерево", может быть "клетка" (пустая внутри), а может быть и "блин" (все со всеми).

Кстати, сколько-то осмысленный софт - это, как правило, именно "блин" (и труба как частный случай).

Иное - результат деятельности разработчика-извращенца.

 

Мне, кстати, как человеку, измученному этим нарзаном еще с 86 года, вообще как-то ближе представления не в виде графов, а в виде таблиц с набором векторов (континуальным, на то оно и программа, а не человек) между ними.

 

Впрочем, это уже, наверное, в курилку.

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

[Priboj37 324]

@Сталкер-Стрелок, .... 100 диалогов Ого! В ЧН, как вариант - стартовый диалог , (вопрос) текст- озвучка (ответ). ps. все, молчу, молчу, уже убег.

[Zander_driver 10 334]

 

 

Поэтому когда-то и решил для себя, что все окна буду делать только на скриптах.

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

 

 

Ведро холодной воды на голову получил, как только мне понадобилось переносить текст в пределах окна по "\n".

У меня переносит спокойно... весь вопрос в том, что есть окно, что есть перенос текста. и как найти в тексте эту "\n"...
Да, для этого приходится ручками переписать кое-что из того, к чему пользователи Виндовс привыкли как к тому что "само делается". но не так уж это сложно.

 

 

кроме "complex_mode" в xml еще много опций не управляемых скриптово.

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

 

 

P.S. 2 Zander_driver: может уже пора слегка приоткрыть тайну золотого ключика ? Я имею в виду принцип, на котором сделан скриптоинвентарь ?

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

 

 

Так вот XML - это отличная вещь. Экономит кучу времени. Позволяет выделить данные из кода и менять многие параметры окна, не меняя код. Сам код становится более структурированный и лаконичный.

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

 

 

99% всех окон статичны

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

[Сталкер-Стрелок 12]

Например, хоть одну назовите?

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

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

@Malandrinus верно говорит, что при наличии исходников писать какие-то схожие дубликаты движковых интерфейсных классов - напрасная трата времени.

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

Я думаю речь была об оригинале. Да и в целом, зачем динамика спальному мешку, к примеру?

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

[Zander_driver 10 334]

 

 

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

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

[Сталкер-Стрелок 12]

@Zander_driver, я возможно не прав, но мне кажется ты как-раз возмущен тем, почему никто не сделал сложные интерфейсы, и агитируешь за то, что-бы всем чем-то подобным заняться. Цели я поддерживаю, но почему не нацелится на дополнения в движке? В скрипты же все это экспортировали явно не для того, что-бы писать сложные системы вроде инвентарей. Началось я так понимаю это все с багажника для машины.

[UnLoaded 313]

Прошу помочь, не получается самому сделать: есть НПС, шмаляет в монстра, монстр в ответ дубасит непися. Задача - сделать так. чтоб монстр не убил непися, а только довел его до раненого состояния. Со стороны непися, у меня вроде все получается, настроил ему wounded - после одной-двух пилюль от монстра он исправно переходит в wounded, при этом выдаю инфо-порцию. Эта и-п переключает логику монстра на следующую секцию, в которой ему прописано npc_friendly = true. Вот только бестолку - монстр сначала заканчивает убиение уже не сопротивляющегося непися, и только потом переходит в новую секцию. Как тварюку заставить во время остановиться ?

[Капрал Хикс 534]

@UnLoaded, 

может, просто грохнуть тварюку скриптом по выдаче инфопорции? Или она живой нужна, для опытов?

Изменено 10 Апреля 2015 пользователем Капрал Хикс

[UnLoaded 313]

 

 

просто грохнуть тварюку скриптом по выдаче инфопорции?

Некрасиво будет... Совсем.

[Сталкер-Стрелок 12]

@UnLoaded, смотря в какой схеме оверрайд выставляешь. Не для всех схем он доступен, только для двоих.

[Nazgool 250]

Например, хоть одну назовите?

heading             -- этот в движке уже делали

complex_mode  -- и этот

light_anim

la_cyclic

la_text

la_texture

la_alpha

xform_anim

xform_anim_cyclic

highlight_text

vert_align

 

И это только для CUIStatic. Для остальных классов  писать?

Как их изменять скриптово? Никак. Нет таких методов в CUIStatic. (ну по крайней мере было никак).

Если кто-то сделает это всё в движке, то денег конечно не дам, но благодарность обеспечена.

А раз пока ничего подобного нет, то остается только новые классы городить.

 

У меня переносит спокойно

Ну это я писал про "то время". Сейчас и у меня нормально переносится.

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

[UnLoaded 313]

 

 

Не для всех схем он доступен, только для двоих.

Ну так поделился бы, в каких именно ?

[Zander_driver 10 334]

 

 

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

Вообще то я немного другое имел в виду. И - всех заняться чем-то одним, я точно не агитировал и не буду. Это глупо.

 

 

Началось я так понимаю это все с багажника для машины.

О_о. В моем случае точно не с этого. мне просто был нужен инвентарь в котором я смогу сделать все что захочется.