Ежели честно, не планирую особо развивать эту тему, так как в текущей реализации Эры ничего не меняю. Мы расходимся в базе. База:
А + Б <> Б + А, если есть подмножество X, принадлежащее модам А и Б.
Мод С, используя А и Б, должен указать в каком порядке их скомбинировать, если X принципиально для работы мода С.

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

Мой вариант покрывает все случаи. О противоречиях пользователь уведомляется при запуске игры, при этом приоритет отдаётся настройкам более поздних модов. Положим, игрок хочет забить на настройки авторов и выстроить моды сам. Он делает это, создав группу [ordered] и перенеся все моды туда.

В варианте Сидра я должен создать секцию json для каждого мода, который используется и указать, эм, до него мне быть, после или где угодно? В чём практический смысл и где детерминированность? Если у вас, ребята, есть чёткое понимание, какие задачи вы собираетесь решить, то на здоровье

Я, так или иначе, включу тот ММ, который даст Сидр ) Только настройки меняются ini/json, первоначально вообще было просто (включил мод в сборку и всё ))).

Да, pac-и можно отключать переименованием. Само наличие паков, не выделенных в моды, мне не нравится. Просто мелкие моды замедляют работу виртуальной фс. 10 модов, 400 сохранёнок в games, 10 поисков по папкам + 4000 проверок существования файлов при первом доступе. Операции кэшируются, надо бы кэш увеличить и выделить эти Анимированные деревья в отдельный мод.

SyDr, будь другом, напомни, какой там самый последний формат настроек модов? Что Валерий использует?

(08.05.2015 20:34)Berserker Wrote:  Мод С, используя А и Б, должен указать в каком порядке их скомбинировать, если X принципиально для работы мода С.

Если. Но почему ты думаешь, что это возможно?

Странный вопрос. Конечно возможно. Всё, что возможно теоретически, возможно и в реале. Быстрая анимация в бою заменяет звуки + cranim. Если импортировать любой другой мод, заменяющий cranim (New Upgrades?), то встанет вопрос, нам нужны только звуки ускоренные или ещё и анимация монстров? Или второй мод заменяет модели на другие, с другим числом кадров, поэтому cranim.txt из Быстрой анимации будет вылетать? Если число кадров то же, стрелки не добавляются и не пропадают, то подойдёт и cranim.txt из Быстрой анимации.

И вот я, автор Lord или чего там ещё, собирая свой мод по кирпичикам, описываю зависимости. Явно не от балды же пишу. Мой мод явно после всех, которые использую. То есть after|does not matter мне не нужны. А вот указать порядок импорта не могу. Так смысл мне тогда делать сборку из модов? Придётся распаковывать все их ресурсы и копировать нужные в свои.

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

Сейчас автору Lordа проще распространять всю игру.

P.S. Но я не спорю ради спора. Пока не ясно назначение настроек Сидра. По мне, так проще просто перечислить неупорядоченный импорт, чем указывать, что все импортируемые моды должны быть before твой.

Quote:А если третий мод укажет наоборот?

При любой реализации можно получить противоречия

Quote:Ежели честно, не планирую особо развивать эту тему, так как в текущей реализации Эры ничего не меняю.

Ну так и у меня ещё ничего не реализовано

Quote:Мод С, используя А и Б, должен указать в каком порядке их скомбинировать, если X принципиально для работы мода С.

Идея понятна, но представить такую ситуацию я себе не могу (точнее могу, но на реальность перевести не получается). Вот что тут поделаешь...

Quote:В варианте Сидра я должен создать секцию json для каждого мода, который используется и указать, эм, до него мне быть, после или где угодно? В чём практический смысл и где детерминированность? Если у вас, ребята, есть чёткое понимание, какие задачи вы собираетесь решить, то на здоровье

Эмм... Ну не нравится секция на мод - можно как здесь: https://github.com/MinecraftForge/FML/wi...ation-file (в самом низу).

Quote:Я, так или иначе, включу тот ММ, который даст Сидр ) Только настройки меняются ini/json, первоначально вообще было просто (включил мод в сборку и всё ))).

Теперь проще - при распаковке с заменой настройки не перезаписываются.

Вообще, немного о других играх:
FTL - много модов не поставишь, нужно ручками аккуратно менять приоритеты в соответствии с указаниями автора
Minecraft - о приоритетах пользователь вообще не парится
Skyrim - пока моды не трогают определённые штуки, можно не волноваться, иначе начинается ад с оптимизацией порядка загрузки и созданием Bashed Patch

Berserker (если есть ММ - смотри каталог doc)

Вообще, я твою идею понял. При такой реализации будет больше инфы для правильной сортировки модов. Но с тем, что Phoenix указывает порядок для WoG и WoG RUS я всё равно не согласен
Но вообще, как ни крути, проблемы будут:
Вот есть B, который указывает, что нужно AB. И есть C, который указывает, что нужно BAC. Кому верить? Учти, что у нас пока вообще нет идей, кто самый приоритетный мод.

Quote:Вообще, я твою идею понял. При такой реализации будет больше инфы для правильной сортировки модов. Но с тем, что Phoenix указывает порядок для WoG и WoG RUS я всё равно не согласен

Я тоже заметил, просто пример хороший. WoG Rus будет импортировать WoG сам. Но если строить Феникс на базе WoG Revised, то нужно указать:

[ordered]
WoG Revised
WoG Rus

Потому что круто, что оба они сами импортируют WoG, но Феникс русскоязычный, а Phoenix Eng можно было бы ставить поверх Феникса.

