Universal ACDC и другие perl-скрипты

[Artos 99]

Предложение:

С целью использования возможности работы с оригинальным файлом 'game.graph', а не с его копией, добавить опцию для возможности указания пути до этого файла, т.е. типа:

 

[-g graph_dir]

 

-g <graph_dir> - путь до game.graph. Если не задан или пуст, граф распаковывается из корневой папки утилиты.

[Artos 99]

KD87

Чтобы не вызывать волну 'фантазий', нельзя ли 'огласить весь список' возможных направлений именно для ACDC в плане пожеланий к функциональности? :-) Т.е. имею ввиду, каковы пределы фантазий? Ведь для упаковщика/распаковщика основное именно получить распакованные коды в стандартном и удобно читаемом виде и упаковать строго в соответствии с форматом игры.

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

 

Сортировка секций?

Учитывая то, что в игре имеется и в модах используется метод спавна объекта именно по индексу секции из 'all.spawn'-а ( alife():create(number) ), то ... пересортировка 'по вкусу' может запутать применение этого метода.

Попробую сформулировать:

Учитывая, что имеется метод спавна по индексу секции из all.spawn'а, в кодах скриптов заносятся численные значения этих индексов.

При добавлении/удалении секций в all.spawn, значения индексов после упаковки изменяются, что требует синхронизации новых значений из all.spawn'а со значениями из скриптов. При более чем десяток-два таких значений, ручная операция довольно утомительна и чревата ошибками по невнимательности/забывчивости.

Вопрос: возможно ли к ACDC подключить некий исходный файл-список с индексами секций (используемыми в скриптах), которые должны контролироваться. И, после перекомпиляции, получать список соответствий исходных индексов контролируемых секций (до упаковки измененного кол-ва всех секций) с индексами этих секций после (пере)упаковки?

 

Добавлено через 16 мин.:

P.S. 'Список контролируемых секций' - вероятно не самое удобное решение. Может быть модмекером может ставиться некий признак в секции all.spawn'а интересующего его объекта (некий аналог story_id), а упаковщик на выходе давал бы информацию о прежнем индексе секции (не обязательно) и новом индексе для данного конкретного признака.

Изменено 17 Сентября 2011 пользователем Artos

[Artos 99]

7.9

Сорри, но о каких папках ты говоришь и о каком автомате?

Номера секций - автоматически даются исходя из непрерывного последовательного ряда. Этот ряд делится на поддиапазоны по локациям. Любое внесение секции объекта на какую-либо локацию влечет сдвиг всех последующих секций с их индексами.

 

[Artos 99]

7.9

Можешь работать с all.spawn'ом как с обычными конфиг-файлами, соблюдая правила, только а) необходимо для "удобства чтения и правок" распаковать и запаковать его, если внес правки, и б) не использовать в своих скриптах метод, зависимый от плавающих индексов. :-)

Изменено 17 Сентября 2011 пользователем Artos

[Artos 99]

KD87

Я ни коем разе не имел ввиду "залоченные" (неизменные) индексы, это было бы слишком хорошо, но увы врядли возможно.

Вывод в лог-файл типа [4562]:log -> OLD - NEW - уже подспорье, но частичное.

Морока модмейкеров, кто имеет такие необходимости по синхронизации индесков вот в чем:

1. Имеем, например десяток переходов (level_changer) и/или рестрикторов и/или квестовых персов.

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

3. Нужно открыть переход - спавним по секции, нужно включить (опять) рестриктор - спавним по секции, нужно оживить мертвого перса - удаляем и спавним по секции.

ВО всех этих опервациях важен именно индекс секции из текущеко алл.спавна. Стоит в начало алл.спавна иль еще куда вставить новый объект - все (или даже часть) используемых в скриптах индексов поплыли ...

Вариант с [4562]:log -> OLD - NEW - уже подспорье, не нужно лазить по всем ltx в поискаи по имени иль еще какому признаку нужной секции и считывания его индекса. Но имея только набор соответствий и не имея дополнительных (еще лучше эксклюзивных)признаков (имя, story_id, ...) - также просто и ошибиться.

Может быть кто-то еще, иль я попозже, даст нечто более удобное, но на сейчас:

если в секцию добавлять что-то типа параметра 'fix_index=my_name_1' и в лог выводить: my_name_1: OLD_IDX => NEW_IDX

тогда задавая удобные 'my_name_1' модмейкеру гораздо проще контролировать и синхронизировать. Даже 'OLD_IDX' уже становится не особенно нужным (может для перепроверок).

 

