There are many json formats that now support single-line // or multi-line comments /**/.

Quote:Фатальный недостаток json - отсутствие комментариев.
Я очень люблю этот формат, конечно, хоть и в плюсах он не так удобен, как в ЯП, хранящих метаинформацию, но все-таки этот факт сильно ограничивает его применимость именно для конфигов.

В Эре парсер Json поддерживает однострочные // комментарии.

Quote:Эээ.. и как это будет осуществляться в реальности?

Как сейчас с *.btn-кнопками, только лучше. Появляется плагин на новых монстров с описанием формата. Он закрывает все вопросы, предоставляя декларативное json-api (под который без проблем можно писать визуальный редактор) и набор функций API для остальных. Для базовых потребностей по монстрам без учёта новых способностей RedirectBlock + одной функции GetMonCount хватило бы за глаза.

Quote:Лучше не надо. Тот патч, который я выложил, вызовет несместимость с ERA+.

Эра+ — потенциальная сборка. С ней просто не включать неудобные плагины, дублирующие функциональность. Это же решается в два щелчка. Нет?

Quote:Мне видится правильным такой подход к разработке платформ, при котором обеспечивается максимально широкий доступ к модификациям, богатый формат описания объектов и отсутствие привязки к фиксированным значениям. То есть правильный плагин на новых монстров — это плагин, парсящий json из VCMI и предоставляющий API для получения адреса таблицы с монстрами, размера одной записи, максимального числа монстров, актуального числа монстров. Завязывать же всю игровую структуру, а то и все структуры на конкретном разработчике нельзя.

Вероятно, разумным будет предложить библиотеку с методами получения/установки адресов и пределов для всех основных игровых структур.
ПолучитьМаксимальныйИДМонстра, ПолучитьЧислоМонстров, ПолучитьТаблицуМонстров. Установить первое, втрое и третье.

Поскольку правильное расширение структур, на мой взгляд, должно иметь динамическую природу (монолитов 8, 50 или 100 зависит от содержимого json-конфигов), то и переносить подструктуры по методу Хероманта или Игрика не вариант. Исходный код gameManager->twoWayTeleports всё время генерирует команду доступа от базового адреса, который можно пропатчить смело, не боясь нарушить остальной код, поскольку далее будет всё тот же gameManager->другоеПоле, который компилятор не имел права оптимизировать. Доступ по указателю — это такая штука, которая предполагает, что значение указателя может измениться даже из соседнего потока. Потому чаще всего можно подструктуру перенести на массив динамического размера без последствий. Если найдёте в патче Хероманта доказательство обратного, сообщите, пожалуйста.

После переноса остаётся несколько вопросов:
-) Какой теперь новый адрес подструктуры?
-) Размер её элемента?
-) Количество элементов?

Вопрос, схожий с обсуждением RedirectMemoryBlock/GetAddr и решаемый на уровне АПИ и соглашений, а не на уровне «никто не имеет права расширять ни одну структуру кроме автора мода ХХХ». Стоит ещё раз подумать, какого АПИ хватило бы всем.

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

Quote:Как сейчас с *.btn-кнопками, только лучше. Появляется плагин на новых монстров с описанием формата. Он закрывает все вопросы, предоставляя декларативное json-api (под который без проблем можно писать визуальный редактор) и набор функций API для остальных. Для базовых потребностей по монстрам без учёта новых способностей RedirectBlock + одной функции GetMonCount хватило бы за глаза.

Just wait a bit, will ya?

(14.12.2020 18:41)Berserker Wrote:  Эра+ — потенциальная сборка. С ней просто не включать неудобные плагины, дублирующие функциональность. Это же решается в два щелчка. Нет?

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

Quote:Появляется плагин на новых монстров с описанием формата. Он закрывает все вопросы, предоставляя декларативное json-api (под который без проблем можно писать визуальный редактор) и набор функций API для остальных.

Но ведь это не ответ.
Т.е. "автор сделает нам зашибись, а как - ну как-нибудь сделает". Я за такое даже за бабки грязно ругаюсь и иногда даже отказываюсь, а тут прост так.

Как будет реализовываться единообразное чтение json? Эра поддерживает комментарии, но не предоставляет плагинам ничего для работы с json (емнип), поэтому библиотек будет..разнообразно, и с теми же нестандартизированными комментариями будут наблюдаться всякие интересные эффекты.
Если это будет не просто "api c json", а именно JSON:API "типа я restful", то нужна сразу эталонная реализация. Кто её подгонит? Кто будет гарантировать, что она адекватна всем возникающим задачам? Как убедить людей, что она нужна?

