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

[Dennis_Chikin 3 658]

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

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

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

Изменено 23 Февраля 2016 пользователем warwer

[Malandrinus 611]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

 

По каким-то уникальным квестам, или тем более сюжетным даже не спорю, текущий вариант более чем приемлем.

[Zander_driver 10 166]

 

 

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

Секундочку, а разве я что-то сказал против разделения кода и данных? Код - в скрипте, данные - в ltx-конфиге. без XML, да.

 

 

Код становится меньше, причём существенно.

Честно никогда не гнался за краткостью кода. Если где то надо впихнуть пару десятков строк комментария, чтобы пояснить КАК работает некий блок, я их не стесняясь напишу. а вообще - почему он становится меньше, потому что мы позволяем xml-стандарту сделать что-то за нас? а если меня не устраивает как он делает. Нет уж спасибо, я сам напишу, свой код, мне не сложно.

 

 

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

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

 

 

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

ВТФ? Я окно создаю одной строкой

self.slot3_frame_id = self:Construct_Frame(self.SCA_Slot3, "slot3", self.mainframe, false)

Опишете мне полноценное окно с рамкой, с возможностью его двигать и менять размеры, рисовать на нем что угодно, писать на его заголовке, в XML, в ОДНУ СТРОКУ?

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

 

 

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

Вообще не понял. Хотим изменить данные - меняем конфиг. Там же текстуры описаны. Хотим изменить алгоритм действия - как ни крутите но придется лезть в скрипт.

 

 

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

У меня не до "определенного предела". у меня внешний вид моего скриптового инвентаря, целиком и полностью, начиная с основ и заканчивая мелочами, может изменить до неузнаваемости как угодно тот самый не-программист.

Вообще, зачем ограничивать дизайнеров какими-то пределами, можете мне сказать?

 

 

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

Проще - не проще, в коде ее можно просто сделать и пользоваться.

 

 

Для XML есть средства визуальной настройки интерфейса. Они пока недостаточно продвинутые на мой взгляд, но это вопрос решаемый.

Для интерфейса созданного совокупностью скриптов и конфигов они тоже уже есть.

 

 

Использование XML ничуть не ограничивает в использовании скриптового контроля при действительной необходимости.

Я бы не сказал, что это удобно. Лично для меня.

 

 

Ряд параметров можно задать только с помощью XML. Это конечно связано с движком, а не с парадигмой разработки, но тем не менее фактор такой есть.

Я по прежнему ни в зуб ногой что это за параметры, которые магически привязаны к XML. Я сам свое окно нарисовал, сам на него кнопку прилепил, сам текст написал. Интерфейс - я создал, я и устанавливаю в нем правила. Выровнять текст, перенести по /n или по слову "апчхи", сделать его полупрозрачным, мигающим, прыгающим, ползающим по потолку туда-сюда, меняющим цвет в зависимости от настроения кровососов на Припяти - я могу какие угодно параметры создавать, и управление ими выводить в LTX-конфиг. И тот самый не-программист сможет это все настроить как ему надо, не чертыхаясь в дебрях горбатого xml.

 

 

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

Мне кажется я ответил. Единственным не отвеченным вопросом осталось то, что вы пользуетесь XML который когда-то, кто-то создал, и написал код для его обработки. Да-да. А я трачу свое время на то чтоб написать систему которая работает так как мне надо. Но это мое личное время за которое я никому ничего не должен

 

 

@Сталкер-Стрелок, Я вам скоро смогу дать удобный функционал для того что вы в своем посте описали. И это будет на порядок удобнее чем существующими методами через xml или полностью скриптово. Просто не спешите
Он уже есть, этот функционал, но пока не в том виде чтоб его выдавать на публику...

[Verberes 7]

Мне необходимо удалить из Сталкера Тень Чернобыля - Весь сюжет. Я скачал мод: Подарок сидоровича. Потом я запер сидоровича что бы он не выдавал квест. Потом оказалось что при переходе на другую локацию выдаётся Автоматический квест (например на свалке: Убить главаря бандитов) друзья мне отрубили эти квесты. Но при Переходе в Припять - ОН ОСТАЛСЯ!! И вот что делать? Как убрать? Квест: Встретиться с группой сталкеров. Я поставил спаун в Припяти поглубже - теперь если не идти на переход на Радар - квест ни выдаётся. Но при переходе на ЧАЭС - всё равно идёт этот ролик (отрубить то можно... но дело не в нём) на котором показывают Стадион и кабанчиков в аномалиях. Потом загружаемся на ЧАЭС и ранее не взятый квест - появляется. Только теперь уже с середины: Найти вход в Саркофаг. Вояки БТР... в общем всё как в оригинале. Подскажите как удалить его а? 

Вот ссылка на Мод (продержится 90 дней... прошу поторопитесь.) http://rghost.ru/7HzFRYGMR

[Dennis_Chikin 3 658]

Для этого надо вдумчиво почистить config\misc\task_manager.ltx, некоторое количество файлов в config\gameplay + возможно, srcipts\xr_effects.script.

 

Как результат - новая игра, поскольку ни сэйв править, ни переписывать специально под заказ тот же task_manager.scipt - ни кто не будет.

 

P.S. Кстати, к вопросу об всех этих "менеджерах" с сохранениями, и об xml'ах, гвоздями прибитых.

 

