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

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


KD87

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

KD87, Universal ACDC не распаковывает аллспавн солянки.

FATAL ERROR!

Function: alife_object::read_common

Line: 5233

Expression: defined $class_name

Description: unknown class for section stalker_sniper

 

 

  ▲

▲ ▲

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

dragunof, распаковывает. Для спавнов от модов acdc необходимо запускать с ключом -scan [путь до папки с конфигами], предварительно удалив sections.ini от предыдущих запусков. В ридми это не разжевано, моя оплошность.

Пример батника (положите папку config от мода в папку с acdc):

universal_acdc.pl -d all.spawn -scan config\

pause

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

Спавн от бета-версии LW:ToD распаковывает.

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

У меня не получилось, выбило, что не может найти файл локации. Хотя путь до all.ltx указан.

Ссылка на комментарий
Real Wolf, в прошлой версии никак. В текущей версии доступно: http://narod.ru/disk/25416706001/Universal%20ACDC.rar.html. Компилировать с ключом -с, только вместо all.ltx указывать путь до папки с распакованным спавном. Если спавн в текущей папке - просто указать ключ -с.
Ссылка на комментарий

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

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

 

[-g graph_dir]

 

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

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Artos, сделано: http://narod.ru/disk/25432988001/Universal%20ACDC.7z.html. Поддерживаются переходы на верхние уровни каталога (../), то есть можно обойтись без абсолютного пути. В архиве есть примерный батник.

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

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

KD87

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

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

 

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

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

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

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

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

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

 

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

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

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

Изменено пользователем 7.9

всё легко

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

7.9

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

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

 

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Я пока all.spawn не использовал, но, видимо, "близится тот час". Хотелось бы работать с этим файлом как с обычными конфигами и не заботиться о том, что там что-то постоянно куда-то "уезжает".

Про папки я оговорился - файлы.

всё легко

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

7.9

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

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

Artos, что касается индексов. Нет, в общем случае "залоченных" индексов сделать нельзя. Просто потому, что движок при чтении спавна читает секции строго подряд, наращивая индекс на единицу. Поэтому в спавне не должно быть пробелов в индексах, в противном случае полспавна просто не заспавнится. Во избежание этого acdc при импорте секций на всякий случай переназначает все индексы - мало ли какие там провалы в индексах после правок модмейкером. Но подумать на эту тему можно, я понимаю суть проблемы скриптера. Пока могу сделать предложенный тобой второй вариант - вывод индексов секций (в лог-файл, например), помеченных метками. Скажем, для секции, записанной вот так - [4562]:log - будет выведен старый и новый индекс после запаковки в лог-файл. Так устроит?

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

Фантазию не ограничиваю никак. Утилита ведь нужна прежде всего вам, мододелам, вот и пишите, чего не хватает. Конечно, не стоит ждать от perl-скрипта второй LE, а так реализовать можно почти любую разумную вещь.

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

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

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' уже становится не особенно нужным (может для перепроверок).

 

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

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

Ссылка на комментарий
движок при чтении спавна читает секции строго подряд, наращивая индекс на единицу

Вот и отлично - 2000 (зарезервированных) секций на локацию (в оригинале - в среднем не более 1000) и будет у нас "стабилизированный all.spawn". Локации заполнять последовательно, можно даже завести, что-нибудь в роде реестра для этого файла...

Ладно - вам виднее :)

Изменено пользователем 7.9

всё легко

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

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

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

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Artos, это я все понимаю. А зачем такая морока: 'fix_index=my_name_1'? Я вполне могу вывести в лог name или section_name из этой секции. В логе будет что-то типа того:

[stalker_wolf]
old_index = 456
new_index = 472.

Или только новый индекс, или в любом другом форматировании, можно добавить story_id, мне это без разницы, на ваше усмотрение.

7.9, тут не зарезервируешь, для движка все секции должны быть заполнены. Не заставишь же мододелов делать строго по 2000 объектов на локации.

Так графическая оболочка для ACDC интересна или нет?

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

Тогда... так:

ВО всех этих операциях важен именно индекс секции из текущеко алл.спавна

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

Изменено пользователем 7.9

всё легко

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

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

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

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

7.9, ты все-таки не совсем понимаешь проблему :) Для движка никакой проблемы нет - проблема у скриптеров (причем только у тех, кто часто спавнит предметы по id), даже не столько проблема, сколько неудобство. Сошлись на том, что в помощь скриптеру будет выводится инфо-файл с этими индексами, исключительно в целях удобства.

Artos, относительные пути и раньше поддерживались, просто не очевидно и никем нигде не указывалось. FEEL TEH POWER OF IO::FILE! :)

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

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

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

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

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

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

Войти

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

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

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

×
×
  • Создать...