Кто-то может возразить: "А зачем? Ведь можно и скриптами все это делать."

Да, и воскрешение персов скрптами уже не проблема, и спавн любых переходов в нужное время (по крайней мере я уже сделал) и рестрикторы не так уж и много жрут ... Но и немало нюансов (с теми же персами) да и неискушенным скриптерам попроще.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

7.9, ты бы все же вначале поработал бы немного с алл.спавном, дабы понять особенности и суть.

Ты предлагаешь на каждую локацию в обязательном порядке спавнить 2000 объектов? И, если нужных объектов не так много - спавнить некие пустышки? Тем самым "застабилизировав" индексы. И новые добавлять заместо пустышек? ;-)

Не забывая - каждый объект это игровой ID, а их в игре всего 65535.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

KD87, последний (17.09.2011) вариант ACDC работает отлично! Спасибо!

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

[Artos 99]

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

Хм, ... тут есть минусы.

1. Не факт, что какой-то модмейкер (новичков много) не создаст себе секцию типа [12345] - т.о. создав дубль.

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

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

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

 

Если хранить все такие метки в алл.спавне - нет необходимости в лишних действиях ... один раз пометил - пользуемся.

 

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

И то, что как то пытался (со старыми версиями) и обломалсия ... и в реадмухах слишком явно указано - не давало стимула проверять поддержку и экспериментировать.

Кстати, реадме тоже нужно бы подправить в некоторых местах, а то ... "-c <dir> - папка, в которой лежит запакованный спавн." - слишком вводит в ступор некотрых.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

KD87

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

Например, ни что нам не мешает добавить в секцию интересующего нас объекта некий параметр в

custom_data = <<END

; ...

fix_index = my_name_1

END

 

Этот параметр не воспринимается игрою.

Если настроить парсер на чтение "за комментом", то типа: ; fix_index = my_name_1

вообще будет безвредной.

 

Ну а про парсер скриптов - я и не заикался. :-) Если это возможно - то это и будет наверное оптимальным решением.

Ведь метод пока вроде как один и маска по 'create(%d+)' - вполне может решить задачу.

Но тут может быть проблемы! В папках скриптов порою валяется нерабочий мусор (в оригинале их куча) и парсер настраивать на игнорирование мусора.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

KD87

Если нельзя метку будет хранить в самом алл.спавне, потеряется универсальность ACDC.

Это как с новыми секциями объектов. Или парсить или ... руками выдергивать из скриптов.

Для того, кто разрабатывает один - хранение во внешних файлах - решение. Для остальных - необходимость ковыряться в распакованном моде.

 

[Artos 99]

KD87, похоже это один из вполне приемлемых и достаточных вариантов. ИМХО.

[Artos 99]

KD87

Если возможно, то модмейкер записывает в кастомдату:

custom_data = <<END
; ...
[fix_index];< метка
my_name_1 = id; < эксклюзивное имя и текуший индекс секции объекта
END

Т.е. при упаковке 'id' - заменяется на текущий индекс секции (дублирует его)

Т.о. можно даже из скрипта прочитать нужную секцию при наличии объекта в игре!

Тогда список таких секций не нужен (все в самом алл.спавне)

Если будет генериться ltx-конфиг, то по сути лог не нужен. Если не, тот логвполне приемлем и годен аналогично 'sections.ini', т.е. типа 'sections_fix.ini' с 'my_name_N = id' в строках

 

Если невозможно в кастом дату писать для метки получаемый индекс, тогда генерируемого ltx-конфига ИМХО достаточно, т.е. список не нужен.

И сам модмейкер пишет типа:

custom_data = <<END
; ...
fix_index = my_name_1;< параметр и эксклюзивное имя
END

 

Если будет генериться ltx-конфиг, то по сути лог не нужен. Если нет, то лог вполне приемлем и годен аналогично 'sections.ini', т.е. типа 'sections_fix.ini' с 'my_name_N = id' в строках или: [id] = my_name_N/

 

Мне неизвестны скрипты, которые могут споткнутся/обвалиться на таких записях в кастом-датах. Даже старенький АМК-рас(у)паковщик кастомдат с такими записями будет работать корректно и не обрезать их. Для парсеров логики и иже - они будут прозрачны.

Кстати, первый вариант - аналог (по форме) поменки статуса аномалии, сделанное при спавне динамических аномалий (АМК), т.е. проверено временем.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

KD87

Проверена последняя версия из #35, в целом все работает. Спасибо!

Помарка: При задании ключа '-idx' и (пути) имени файла для ltx-конфига - расширение 'itx' не присваивается файлу (файлу дается только имя).

 

