Перейти к контенту

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


Рекомендуемые сообщения

 

 

переделывать движок на что-что специальное

Если это о том что я говорил, то не стоит беспокоится.

В bin добавляется 4 dll-ки и 1 файл lua.

Т.е. 3 dll - это расширение lua, 1 dll и 1 lua - библиотека LuaXml.

Ни о каком движке речи не идет.

Ссылка на комментарий

Dennis_Chikin,

я бывало с Вами спорил, Вы бывало меня банили... но вот здесь я с Вами.

 


 

 

Если это о том что я говорил, то не стоит беспокоится. В bin добавляется 4 dll-ки и 1 файл lua.

хорошенькое дело: "не стоит беспокоится". В СТАЛКЕР играют миллионы, этот сай просматривают сотни ( ладно тысячи), моды на торрентах... везде. И вдруг... "не стоит беспокоится"!!! Делайте свои поделки для себя и близкого круга соратников... или найдите приемлимый способ оповестить всех остальных о необходимости: "3 dll - это расширение lua, 1 dll и 1 lua - библиотека LuaXml.".

Кудесник вы наш.

Ссылка на комментарий

 

или найдите приемлимый способ оповестить всех остальных
Интересно, уважаемый, а как в вашем мире моды устанавливаются?
Не  заменой ли оригинальных файлов?
P.S.1 Ах, нет. У вас это видимо происходит как-то по-другому.
 
Для вас это будет открытием, но указаные мною файлы тоже добавляются при установке.
Не удивляйтесь. Это не чудо. Подобное происходит у всех.
P.S.2 см. P.S.1
 
За сим не вижу смысла нашего дальнейшего разговора. Разрешите откланяться.
Изменено пользователем Nazgool
Ссылка на комментарий
Интересно, уважаемый, а как в вашем мире моды устанавливаются?

разрешаю и спокойной ночи,

 

по остальному... 

Как устанавливуются? - да простенько так... или через замену gamedata, или через установщик (после прочтения описания). Моды требующие перезаписи bin вообще никогда не устанавливаю (тем более под SoC). Каюсь, установил и даже с удовольствием играл в один мод, который требовал замену библиотеки из bin  -  "Время Альянса" (но он был под ЗП, стоил того риска и я знал зачем это надо было делать).

 

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

Как-то так.

Изменено пользователем Serge!
Ссылка на комментарий

 

 

Моды требующие перезаписи bin вообще никогда не устанавливаю

С таким подходом, скоро не останется модов, которые вы себе поставить сможете :)

 

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

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

2 Serge!: баны здесь прилетают за переходы на личности. Ну или за явный оффтопик. Посты в отстойник уходят из-за этого же. За спор по существу вопросов такого не бывает.

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

 

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

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

 

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

Кому не надо... Ну, тот не заинтересуется, и будет дальше плодить копипастой свои мегабайты. ;)

 

 

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

 

2 Nazgool: ересь в том, что остальным теперь надо это все самостоятельно повторять, или откуда-то выкапывать, что не сильно легче. ;)

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

 

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

Ведро холодной воды на голову получил, как только мне понадобилось переносить текст в пределах окна по "\n".
Тогда я и узнал что это не возможно сделать без использования xml в качестве конфиг. описателя и установки опции "complex_mode".
Сейчас эта возможность уже добавлена, но (1) это ковыряние движка, (2) кроме "complex_mode" в xml еще много опций не управляемых скриптово.
Под каждую крутить движок?. Я не специалист в этом, поэтому пошел по единственно доступному мне пути.

Повезло тут же.
Оказалось что CScriptXmlInit читает xml при каждом открытии окна. Плюс к этому уважаемый RvP открыл доступ к пространству 'io' в SoC.
Да и библиотека LuaXml уже давно существует. Бинго короче.

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