Как будет это апи реализовываться? Экспорты из дллплагина, и заголовочник? Это возможно и без эры, но почему-то этим никто не пользуется. Не говоря уже об опухании дллмейна от всяких InitializeEra(); InitializeMonsterExtender(); InitializeMonsterExtender2(); InitializeArtifactExtender(); InitializeSomeshit1Extender(); InitializeSomeshit2Extender(); .. InitializeSomeshit37Extender();
Как будет решаться вопрос с разными версиями плагинов, и вообще с известной проблемой пятнадцатого стандарта? У нас уже есть два разных плагина для добавления монстров, и при этом этот зоопарк еще и не закрывает всех потребностей.


Альтернативное предложение: нам просто нужен обмен переменными на уровне эры, как это делают плагины и хота для общения с HD-модом.
Т.е. никакого внешнего апи, которое поддерживается волшебными гномиками, а тупо глобальное key-value хранилище, и функции типа GetEraDword("name", [default_value]), добавить по вкусу вариаций для разных типов.

Тогда, для получения размера монстров - GetEraDword("amethyst.monster_count", 197) или там даже GetEraDword("amethyst.monster_count", GetEraDword("typhon.monster_count", 197))

Более того, мы даже для массива существ можем использовать тогда конструкции вида (_CreatureInfo_*)GetEraDword("amethyst.monster_table_ptr", o_Creatures)