Пожелалка: При не задании ключа '-idx' - в лог 'new_idx' выводить не только имя секции и индекс, но и хотя бы story_id.

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

 

P.S.

Задав в батнике такое: perl universal_acdc.pl -c ../src -o ../all.spawn -idx fix_idx

Получаю файл 'fix_idx' в корне утилиты. Если с путем ( -idx ../fix_idx ) - то по указанному пути получаю такой же файл без расширения ltx

Т.к. в описании говорится о создании именно ltx-конфига ("скрипт сформирует ltx конфиг") - то пользователь подразумевает о необходимости задания только [пути]имени.

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

smeh

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

Почитай реадми к ACDC и посмотри что у тебя прописано в батниках. Приведи их (пути/имена/...) к требуемому именно у тебя, а не со скачанного компа.

 

KD87

А может дефолтно именно принудительно давать заявленное расширение?

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

Можно и парсить это имя и ... при указании расширения - задавать именно его, а по дефолту давать именно *.ltx .

 

================================

Добавлено через 13 мин.:

Вопрос(ы) из категории "другие perl-скрипты":

 

Учитывая, что порою при модификациях встает вопрос совместимости со старыми/прежними сэйвами игры на данном моде, модмейкерам приходится или вводить усложнения по адаптции или заставлять игроков начинать НИ (заново).

1. Возможна ли работа (распаковка-изменение-упаковка) с сохранениями игры и создание скриптов для такой работы?

2. Чем и как можно работать с ссхранениями игры, учитывая конечно версию ТЧ/ЧН/ЗП?

Изменено 18 Сентября 2011 пользователем Artos

[Artos 99]

KD87

По последней на сегодня верcии универсального ACDC (18.09.2011):

 

Имеется критический недостаток при использовании формируемого ltx-конфига с индексами из алл.спавне.

Формируемый файл содержит достаточно много дублирующихся секций и его невозможно прочитать стандартным методом 'ini_file("spawn_ids.ltx")', т.к. движек вылетает по ошибке типа: "Duplicate section 'meshes\brkbl#0.ogf' found.".

 

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

В качестве признака, например, (на вскидку) может быть суффикс или приставка индекса локации (Кордон - 1 и т.п.).

Пока в тестах использую самописный построчный парсер секций.

 

Также, предложение: присвоить дефолтное имя 'spawn_ids' (по аналогии с 'game_story_ids.ltx') этому ltx-конфигу и логу (вместо new_idx).

Т.е. дефолтно будет (если есть метки) формироваться 'spawn_ids.log', при указании только '-idx' - будет формироваться в корне 'spawn_ids.ltx', ну а при указании пути|имени - указанное.

 

Также, предложение: для единообразия в 'custom_data' помеченных объектов добавлять секцию [spawn_id] (или [spawn_section_id]) вместо [fix_index].

 

Примечание для модмейкеров:

Использование чтения секции с именем и индексом спавна из 'custom_data' помеченного объекта применимо в случае, если в процессе игры НЕ перекомпилировался 'all.spawn' с добавлением новых объектов. В противном случае для сэйвов требуется коррекция индексов спавна в 'custom_data' объектов под перекомпилированный 'all.spawn' или НИ (заново).

Изменено 19 Сентября 2011 пользователем Artos

[Artos 99]

KD87

Если ACDC вытягивает имена аналогичные игровым alife():level_name(idLocation) - оно же level.name() - то вполне подойдет (для большинства).

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

И не уверен, при парсинге из game.graph не может попасться типа 'L01_escape'? (upper_symbol)

 

ИМХО, проще, быстрее и однозначнее запрос к секции ltx-конфига делать по числовому индексу локации: idLocation..'_'..obj:name()

Уж численные 'idLocation' у всех едино получаются (для текущей: alife():level_id() или по гейм-вертексу для любой: game_graph():vertex(idGv) ).

Да и собственно имя локации - это производная от индекса, который первичен.

 