upd: ну, "что-править, что-править"... Раз уж есть такое желание, то просто читать внимательно все, что там написано, и думать - а нужно ли оно, и для чего. В xml - файлы info* и task*

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

[Verberes 7]

Для этого надо вдумчиво почистить config\misc\task_manager.ltx, некоторое количество фалов в config\gameplay + возможно, srcipts\xr_effects.script.

 

Как результат - новая игра, поскольку ни сэв править, ни переписывать специально под заказ тот же task_manager.scipt - ни кто не будет.

 

P.S. Кстати, к вопросу об всех этих "менеджерах" с сохранениями, и об xml'ах, гвоздями прибитых.

А что именно нужно прочистить? А при новой игре у меня старт в Припяти. Так что всё нормально. А точнее что нужно Удалить из этих файлов?

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

[Zander_driver 10 166]

@Verberes, Раз уж речь идет про удаление сжета, то я бы заодно предложил поудалять все рестрикторы из аллспавна, кроме тех что к кострам пришпилены. Хуже не будет, а от всякой сюжетной "автоматики" избавитесь.
И кстати да, правка аллспавна тоже влечет за собой новую игру. Так что лучше в один присест сделать и то и другое.

[7.9 174]

Я вам скоро смогу дать удобный функционал ... Просто не спешите

Лучше скорее. Ещё время на освоение уйдёт...

Вот мне, например, 2dhud никак неохотавозможно допилить, хоть он и готов на 75% (с 2012 года ), а всё равно некогда... а нужно

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

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

@Zander_driver, движок правили? Мне допустим все равно xml или нет, в скрипте нагляднее, но в xml удобно форматировать.

[Lanta87 19]

Всем привет!

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

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

[Desertir 202]

@Lanta87, это коллизия трупов. Для этого есть движковые правки, посмотри в X-Ray Extensions или подобных проектах.

[Zander_driver 10 166]

@Сталкер-Стрелок, Вовсе нет. ничего делать с движком для этого не требуется.

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

@Zander_driver, ну как же? Без него мы будем генерировать тысячи фраз (выше написал), это не то что нужно в нормальном варианте. Тогда не заинтересовало. Подожду пока кто-нибудь в движке сделает что-нибудь нормальное.

[Карлан 1 049]

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

function get_build_number(date)
local datetime, days, build = os.date("!*t",os.time())
days = {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 303, 334, 365}
build = 365*(datetime.year-1999)-31+days[datetime.month]+datetime.day
return date and build, string.format('(+'..datetime.day..'%s%s)',datetime.month<10 and '0'..datetime.month or datetime.month, tostring(datetime.year):sub(3)) or build  --/> number, string
end
--// out: 5910    (+110415)

Я еще пишу дату, она возвращается форматированной строкой, если она вам не нужна поставьте просто return build.

[UnLoaded 313]

set_relation(...) для монстр->НПС и НПС->монстр будет работать ?

[Карлан 1 049]

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

 

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

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

[Zander_driver 10 166]

Все камни преткновения

на самом деле не все, ты видимо некоторые забыл) или не знал о них. Ну не важно. В движок я конечно полезу, всему свое время. Изменено 12 Апреля 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Не оффтоп. Хотя трэд надо будет потом по двум разным темам разносить однозначно.

И таки отнюдь не единственный.

 

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

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

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

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

 

Да, если бы оно изначально было бы в движке - возможно, ориентировались бы на движок. Родить мгновенно, переделать сразу и навсегда, всех обучить и дружно перейти на стабильную новую версию...

Гм. Опять же, если б 6 лет назад у движка была команда "вызвать код из внешнего модуля и передать ему вот этот кусок памяти" - ага, все б делал на этих самых модулях, благо, у мну есть правильно и годно спроектированная система вот таких вот модулей взаимодействия, 20 лет назад написанная и много раз помогавшая быстро родить странное под всякие странные идеи нашего родного государства. И, внезапно, под работу с таблицами же и заточенная (как предвидел, что кто-нибудь LUA придумает).

Но, это все из серии "если б у бабушки было сами-знаете-что".

 

А сейчас же есть две ветки работ, которые начать и кончить.

Первое - сделать в движке то, не знаю что, но чтоб красиво, и всем перейти на сделанное;

либо таки обертка на существующего уродца, которую можно оперативно затачивать под внезапно обнаружившуюся надобность, не трогая движок.

 

Как бы, оба направления вполне благодарные, но нельзя сделать все сразу. Эрго, кто-то полез в одно, кто-то пилит другое. И это радует, коль скоро не сподобились наладить совместную работу ну хотя-бы на уровне хоть того же freebsd.org - как говорится, ну хоть что-то.

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

[dsh 3 820]

Направьте, пожалуйста, в нужном направлении. Хочу понять, по каким условиям непись выставляет в торговлю оружие, которое у него текущее. Да и не только текущее. Чем вообще определяется, будет-ли первый встреченный сталкер продавать что-то, что у него есть, или не будет?

 

Спасибо.

[UnLoaded 313]

 

 

Хочу понять, по каким условиям непись выставляет в торговлю оружие ... Чем вообще определяется, будет-ли первый встреченный сталкер продавать что-то...

Конфигами(ltx-файлами), начинающимися с trade_....(папка gamedata\config\misc).