Russian thread

Нативная сборка работает только в режиме Рабочего Стола и только на PC. А ты забыл про телефоны, планшеты, Windows Phone и т.п

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


Кстати, тут наткнулся на Palm Heroes (open source)
sourceforge.net/projects/palmheroes/

Код там 2010 года, но возможно, что-то можно будет взять оттуда.


Лицензия не позволяет брать оттуда код - не совместимы apache и GPL. На этом вопрос можно закрыть

на w7 64 бита у меня нет автосохранения

В логах что написано?

Вопрос к разработчикам:

  • что поспособствовало тому, что в качестве языка описания был выбран JSON?
    Почему не XML, например, кажется - он более интуитивен…

habrahabr.ru/post/31225/

Macron1, благодарю! Жаль, других инструментов нет!

Всё же отвечу!
Даже из этой статьи, благоговейно рекомендованной мне одним из респектабельных наших форумчан - не понял решительной разницы между XML и JSON (кроме читабельности, но я её не заметил) - все равно всё генерируется и читается программой.
Повышенную читабельность - не заметил, зато отсутствие компонентов для работы с JSON в среде DELPHI XE8, особенно для Android - сильно демотивировало!

Мсье знает толк в некрофилии.
PS Я так понимаю, формат плох тем, что его не осилили дельфисты?

UPD
Первая же ссылка в поисковике выдала мне эту статью
webdelphi.ru/2011/10/rabota- … -2010-xe2/

То что все генерируется программой - это вкорне неверно. Програаммно генерируется на данный момент только сохранение настроек (“modSettings.json” “settings.json” ) остальное все написано руками (ну не все :slight_smile: есть часть файлов изначально сконвертированных программно), и вручную писать JSON удобнее.

А какое отношение DELPHI XE8 имеет к VCMI?

Да как бы и никакого, но это моя рабочая среда, и жалко, что если понадобится преобразование карт в формат JSON, а особенно - преобразование карт в формате JSON по некоторому алгоритму - парсер придётся писать самому.

Парсер из фрипаскаля заставить работать под дельфи не проблема, а там он есть.

Более интуитивен? Лично мне всегда казалось что пары ключ-значение более интуитивно понятны чем открытие ключа - значение - закрытие ключа

"army" : {
    { "type": "pikeman", "amount" : 8 },
    { "type": "archer", "amount" : 3 },
}

<army>
    <slot type="pikeman"><amount>8<amount/></slot>
    <slot type="archer"><amount>3<amount/></slot>
</army>

Расчет был на то, что все описание будут составлятся вручную. Редактор карт, пожалуй, единственное исключение где автогенерация безусловно нужна.

Еще один плюс - простота формата. Парсить json намного быстрее чем парсить xml. Теоретически, мы могли бы взять готовую xml библиотеку, но она бы все равно была бы медленнее чем библиотека работающая с json. Для vcmi это критично - насколько я помню, сейчас парсинг конфигов занимает заметную долю загрузки.

Да, минус json это то что он менее популярен чем xml и как результат - меньше всяких библиотек готовых. Но нам намного критичнее была простота парсинга и человекочитаемость.

Понятно. Если быстрее - тогда правильно.
Но мне страшновато увидеть json-модификацию карт! Заголовок - ладно. А сам массив тайлов с дорогами, реками и зеркалами? В xml я бы это реализовал через [CDATA] - а есть ли подобное в json? В каком виде включать ERM и LUA код?

Гдето на нашей вики есть страница с наброском формата карт. Можешь поискать, глянуть детали.
Вкратце, карта это архив с несколькими json файлами:
Заголовок для быстрого парсинга
Все объекты карты
По файлу для террейна каждого уровня.

Террейн записывается как двумерный массив, элементы это строки с закодированным описанием тайла. Кодирование нужно опять же для скорости. Посимвольно распарсить строку будет быстрее чем полноценный конфиг, к которому к тому же доступ только через дорогое сравнение строк

А вот вики wiki.vcmi.eu/index.php?title=Map_format

Могу скинуть примерчик не так там все и страшно:)

В общем - понятно.
Порадовало:

Но это:

всё равно нечитабельно, - чем семибайтовая последовательность была бы хуже? Пусть даже в варианте “#05#00#01#28#FC#1B#08”.
И вот это:

То есть расширяемости здесь ожидать не стоит? Карты всегда будут 1-2 слойными, игроков - не больше 8, и даже почвы или реки добавить не получится?