И вообще функция универсальная. У меня давно подгорает от того, что для SN:W-переменных нету прямого доступа, например, приходится писать всякие ненужные обертки над erm.
Туда же можно заливать прочитанный эрой JSON, типа какой-нибудь {plugin_config":{"param":1}} будет мапиться в "_json.plugin_config.param".. ладно, увлекся.

Quote:Давно прошу добавить в ERA режим глобального мода (или сборки), принудительно отключающий ненужные моды, но вот воз и ныне там.

Так с любой игрой с модами. Есть параметр командной строки modlist="путь к файлу со списком модом". Если это сборка, то и вовсе включи в архив list.txt. А если я всё равно хочу включить какой-то мод, я его включу.

Quote:Just wait a bit, will ya?

It's not an announcement. Just point of view.

Quote:Альтернативное предложение: нам просто нужен обмен переменными на уровне эры, как это делают плагины и хота для общения с HD-модом.
Т.е. никакого внешнего апи, которое поддерживается волшебными гномиками, а тупо глобальное key-value хранилище, и функции типа GetEraDword("name", [default_value]), добавить по вкусу вариаций для разных типов.

Тогда, для получения размера монстров - GetEraDword("amethyst.monster_count", 197) или там даже GetEraDword("amethyst.monster_count", GetEraDword("typhon.monster_count", 197))

Это форма неявного, нечёткого и более хрупкого API. Конкретно его низкоуровневая часть. В твоём высокоуровневом коде всё равно будут функции-обёртки, если делаешь по уму.

15 стандартов есть, когда нет ни одного удобного. Сам плагин через любую json-библиотеку сам считывает json-конфиги в своём формате. Как Yona считывает свой ini-файл. В чём сложность? Другим lua/dll/erm модулям нужно простое и рабочее API для доступа к новым возможностям. Даже указатель на массив структур можно получать, считывая части кода SoD, как и предлагали выше.

Доступ к SN:W переменным и глобальному хранилищу ключ-значение сделаю.

Quote:Сам плагин через любую json-библиотеку сам считывает json-конфиги в своём формате. Как Yona считывает свой ini-файл. В чём сложность?

А в чем смысл?
Ну т.е. это все то же самое, что и сейчас, ровно с теми же проблемами. Только стильный, модный, молодежный json (со своими новыми стильными проблемами).

Quote:Другим lua/dll/erm модулям нужно простое и рабочее API для доступа к новым возможностям.

Ну всем понятно, что лучше быть здоровым и богатым, чем бедным и больным, но это неконструктивное утверждение.
Это просто клич "авторы, чаще используйте extern "C" __declspec( dllexport )"? Ну ок, будем использовать, но к чему эти разговоры про единое замечательное апи, если его предлагается не то что реализовывать, а даже декларировать своими силами — и следовательно, оно не будет ни таким уж единым, ни таким уж и замечательным.

Quote:Это форма неявного, нечёткого и более хрупкого API. Конкретно его низкоуровневая часть. В твоём высокоуровневом коде всё равно будут функции-обёртки, если делаешь по уму.

Нет, не будут, я же не бессмертный оборачивать все, что у нас там нареверсено, под обертки.
¯\_(ツ)_/¯
Либо тогда мне нужна стоковая поставка из Эры описывающих герои заголовочников, которые по функционалу эквивалентны хотя бы тем, которые когда-то в начале десятых были в последних HD-шных сорцах, 3.15f, кажется. Там немного, килобайт триста.

Алсо
> хрупкое
НD общаться с HotА и HD с плагинами так общаться нехрупко, а тут ну не норм.
И сравнивать с решением, в котором мы будем зависеть как минимум от имени dll-файла плагина и считать это менее хрупким.. ну такое.
И да, оно неявное, нечеткое и низкоуровневое - и это еще не все его достоинства!
Смешно бояться хрупкости в реверсинговой сцене.

Berserker, reporting an issue related to characters/colour
Check this one:
Debug+Save
The menu pops up when fighting a neutral stack is totally messed up.

Checked w/ and w/o WoG Native Dialgos/HD mod, it turns out
1. w/o WoG Native Dialog, the issue can be resolved.
2. w/o HD, the issue persists.

This could be a problem with WoG Naitve Dialog, but since ERA gets so many updates related to characters/colour recently, I believe it's more likely needed to be adjust from ERA

(14.12.2020 19:04)XEPOMAHT Wrote:  

(14.12.2020 18:41)Berserker Wrote:  Эра+ — потенциальная сборка. С ней просто не включать неудобные плагины, дублирующие функциональность. Это же решается в два щелчка. Нет?

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

Подписываюсь под Вашими словами. В качестве варианта реализации могу предложить использование текстовика или ini-файла, лежащего в папке с модом, который будет считываться одновременно с list.txt, и в котором будут указаны моды, которые нужно отключить. Соответственно, при чтении списка модов нужно просто пробегаться циклом по этому списку исключений и проводить сравнение с данными из, например, mod.json или ещё откуда-нибудь.

(15.12.2020 13:50)Raistlin Wrote:  В качестве варианта реализации могу предложить использование текстовика или ini-файла, лежащего в папке с модом, который будет считываться одновременно с list.txt, и в котором будут указаны моды, которые нужно отключить. Соответственно, при чтении списка модов нужно просто пробегаться циклом по этому списку исключений и проводить сравнение с данными из, например, mod.json или ещё откуда-нибудь.

Думаю, что вместо чёрного списка модов лучше использовать белый список - проверенные на совместимость моды. Т.е. пользователь подключает ERA+, перед загрузкой движок ERA рядом с list.txt находит whitelist.txt, сравнивает содержимое с list.txt и подгружает только моды, имена которых совпали в обоих листах. Пользователь отключает ERA+, и моды уже грузятся согласно list.txt (т.е. список модов, который пользователь мог собирать и настраивать под себя годами, никак не повреждается от включения/выключения ERA+, т.е. всё проходит автоматически и мне потом не нужно уговаривать людей УСТАНАВЛИВАТЬ ERA+ В ОТДЕЛЬНУЮ ПАПКУ С ГЕРОЯМИ, ЧТОБЫ НИКАКИЕ СТОРОННИЕ МОДЫ НЕ МЕШАЛИ ПОЛЬЗОВАТЕЛЯМИ, КОТОРЫЕ В НИХ НИЧЕГО НЕ ПОНИМАЮТ И ХОТЯТ ТОЛЬКО ИГРАТЬ В САМУ ИГРУ ).

Имхо, это уровень ответственности настроек мода в json и менеджера модов. Менеджер модов должен предупреждать о несовместимых модах по набору критериев: явные чёрные списки и и явные белые.

Archer30, thank you. My bug, will be fixing it.

(15.12.2020 19:25)Berserker Wrote:  Менеджер модов должен предупреждать о несовместимых модах по набору критериев: явные чёрные списки и и явные белые.

Вообще-то Менеджер Модов не является приложением Win32 не работает в виндовозах младше 7-й. Лично мне он за всю историю ни разу не пригодился (не запускается, и не надо) и всецело заменим обычным блокнотом, т.к. только управляет содержимым list.txt (чем я кстати не занимаюсь, как 5 лет прописал там 4 мода, так они там и остаются). Ну а винить-то будут опять ERA+, в том что не смогут её запустить, а никак не Менеджер Модов. Мне вот не хотелось бы решать проблемы этого самого Менеджера (который всё равно ничего не знает о ERA+ и совместимых с ним модов).

У твоей аудитории уже давно стоят Windows 10. И да, они пользуются менеджером модов.

Berserker, help needed with SN:D/BU:R
How exactly does these work? Why are they sometimes result in crashes that only reproducable in particular PC?

From discord:

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

debug - This is a crash realated to SN:D from 40 Karmic Battles.

I had this report a week ago. I tested with the savegame the player sent and not able to reproduced his issue, while he had a very high chance of crash (like every 3 battles). I thought that was only a rare situation. But since now I see the second report, it must be something.

SN:D calls BU:R. BU:R crashes if called on round 0. That's all I know. Thanks for report.

Seems like some def was not loaded still and BU:R requires it.

Ah, seems like BU:R in autobattle is a bit unsafe.