Russian thread


#561

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


#562

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



#563

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

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


#564


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


#565

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


#566

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


#567

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

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

#568

habrahabr.ru/post/31225/


#569

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


#570

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


#571

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

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


#572

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


#573

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


#574

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


#575

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


#576

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

"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 и как результат - меньше всяких библиотек готовых. Но нам намного критичнее была простота парсинга и человекочитаемость.


#577

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


#578

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

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

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


#579

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


#580

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

Но это:

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

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