07.03.2012, 18:23
07.03.2012, 18:50
Demoth,Среда, 07 Марта 2012, 17:23 Написал:О, вот это уже тема! Кстати, ты потом добавишь acks и quests из сингла?Да, как будет время, думаю добавить их для полноты картины.
Я сейчас возьмусь за заполнение колонок.
[right][snapback]41138[/snapback][/right]
08.03.2012, 16:04
09.03.2012, 04:39
Пофиксил поддержку вложенных структур.
Немного более адекватно обозвал некоторые типы полей.
Поправил некоторые некорректные типы полей.
Убрал необходимость писать дополнительные блоки (XBlockID) в dbblocks.txt.
Сделал поддержку кодировок (в файле settings.ini).
Добавил в фильтры маску *.qdb.
Как будет время, попробую сделать импорт/экспорт в файлы экзеля. За традиционные текстовики возьмусь после этого, так как в текстовиках зарыта ещё куча нюансов по преобразованию данных в разные удобные виды. В случае работы с экзелем напрямую, все нюансы можно будет переложить собственно на экзель. По крайней мере мне пока что так кажется. Как там будет в реальности - увидим.
Немного более адекватно обозвал некоторые типы полей.
Поправил некоторые некорректные типы полей.
Убрал необходимость писать дополнительные блоки (XBlockID) в dbblocks.txt.
Сделал поддержку кодировок (в файле settings.ini).
Добавил в фильтры маску *.qdb.
Как будет время, попробую сделать импорт/экспорт в файлы экзеля. За традиционные текстовики возьмусь после этого, так как в текстовиках зарыта ещё куча нюансов по преобразованию данных в разные удобные виды. В случае работы с экзелем напрямую, все нюансы можно будет переложить собственно на экзель. По крайней мере мне пока что так кажется.
Как там будет в реальности - увидим. 10.03.2012, 11:08
10.03.2012, 22:10
Demoth,Суббота, 10 Марта 2012, 10:08 Написал:Кстати, может стоит ширину колонки определять по длине ее названия, либо по максимальной ширине данных внутри нее (тут правда будет фэил с перечислением строк - уж очень длинные могут быть, этот вариант можно применять к числовым данным).Подумаю над этим.
[right][snapback]41143[/snapback][/right]
Чего-то в Qt вроде бы не всё так просто с автошириной колонок. 11.03.2012, 16:58
А, ну да, еще одна приятная мелочушка - если тип первого столбца String, тогда выводить в строке состояния эту строку для текущей строки таблицы. (Просто как правило, если там стринг, то это Name, а его всегда под рукой желательно иметь - отматывать постоянно влево не очень удобно...) 
В принципе, эту идею можно прокачать до поиска строки при вводе первых символов имени, что-то вроде быстрого перехода. Т.е. когда сфокусировано на самой таблице (т.е. не в момент редактирования конкретного элемента) то обработчик нажатия клавиш можно былобы приспособить для перехода к нужной строке таблицы, т.е. скролл по вертикали.
В принципе, эту идею можно прокачать до поиска строки при вводе первых символов имени, что-то вроде быстрого перехода. Т.е. когда сфокусировано на самой таблице (т.е. не в момент редактирования конкретного элемента) то обработчик нажатия клавиш можно былобы приспособить для перехода к нужной строке таблицы, т.е. скролл по вертикали.
14.03.2012, 13:41
Слегка обновил версию: зафиксировал первую колонку.
16.03.2012, 02:02
Обновил версию.
Теперь утилитка поддерживает импорт из экзелевых файлов XLSX.
В папке с программой лежит пример экзелевого файла для импорта. Импортер ориентируется по названиям колонок, начинающихся с FLD.
Название каждого листа должно совпадать с кодовым названием блока (см. файл dbblocks.txt).
В ячейках допускается использовать формулы, импортер будет брать только рассчитанные значения. Это позволяет несколько (или же существенно, зависит от уровня владения экзелем) автоматизировать ввод значений, а также расчёт баланса.
В принципе все непонятные простому смертному модостроителю колонки можно задвинуть куда-нибудь вправо (главное, чтобы там в заголовке колонки как положено было FLD) и рассчитывать их значения автоматически. А все информационно полезные колонки (в т.ч. и свои созданные) держать на виду. В общем, кому как удобнее, так и делайте.
Что остаётся:
* Доопределить нормально поля
* Сделать более полный пример экзелевой датабазы
* Сделать автоширину колонок
* Сделать экспорт в экзель
Последние два пункта я как-нибудь когда-нибудь сделаю. А вот с первыми двумя пунктами может помочь любой желающий. В качестве награды -- запись в окошке About данной проги. 
Теперь утилитка поддерживает импорт из экзелевых файлов XLSX.
В папке с программой лежит пример экзелевого файла для импорта. Импортер ориентируется по названиям колонок, начинающихся с FLD.
Название каждого листа должно совпадать с кодовым названием блока (см. файл dbblocks.txt).
В ячейках допускается использовать формулы, импортер будет брать только рассчитанные значения. Это позволяет несколько (или же существенно, зависит от уровня владения экзелем) автоматизировать ввод значений, а также расчёт баланса.
В принципе все непонятные простому смертному модостроителю колонки можно задвинуть куда-нибудь вправо (главное, чтобы там в заголовке колонки как положено было FLD) и рассчитывать их значения автоматически. А все информационно полезные колонки (в т.ч. и свои созданные) держать на виду. В общем, кому как удобнее, так и делайте.
Что остаётся:
* Доопределить нормально поля
* Сделать более полный пример экзелевой датабазы
* Сделать автоширину колонок
* Сделать экспорт в экзель
Последние два пункта я как-нибудь когда-нибудь сделаю.
А вот с первыми двумя пунктами может помочь любой желающий. В качестве награды -- запись в окошке About данной проги. 16.03.2012, 19:02
16.03.2012, 19:03
Це я был выше
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 оперирует с уже разобранными типами полей).
Доопределить -- это расписать типы (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. Но автоширина пока что считается только по тексту хедера. Не по содержимому.
Зделал автоширину колонок, если в dbheaders.txt на месте ширины указать 0. Но автоширина пока что считается только по тексту хедера. Не по содержимому.
19.03.2012, 06:58
И ещё раз обновил версию.
Файл Acks подбросил очередной сюрприз в виде списка структур. Так и не придумал, как оптимально и наглядно отобразить это нечто, скорее всего оптимальным для Acks является не табличный вид.
Но пока что нетабличные вкладки я делать не хочу (лень). Потому список структур превращается в специально отформатированную строку. Соответственно для этой цели был введён очередной новый тип.
В общем, 99,9% типов всех полей определены. Могут быть мелкие недочёты и огрехи (и если обнаружите их - пишите ).
Также добавил маленькую полезную фичу: если выделить всю таблицу целиком, то при копировании скопируются не только данные, но и заголовок, причём в таком формате, в котором его можно вставить в экзель, сохранить (переименовав лист на имя скопированной таблицы) и спокойно импортировать. То есть это такая недофункция экспорта.
Соответственно сделал более полный пример экзелевского файла. Там теперь все блоки базы данных в одном файле. По-идее колонки можно менять местами и разбрасывать (не двигая по вертикали разумеется). Можно использовать формулы, в т.ч. и между листами (между блоками инфы).
Ну и остаётся собственно правильно назвать все эти колонки. Они ещё не названы как положено.
А так вроде бы всё.
На всякий, продублирую ссылку, чтобы не искали:
EIDBEditor
Файл Acks подбросил очередной сюрприз в виде списка структур. Так и не придумал, как оптимально и наглядно отобразить это нечто, скорее всего оптимальным для Acks является не табличный вид.
Но пока что нетабличные вкладки я делать не хочу (лень). Потому список структур превращается в специально отформатированную строку. Соответственно для этой цели был введён очередной новый тип.
В общем, 99,9% типов всех полей определены. Могут быть мелкие недочёты и огрехи (и если обнаружите их - пишите
).Также добавил маленькую полезную фичу: если выделить всю таблицу целиком, то при копировании скопируются не только данные, но и заголовок, причём в таком формате, в котором его можно вставить в экзель, сохранить (переименовав лист на имя скопированной таблицы) и спокойно импортировать.
То есть это такая недофункция экспорта. Соответственно сделал более полный пример экзелевского файла. Там теперь все блоки базы данных в одном файле. По-идее колонки можно менять местами и разбрасывать (не двигая по вертикали разумеется). Можно использовать формулы, в т.ч. и между листами (между блоками инфы).
Ну и остаётся собственно правильно назвать все эти колонки. Они ещё не названы как положено.
А так вроде бы всё.
На всякий, продублирую ссылку, чтобы не искали:
EIDBEditor
19.03.2012, 13:09
А интегрировать сюда же работу с анимационными *.adb базами ты не планируешь?
А вообще, я много думал по поводу аналогичного редактора, много мыслекопий поломал, но в итоге пришел к одному простому решению, которое, правда, так и не реализовал пока из-за лени и нехватки времени
Если задаться вопросом, что нужно-то вообще обычному модмейкеру от базы? Только лишь возможность прописать туда новые строчки в таблички или поменять какие-то оригинальные значения. Всего этого можно добиться, если реализовать базу в виде обычного экселевского файла, который по макросу будет экспортировать все данные в текстовый формат совместимый с нивальскими утилитами упаковки базы. Единственная назойливая сложность тут - первоначальное заполнение этого экселевского документа.
Ну а такая утилита будет полезна в том случае, когда захочется "вскрыть" базу любого стороннего разработчика (т.е. чужого мода), что бывает, в общем-то, сильно редко
Если же даже и делать такую утилиту, то, имхо, надо делать либо полноценный двусторонний конвертор database.res <-> database.xls, либо крутую гуёвую программулину, которая по функционалу управления таблицами не будет уступать хотя бы базовой версии экселя, при этом будет работать с оригинальным файлом database.res, а не с текстовыми, распакованными или экселевскими вариантами той же базы.
А вообще, я много думал по поводу аналогичного редактора, много мыслекопий поломал, но в итоге пришел к одному простому решению, которое, правда, так и не реализовал пока из-за лени и нехватки времени
Если задаться вопросом, что нужно-то вообще обычному модмейкеру от базы? Только лишь возможность прописать туда новые строчки в таблички или поменять какие-то оригинальные значения. Всего этого можно добиться, если реализовать базу в виде обычного экселевского файла, который по макросу будет экспортировать все данные в текстовый формат совместимый с нивальскими утилитами упаковки базы. Единственная назойливая сложность тут - первоначальное заполнение этого экселевского документа.
Ну а такая утилита будет полезна в том случае, когда захочется "вскрыть" базу любого стороннего разработчика (т.е. чужого мода), что бывает, в общем-то, сильно редко
Если же даже и делать такую утилиту, то, имхо, надо делать либо полноценный двусторонний конвертор database.res <-> database.xls, либо крутую гуёвую программулину, которая по функционалу управления таблицами не будет уступать хотя бы базовой версии экселя, при этом будет работать с оригинальным файлом database.res, а не с текстовыми, распакованными или экселевскими вариантами той же базы.
19.03.2012, 21:12
*.adb действительно думаю также задействовать. Только вот думаю, в какой бы вид лучше это всё конвертить. Одни только блоки данных составляют около 20 страниц экзеля, по ним навигировать уже не очень удобно. А *.adb могут жеж ещё несколько десятков листов набросить. Думаю, может быть их как-нибудь в отдельный файл выконвертивать.
В принципе я и рассчитываю добавить поддержку прямой работы с database.res и в итоге сделать именно такой конвертер : database.res <-> database.xlsx (ну или типа того).
Гуи особо сильно наворачивать не хочу, он просто для оперативного доступа и чтобы поиграться.
Вообще ещё посещала мысль сделать вариант экспорта/импорта не только в *.xlsx, но и в кучку файлов .xml.
Вообще, интересно узнать, вот с точки зрения современной разработки игрухи:
* в чём лучше хранить подобные игровые данные (характеристики айтемов, заклов, персов, etc)?
* и в чём лучше хранить анимационную инфу, как и где её по-хорошему обычно сейчас хранят?
Просто есть желание как бы наперёд этой тулзе дать возможность конвертить в удобный современный формат хранения подобной инфы.
В принципе я и рассчитываю добавить поддержку прямой работы с database.res и в итоге сделать именно такой конвертер : database.res <-> database.xlsx (ну или типа того).
Гуи особо сильно наворачивать не хочу, он просто для оперативного доступа и чтобы поиграться.
Вообще ещё посещала мысль сделать вариант экспорта/импорта не только в *.xlsx, но и в кучку файлов .xml.
Вообще, интересно узнать, вот с точки зрения современной разработки игрухи:
* в чём лучше хранить подобные игровые данные (характеристики айтемов, заклов, персов, etc)?
* и в чём лучше хранить анимационную инфу, как и где её по-хорошему обычно сейчас хранят?
Просто есть желание как бы наперёд этой тулзе дать возможность конвертить в удобный современный формат хранения подобной инфы.
21.03.2012, 04:40
Обновил версию.
Теперь прога умеет напрямую читать из *.res. Но ещё пока что не пишет. :wacko:
Я так и не разобрался, как там считается контрольная сумма у файла.
Если кто подскажет, то буду очень благодарен.
Также demoth расписал названия полей для Units.
А также поправил нехорошую ошибку в окоше About (чё там было написано не скажу
) и сменил лицензию с GPL на более мягкую LGPL (так, на всякий случай).
Теперь прога умеет напрямую читать из *.res. Но ещё пока что не пишет. :wacko:
Я так и не разобрался, как там считается контрольная сумма у файла.
Если кто подскажет, то буду очень благодарен.
Также demoth расписал названия полей для Units.
А также поправил нехорошую ошибку в окоше About (чё там было написано не скажу
) и сменил лицензию с GPL на более мягкую LGPL (так, на всякий случай).21.03.2012, 07:29
21.03.2012, 11:18
Ух, не разбираюсь я в этих нюансах. Ну, допустим, что хэш-таблица по факту есть, а вот как в ней адресуются элементы, и как вычисляется тогда хэш-функция -- непонятно.
Ну, допустим, что хэш-таблица по факту есть, а вот как в ней адресуются элементы, и как вычисляется тогда хэш-функция -- непонятно. 21.03.2012, 11:55