Quote:Вот есть B, который указывает, что нужно AB. И есть C, который указывает, что нужно BAC. Кому верить? Учти, что у нас пока вообще нет идей, кто самый приоритетный мод.

Есть базовый список, формируемый при установке модов или вручную.
[unordered]
A
B
C

Первым делом разрешаем зависимости C. Если будет установлено, что A+B, а не B+A, любое противоречие приведёт к диалоговому окну: «Мод С требует порядка модов: A, B. Мод E требует порядка модов B, A. Противоречие не возможно разрешить в автоматическом режиме. Продолжить?».

Quote:Идея понятна, но представить такую ситуацию я себе не могу (точнее могу, но на реальность перевести не получается). Вот что тут поделаешь...

Угу, выше привёл.

Quote:Эмм... Ну не нравится секция на мод - можно как здесь: https://github.com/MinecraftForge/FML/wi...ation-file (в самом низу).

Не критично. Просто пока видится смысл в обычном массиве ["A", "B", "C"], учитывая, что все импортируемые должны быть загружены ДО текущего мода.

Quote:Вообще, немного о других играх:
FTL - много модов не поставишь, нужно ручками аккуратно менять приоритеты в соответствии с указаниями автора
Minecraft - о приоритетах пользователь вообще не парится
Skyrim - пока моды не трогают определённые штуки, можно не волноваться, иначе начинается ад с оптимизацией порядка загрузки и созданием Bashed Patch

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

Спасибо за конфиг, понял.

Предполагалось, что у ММ два режима (галочка). В автоматическом пользователь меняет порядок модов в основном неупорядоченном списке:

[unordered]
A
C
B

Можно через радио-переключатель посмотреть конечный список read-only, где разрешены зависимости. Разрешение зависимостей идёт в порядке от самого свежего к самому древнему: B, C, A.

Если же стоит галочка «вручную», то пользователь редактирует упорядоченный список:

[ordered]
C
B
A

При этом зависимости игнорируются, ведь упорядоченный список, он как пресет. Фиксирует всё жёстко.

В чём разница в твоей системе между:
[ordered]
WoG
WoG Rus
и
[ordered]
WoG
[ordered]
WoG Rus
?

Ни в чём.

(08.05.2015 21:38)Berserker Wrote:  Первым делом разрешаем зависимости C. Если будет установлено, что A+B, а не B+A, любое противоречие приведёт к диалоговому окну: «Мод С требует порядка модов: A, B. Мод E требует порядка модов B, A. Противоречие не возможно разрешить в автоматическом режиме. Продолжить?».

Вот это уже что-то приличное.

Berserker, если правильно понял, можно описывать так:
(Мне надоело говорить про приоритеты, поэтому я буду говорить о порядке загрузки - WoG первый, остальные потом, т.е. просто инверсия порядка приоритетов. Да, я знаю, что в реальности это не так)
priority - после всех расстановок у нас получается упорядоченная группа неупорядоченных групп. Можно использовать для дополнительной сортировки внутри этих групп (просто уже существующая запись сюда переедет).
incompatible - для меня это больше логическая несовместимость, чем физическая. Т.е. даже если игра и будет работать, но без ожидаемых изменений, я считаю, что моды несовместимы.
optional - мод совместим с этими модами. Не указывает порядок вообще, т.е. они могут загружены после.
required - эти моды обязаны быть для корректной работы. В идеале игра не должна запускаться с корректным сообщением об ошибке.
after - твоя система с измененим, что секции ordered постоянно повторяются (их можно сразу описывать строкой, а не массивом, но для порядка лучше было бы, чтобы всё одинаково было).
before - тоже самое.

Вообще, проблемы всё ещё есть, например, нельзя указать, что Mod 3 должен быть загружен до этого мода, но в любом месте. Можно было бы решить: два списка, необзательные и обязательные + список пар, какой мод после какого идёт:

SyDr, почему бы не:

optional => compatible
required не нужен же становится.
смысл before/after для меня не очень ясен. Зависимость, которая должна перекрывать тебя самого — очень неоднозначная зависимость.

(09.05.2015 15:48)Berserker Wrote:  required не нужен же становится.

Почему это не нужен? WoG Rus без WoG работать не может. А after - это как раз твоя рекомендательная система.

(09.05.2015 15:48)Berserker Wrote:  смысл before/after для меня не очень ясен. Зависимость, которая должна перекрывать тебя самого — очень неоднозначная зависимость.

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

Berserker, ты рассматриваешь систему, как что-то вроде импорта в языках программирования. Я же имею в виду возможность создать порядок загрузки для произвольного набора модов. Отсюда и идут корни priority и optional. Соответственно, before позволяет прописывать порядок загрузки для новых модов без необходимости обновления ифны в старых.

Всё о чём не знаем - совместимо и может быть загружено где-угодно.
incompatible - с этими модами не запустится или это бессмысленно.
required - без этих модов работать не будет.
hints - в чистом виде твоя идея с упорядоченным списком неупорядоченных списков. Здесь же список упорядоченных списков неупорядоченных списков :D

Результат читать так:
Мод несовместим с Sagamosa
Мод требует WoG для работы
Требует чтобы WoG Rus был загружен после WoG (при условии что он есть в активных модах)
"Yona", "Fast Battle Animation", "New Music Pack" должны быть загружены после "WoG Rus" (и, соответственно WoG)
"Phoenix Orange Skin" должен быть загружен после этих модов
Сам мод должен быть загружен после "Phoenix Orange Skin"
Другими словами, это почти то, что ты предлагал.
Дальше, Mod 3 должен быть загружен перед нашим модом, но при этом неважно где, т.е. можно перед WoG
Ну и Mod 4 должен быть загружен после нашего мода.