Нативная сборка работает только в режиме Рабочего Стола и только на PC. А ты забыл про телефоны, планшеты, Windows Phone и т.п
После замены файлов перезаписью на самую последнюю версию у меня при входе в город, у которого стоит музыкальная тема во FLAC, стало появляться окошко с ошибкой. Я так понимаю, нужна какая-то системная библиотека более новая?
Кстати, тут наткнулся на Palm Heroes (open source)
sourceforge.net/projects/palmheroes/
Код там 2010 года, но возможно, что-то можно будет взять оттуда.
Кстати, тут наткнулся на Palm Heroes (open source)
sourceforge.net/projects/palmheroes/Код там 2010 года, но возможно, что-то можно будет взять оттуда.
Лицензия не позволяет брать оттуда код - не совместимы apache и GPL. На этом вопрос можно закрыть
на w7 64 бита у меня нет автосохранения
на w7 64 бита у меня нет автосохранения
В логах что написано?
Вопрос к разработчикам:
- что поспособствовало тому, что в качестве языка описания был выбран JSON?
Почему не XML, например, кажется - он более интуитивен…
Вопрос к разработчикам:
- что поспособствовало тому, что в качестве языка описания был выбран JSON?
Почему не XML, например, кажется - он более интуитивен…
Macron1, благодарю! Жаль, других инструментов нет!
Всё же отвечу!
Даже из этой статьи, благоговейно рекомендованной мне одним из респектабельных наших форумчан - не понял решительной разницы между XML и JSON (кроме читабельности, но я её не заметил) - все равно всё генерируется и читается программой.
Повышенную читабельность - не заметил, зато отсутствие компонентов для работы с JSON в среде DELPHI XE8, особенно для Android - сильно демотивировало!
в среде DELPHI XE8
Мсье знает толк в некрофилии.
PS Я так понимаю, формат плох тем, что его не осилили дельфисты?
UPD
Первая же ссылка в поисковике выдала мне эту статью
webdelphi.ru/2011/10/rabota- … -2010-xe2/
Всё же отвечу!
все равно всё генерируется и читается программой.
То что все генерируется программой - это вкорне неверно. Програаммно генерируется на данный момент только сохранение настроек (“modSettings.json” “settings.json” ) остальное все написано руками (ну не все есть часть файлов изначально сконвертированных программно), и вручную писать JSON удобнее.
отсутствие компонентов для работы с JSON в среде DELPHI XE8, особенно для Android - сильно демотивировало!
А какое отношение DELPHI XE8 имеет к VCMI?
Да как бы и никакого, но это моя рабочая среда, и жалко, что если понадобится преобразование карт в формат JSON, а особенно - преобразование карт в формате JSON по некоторому алгоритму - парсер придётся писать самому.
Да как бы и никакого, но это моя рабочая среда, и жалко, что если понадобится преобразование карт в формат JSON, а особенно - преобразование карт в формате JSON по некоторому алгоритму - парсер придётся писать самому.
Парсер из фрипаскаля заставить работать под дельфи не проблема, а там он есть.
Вопрос к разработчикам:
- что поспособствовало тому, что в качестве языка описания был выбран JSON?
Почему не XML, например, кажется - он более интуитивен…
Более интуитивен? Лично мне всегда казалось что пары ключ-значение более интуитивно понятны чем открытие ключа - значение - закрытие ключа
"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
Понятно. Если быстрее - тогда правильно.
Но мне страшновато увидеть json-модификацию карт! Заголовок - ладно. А сам массив тайлов с дорогами, реками и зеркалами?
Могу скинуть примерчик не так там все и страшно:)
В общем - понятно.
Порадовало:
// list of triggered events that denote computer-readable victory/defeat conditions
"triggeredEvents" : { <list of triggered events, see below> }
Но это:
“dt10”, “dt13pc3”, “dt12” ],
“wt26”, “wt03pc3”, “dt12” ],
“wt64”, “wt34pc3”, “dt12rw4” ]
]
всё равно нечитабельно, - чем семибайтовая последовательность была бы хуже? Пусть даже в варианте “#05#00#01#28#FC#1B#08”.
И вот это:
//mandatory, unique; level depth "depth": 0, //0=surface, 1 underground.
Player color names red, blue, tan, green, orange, purple, teal, pink
То есть расширяемости здесь ожидать не стоит? Карты всегда будут 1-2 слойными, игроков - не больше 8, и даже почвы или реки добавить не получится?