Я бы предпочел [1_meshes\brkbl#0.ogf], т.е. приставка соответствует 'alife():level_id()' (без начальных нолей конечно).

Изменено 19 Сентября 2011 пользователем Artos

[Artos 99]

FANAT

Что значит "открывает ... и все.."?

Открывает этот файл типа в блокноте иль в ворде?

Или открывается консоль (черное такое окошко с буковками)?

Если второе - напиши что написано в окне.

Если первое - читай в шапке: "Для работы необходим Active Perl. Брать тут ..."

[Artos 99]

Если интересно, пару слов из серии "Знаете ли вы...":

 

Для того, чтобы 'скопипастить' все сообщение из консольного (DOS) окна нужно:

 

1. Не нажимая никаких клавишь на клавиатуре, кликнуть правой кнопкой мыши (ПКМ) по рамке DOS-окна.

2. В появившемся меню выбрать: Изменить -> Выделить все. В результате весь текст в окне подсветится ...

3. Нажать на клавиатуре клавишу: <Ввод> (Enter) или, опять же по ПКМ, в появившемся меню выбрать: Изменить -> Копировать.

В результате выделенный текст окажется в буфере обмена и может быть вставлен (Insert) в какой-либо редактор, например в "Блокнот" (Notepad), и сохранен как текстовый файл.

 

KD87, текущий (19.09.2011) вариант проверил. Работает как заявлено.

Появились некоторые мысли ... например по использованию того же 'guids.ltx'. Сформулирую немного познее, погоняв утилиту ...

Изменено 19 Сентября 2011 пользователем Artos

[Artos 99]

smeh

Если у тебя Windows7 - в батники перед 'universal_acdc' добавь 'perl' (прямой вызов интерпретатора языка).

 

Т.е.: perl universal acdc.pl -d all.spawn\ -o amk

 

 

KD87, про особенность батников для Windows7 вероятно стОит и в шапку вынести и в readme добавить. Вопросы такие постоянно идут и только будут расти повторы.

 

Эм, это необязательно. У меня семерка, никогда не ставлю perl. KD87

 

P.S.

ziStam, а ты попробуй оригинаьный спавн распаковать ... Тоже удивишься. :-)

ACDC сортирует пути по файлам локаций (way_ИМЯ_ЛОКАЦИИ.ltx) по гейм-вертексам прописанным в путях.

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

Т.о. секция пути и не теряется и не приводит к фатальным ошибкам игры/скриптов из-за ненахождения пути.

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

Изменено 19 Сентября 2011 пользователем KD87

[Artos 99]

smeh

Краткая инструкция по установке универсального ACDC для работы 'на лету':

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

Устанавливаем и настраиваем комплект ACDC:

 

1. Открываем папку 'gamedata\spawns' и в ней создаем папку 'acdc'.

 

2. В эту папку (acdc) копируем (распаковываем) весь комплект файлов из архива 'Universal ACDC.7z', т.е. в папке должны лежать:

- universal_acdc.pl - перл-скрипт утилиты;

- acdc_decompile.bat - командный файл для распаковки;

- acdc_compile.bat - командный файл для запаковки;

- stkutils - папка со служебными библиотеками утилиты;

... - необязательные или технологические файлы (universal_acdc_readme.txt и т.п.).

 

4. Выходим опять в папку 'gamedata\spawns' и создаем в ней папку 'unpack' - в этой папке будут находиться файлы распакованного спавна.

 

5. Открываем командный файл (батник) 'acdc_decompile.bat' и изменяем в нем строку на эту:

universal_acdc.pl -d ../all.spawn -o ../unpack -g ../../ -scan ../../config/

6. Открываем командный файл (батник) 'acdc_compile.bat' и изменяем в нем строку на эту:

universal_acdc.pl -c ../unpack -o ../all.spawn

7. Проверьте, есть ли в папке 'gamedata' файл 'game.graph'.

Если его нет - распакуйте его из пак-файлов (gamedata.db*) оригинальной игры и скопируйте в папку 'gamedata' мода.

 

8. Важно! Для вашей безопасности скопируйте файл 'all.spawn' в удобное вам место (зарезервируйте) для возможности восстановления исходного файла спавна после возможных ваших ошибок при редактировании.

 

Все, ваш комплект готов для работы с 'all/spawn'-ом на лету, т.е. вы можете запускать игру и играть, можете распаковывать, редактировать и запаковывать файл спавна.

- Распаковка - запускаете 'acdc_decompile.bat' (см. по пути '\gamedata\spawns\acdc');

- Редактируете в папке 'unpack' (см. по пути '\gamedata\spawns\unpack');

- Запаковка - запускаете 'acdc_compile.bat' (см. по пути '\gamedata\spawns\acdc');

- ... проверяете в игре.

 

Примечание: Если у вас стоит ОС Windows 7 - возможно потребуется в начало командных строк добавить вызов 'perl':

perl universal_acdc.pl -d ../all.spawn -o ../unpack -g ../../ -scan ../../config/
perl universal_acdc.pl -c ../unpack -o ../all.spawn

Успехов в модмейкерстве! :-)

 

Изменено 20 Сентября 2011 пользователем Artos