Я пошел немного по другому пути. Решил скрыть детали реализации в обертке для соответствующих CUI классов (также добавил для удобства новые классы и методы).
Т.е. всю информацию о строении, поведении окон и их опциях храню в этих классах.

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

Изменено пользователем Nazgool
Ссылка на комментарий
У меня такая проблема..

Решил соспавнить квестовый предмет:



[quest_case_sidor]:identity_immunities
GroupControlSection = spawn_group
discovery_dependency = 
$spawn = "devices\quest_items\quest_case_sidor"
;$prefetch = 32
class = II_ATTCH
cform = skeleton
visual = equipments\item_merger.ogf
radius = 1
;script_binding = stalker.object_init
quest_item = true
 
description         = item_case_esc_desc
 
inv_name = item_case_esc_name
inv_name_short = item_case_esc_name
inv_weight = 0
inv_grid_width = 2
inv_grid_height = 1
inv_grid_x = 8
inv_grid_y = 18
cost = 50


Вот секция в all.spawn:



[875]
 
; cse_abstract properties
section_name = quest_case_sidor
name = quest_case_sidor
position = 1.16483449935913,2.24864912033081,61.4285430908203
direction = 0,1.57047343254089,0
version = 118
script_version = 6
 
; cse_alife_object properties
game_vertex_id = 89
distance = 0
level_vertex_id = 278058
object_flags = 0xffffff0f
story_id = 0
 
; cse_visual properties
visual_name = equipments\item_merger
 
; cse_alife_inventory_item properties
condition = 1
upd:num_items = 0


При компиляции all.spawn FATAL ERROR! С логом:

4nr6dvw7ol3zrjg30pmgd62ic.jpg


Не могу понять в чем может быть проблема..(  :russian_ru:

NL-Vincenz.gif

Ссылка на комментарий

@NL-Vincenz

Ну во первых - story_id = 0 уже занят в игре, используй(пропиши по анологии) свободное значение в gamedata\config\game_story_ids.ltx. А во вторых - не стоит логи ошибок делать в виде фото. Кстати, файлопомойка мне пишет, что фото уже удалено.

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

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

 

 

 

Что касается дополнительных dll - если именно дополнительные, то ничего страшного не вижу

я тоже не видел, пока однажды мне одна такая дополнитетельная dll не принесла дополнительные проблемы. С тех пор я поступаю так, как поступаю.

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

 

 

С таким подходом, скоро не останется модов, которые вы себе поставить сможете

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

Изменено пользователем Serge!
Ссылка на комментарий

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

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

 

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

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

 

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

 

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

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

 

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

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

 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

Ссылка на комментарий

@Malandrinus, граф разговора, если объяснить строго, то например захотел я добавить в граф диалога еще фразу, либо переделать какую-то, и вот что-бы не ветвить огромными дополнениями эти вкрапления, можно было бы попросту обновить диалог в игре заменив нужные фразы и условия к ним. Т.е. по факту динамическое построение диалога. Предполагаю, что подобное будет сделать не просто, думаю нужно будет заводить массив, где хранить нужное нам время все эти созданные диалоги. Основной класс CPhraseDialog как я понимаю (а граф идет из CGraphAbstract), мне непонятно в какой момент происходит загрузка данных, и как трудно будет сделать перезагрузку всего диалога.

Изменено пользователем Сталкер-Стрелок
Ссылка на комментарий

Экстренный рескан смартов на предмет может ли быть назначен.

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

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

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

 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

Ссылка на комментарий

@Malandrinus, да, я имею ввиду исходники. Кеширование имеешь ввиду выбрасывать из GamePersistent? Способ добавления диалогов НПС останется прежним в таком случае? Инклюды нужны все равно в таком деле.

Ссылка на комментарий

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

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

 

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

Ссылка на комментарий

 

 

Экстренный рескан смартов на предмет может ли быть назначен.

Это я так понимаю для brain():update(). А что за объект возвращает сам этот brain(), и какие методы еще есть кроме update() ?

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...