07.03.2012, 18:23
О, вот это уже тема! Кстати, ты потом добавишь acks и quests из сингла?
Я сейчас возьмусь за заполнение колонок.
Я сейчас возьмусь за заполнение колонок.
Распаковка базы Database(lmp).res
|
07.03.2012, 18:23
О, вот это уже тема! Кстати, ты потом добавишь acks и quests из сингла?
Я сейчас возьмусь за заполнение колонок.
07.03.2012, 18:50
Demoth,Среда, 07 Марта 2012, 17:23 Написал:О, вот это уже тема! Кстати, ты потом добавишь acks и quests из сингла?Да, как будет время, думаю добавить их для полноты картины.
Обновленные файлы:[attachment=794]Заполнил типы для Units а также имена для Hit Locations и Race Models,
взятые из EIedit. Еще добавил Acks и Quests, правда надо в фильтр открытия файлов добавить *.qdb. В ближайшее время допишу оставшиеся имена в Units и Items. Надеюсь ты в скором времени допилишь поддержку пользовательских структур. P.S. Может стоит сделать импорт/экспорт txt?
Пофиксил поддержку вложенных структур.
Немного более адекватно обозвал некоторые типы полей. Поправил некоторые некорректные типы полей. Убрал необходимость писать дополнительные блоки (XBlockID) в dbblocks.txt. Сделал поддержку кодировок (в файле settings.ini). Добавил в фильтры маску *.qdb. Как будет время, попробую сделать импорт/экспорт в файлы экзеля. За традиционные текстовики возьмусь после этого, так как в текстовиках зарыта ещё куча нюансов по преобразованию данных в разные удобные виды. В случае работы с экзелем напрямую, все нюансы можно будет переложить собственно на экзель. По крайней мере мне пока что так кажется. Как там будет в реальности - увидим.
10.03.2012, 11:08
Кстати, может стоит ширину колонки определять по длине ее названия, либо по максимальной ширине данных внутри нее (тут правда будет фэил с перечислением строк - уж очень длинные могут быть, этот вариант можно применять к числовым данным).
10.03.2012, 22:10
Demoth,Суббота, 10 Марта 2012, 10:08 Написал:Кстати, может стоит ширину колонки определять по длине ее названия, либо по максимальной ширине данных внутри нее (тут правда будет фэил с перечислением строк - уж очень длинные могут быть, этот вариант можно применять к числовым данным).Подумаю над этим. Чего-то в Qt вроде бы не всё так просто с автошириной колонок.
А, ну да, еще одна приятная мелочушка - если тип первого столбца String, тогда выводить в строке состояния эту строку для текущей строки таблицы. (Просто как правило, если там стринг, то это Name, а его всегда под рукой желательно иметь - отматывать постоянно влево не очень удобно...)
В принципе, эту идею можно прокачать до поиска строки при вводе первых символов имени, что-то вроде быстрого перехода. Т.е. когда сфокусировано на самой таблице (т.е. не в момент редактирования конкретного элемента) то обработчик нажатия клавиш можно былобы приспособить для перехода к нужной строке таблицы, т.е. скролл по вертикали.
14.03.2012, 13:41
Слегка обновил версию: зафиксировал первую колонку.
16.03.2012, 02:02
Обновил версию.
Теперь утилитка поддерживает импорт из экзелевых файлов XLSX. В папке с программой лежит пример экзелевого файла для импорта. Импортер ориентируется по названиям колонок, начинающихся с FLD. Название каждого листа должно совпадать с кодовым названием блока (см. файл dbblocks.txt). В ячейках допускается использовать формулы, импортер будет брать только рассчитанные значения. Это позволяет несколько (или же существенно, зависит от уровня владения экзелем) автоматизировать ввод значений, а также расчёт баланса. В принципе все непонятные простому смертному модостроителю колонки можно задвинуть куда-нибудь вправо (главное, чтобы там в заголовке колонки как положено было FLD) и рассчитывать их значения автоматически. А все информационно полезные колонки (в т.ч. и свои созданные) держать на виду. В общем, кому как удобнее, так и делайте. Что остаётся: * Доопределить нормально поля * Сделать более полный пример экзелевой датабазы * Сделать автоширину колонок * Сделать экспорт в экзель Последние два пункта я как-нибудь когда-нибудь сделаю. А вот с первыми двумя пунктами может помочь любой желающий. В качестве награды -- запись в окошке About данной проги.
16.03.2012, 19:02
А что понимается под "определением полей"?
16.03.2012, 19:03
Це я был выше
Duty is everything, the greatest of joys, the deepest of sorrows.
16.03.2012, 19:46
Привет, Altair
Доопределить -- это расписать типы (integer/string/struct/etc...) и названия полей. Там в текстовых файлах сделаны записи о том, какой должен быть тип у каждого поля, а также как каждое поле должно называться. В принципе наверно можно просто переписать типы и названия из исходников EiEdit. Или из любого другого удобного исходника. По-идее это не должно быть большой проблемой, главное сделать. У меня руки не доходят. Сейчас типы полей записаны: * для файла Items * частично для Spells (только Spell Prototypes и Spell Modifiers) * для Levers * для Prints (но нужно проверить, не перепутаны ли названия блоков Blood и Foot Prints) * для Units Соответственно нужно доопределить типы: * оставшиеся для Spells * для Perks * для Acks и Quests (для SP) Описания типов полей хранятся в файле dbtypes.txt. Названия же колонок пока что описаны хуже. Они готовы: * для Materials и Weapons из файла Items * для Spell Prototypes и Spell Modifiers из файла Spells * для Hit Locations и Race Models из файла Units Для остальных блоков названия ещё не вписаны. Соответственно нужно бы вписать. Хоть из того же EiEdit. Описания названий полей хранятся в отдельном файле dbheaders.txt (в отдельном, так как если например полю задать тип FloatList, то вместо этого поля получается сразу список полей, для которых нужны разные названия -- соответственно файл dbheaders оперирует с уже разобранными типами полей).
19.03.2012, 00:01
Немного обновил версию.
Зделал автоширину колонок, если в dbheaders.txt на месте ширины указать 0. Но автоширина пока что считается только по тексту хедера. Не по содержимому.
И ещё раз обновил версию.
Файл Acks подбросил очередной сюрприз в виде списка структур. Так и не придумал, как оптимально и наглядно отобразить это нечто, скорее всего оптимальным для Acks является не табличный вид. Но пока что нетабличные вкладки я делать не хочу (лень). Потому список структур превращается в специально отформатированную строку. Соответственно для этой цели был введён очередной новый тип. В общем, 99,9% типов всех полей определены. Могут быть мелкие недочёты и огрехи (и если обнаружите их - пишите ). Также добавил маленькую полезную фичу: если выделить всю таблицу целиком, то при копировании скопируются не только данные, но и заголовок, причём в таком формате, в котором его можно вставить в экзель, сохранить (переименовав лист на имя скопированной таблицы) и спокойно импортировать. То есть это такая недофункция экспорта. Соответственно сделал более полный пример экзелевского файла. Там теперь все блоки базы данных в одном файле. По-идее колонки можно менять местами и разбрасывать (не двигая по вертикали разумеется). Можно использовать формулы, в т.ч. и между листами (между блоками инфы). Ну и остаётся собственно правильно назвать все эти колонки. Они ещё не названы как положено. А так вроде бы всё. На всякий, продублирую ссылку, чтобы не искали: EIDBEditor
А интегрировать сюда же работу с анимационными *.adb базами ты не планируешь?
А вообще, я много думал по поводу аналогичного редактора, много мыслекопий поломал, но в итоге пришел к одному простому решению, которое, правда, так и не реализовал пока из-за лени и нехватки времени Если задаться вопросом, что нужно-то вообще обычному модмейкеру от базы? Только лишь возможность прописать туда новые строчки в таблички или поменять какие-то оригинальные значения. Всего этого можно добиться, если реализовать базу в виде обычного экселевского файла, который по макросу будет экспортировать все данные в текстовый формат совместимый с нивальскими утилитами упаковки базы. Единственная назойливая сложность тут - первоначальное заполнение этого экселевского документа. Ну а такая утилита будет полезна в том случае, когда захочется "вскрыть" базу любого стороннего разработчика (т.е. чужого мода), что бывает, в общем-то, сильно редко Если же даже и делать такую утилиту, то, имхо, надо делать либо полноценный двусторонний конвертор database.res <-> database.xls, либо крутую гуёвую программулину, которая по функционалу управления таблицами не будет уступать хотя бы базовой версии экселя, при этом будет работать с оригинальным файлом database.res, а не с текстовыми, распакованными или экселевскими вариантами той же базы.
Duty is everything, the greatest of joys, the deepest of sorrows.
*.adb действительно думаю также задействовать. Только вот думаю, в какой бы вид лучше это всё конвертить. Одни только блоки данных составляют около 20 страниц экзеля, по ним навигировать уже не очень удобно. А *.adb могут жеж ещё несколько десятков листов набросить. Думаю, может быть их как-нибудь в отдельный файл выконвертивать.
В принципе я и рассчитываю добавить поддержку прямой работы с database.res и в итоге сделать именно такой конвертер : database.res <-> database.xlsx (ну или типа того). Гуи особо сильно наворачивать не хочу, он просто для оперативного доступа и чтобы поиграться. Вообще ещё посещала мысль сделать вариант экспорта/импорта не только в *.xlsx, но и в кучку файлов .xml. Вообще, интересно узнать, вот с точки зрения современной разработки игрухи: * в чём лучше хранить подобные игровые данные (характеристики айтемов, заклов, персов, etc)? * и в чём лучше хранить анимационную инфу, как и где её по-хорошему обычно сейчас хранят? Просто есть желание как бы наперёд этой тулзе дать возможность конвертить в удобный современный формат хранения подобной инфы.
Обновил версию.
Теперь прога умеет напрямую читать из *.res. Но ещё пока что не пишет. :wacko: Я так и не разобрался, как там считается контрольная сумма у файла. Если кто подскажет, то буду очень благодарен. Также demoth расписал названия полей для Units. А также поправил нехорошую ошибку в окоше About (чё там было написано не скажу ) и сменил лицензию с GPL на более мягкую LGPL (так, на всякий случай).
21.03.2012, 07:29
ELF, а ты список учитывал? Там массив записей образует хэш таблицу.
21.03.2012, 11:18
Ух, не разбираюсь я в этих нюансах. Ну, допустим, что хэш-таблица по факту есть, а вот как в ней адресуются элементы, и как вычисляется тогда хэш-функция -- непонятно.
21.03.2012, 11:55
Хеш функция = сумма символов % количество файлов. Если в хеши совпадают, то в первом элементе записывается номер следующего файла с таким же хешом. Т.е. при запаковке в первую очередь записываются файлы без повторения хешей а потом все оставшиеся в произвольном порядке.
|
« Предыдущая | Следующая »
|