21.03.2012, 13:40
21.03.2012, 19:55
Robin, спасибо большое! ![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
04.04.2012, 02:43
Обновил версию проги. ![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
* Сделал прямую запись в RES
* Сделал прямую запись в XLSX
* Соответственно сделал возможным вызывать прогу с параметрами командной строки![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
* Сделал одну кнопку для загрузки всех форматов (RES/XLSX/*db)
* Теперь когда прога сохраняет в RES, она оставляет оригинальные неподдерживаемые файлы (например пока что adb) из оригинального RES. А если оригинального RES не было (т.е. например работали изначально с XLSX), то сохраняются оригинальные неподдерживаемые файлы конечного RES файла (если он уже был).
* Добавил функцию последних 5-ти загрузок![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
* Дописал названия полей
* Написал readme.txt о том, что может быть непонятно![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
С командной строкой работать так:
dbeditor.exe pathtofilename.res <- сделает pathtofilename.xlsx
dbeditor.exe pathtofilename.xlsx <- сделает pathtofilename.res
Так как прога не консольная, то нужно учитывать, что она сразу же после вызова возвращает управление, не дожидаясь своего завершения. Если нужно дождаться завершения работы проги в консоле, тогда нужно, например, вызывать так:
start /wait dbeditor.exe pathtofilename.res
Соответственно получается ещё один сценарий работы с прогой:
* Бросаем res файл на прогу и получаем рядом с ним xlsx
* Бросаем xlsx файл на прогу и получаем рядом с ним res
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
* Сделал прямую запись в RES
* Сделал прямую запись в XLSX
* Соответственно сделал возможным вызывать прогу с параметрами командной строки
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
* Сделал одну кнопку для загрузки всех форматов (RES/XLSX/*db)
* Теперь когда прога сохраняет в RES, она оставляет оригинальные неподдерживаемые файлы (например пока что adb) из оригинального RES. А если оригинального RES не было (т.е. например работали изначально с XLSX), то сохраняются оригинальные неподдерживаемые файлы конечного RES файла (если он уже был).
* Добавил функцию последних 5-ти загрузок
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
* Дописал названия полей
* Написал readme.txt о том, что может быть непонятно
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
С командной строкой работать так:
dbeditor.exe pathtofilename.res <- сделает pathtofilename.xlsx
dbeditor.exe pathtofilename.xlsx <- сделает pathtofilename.res
Так как прога не консольная, то нужно учитывать, что она сразу же после вызова возвращает управление, не дожидаясь своего завершения. Если нужно дождаться завершения работы проги в консоле, тогда нужно, например, вызывать так:
start /wait dbeditor.exe pathtofilename.res
Соответственно получается ещё один сценарий работы с прогой:
* Бросаем res файл на прогу и получаем рядом с ним xlsx
* Бросаем xlsx файл на прогу и получаем рядом с ним res
04.04.2012, 15:34
Молодец! Отличная прога!!! Так держать!
04.04.2012, 17:05
Си-иба ![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
13.04.2012, 11:11
ELF, в последней версии EIDB Editor'а довольно странный и противный баг с SignedLong полями. А именно при редактировании или импортировании из xlsx он прибавляет к отрицательным числам 1. В итоге хочешь к примеру записать -1 а он выдает 0, хочешь записать -2 а на деле -1. ><
13.04.2012, 16:19
Гы) вот так баг
попробуем разобраться на досуге =)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
13.04.2012, 23:56
Забавная программа
я даже попытался почитать исходный код...) Правда что-то там всего много. Неужели в Qt нету встроенных таблиц? Кстати я удивлён, увидев, что pragma влияет на g++. Если верить тому, что я читал раньше, он должен был бы их игнорить. (я не говорю что я собирал твою программу под Linux. Никогда не собирал ничего под Qt. Под GTK+ да, под XLib да, под Qt - никогда
) В коде кстати есть довольно странное условие, не знаю, так и надо или нет... if( offset < 0 || size < 0 )... бессмысленный код
вроде if(false). Ведь offset и size по типу quint32, беззнаковые. (строки 79-81 файла qresreader.cpp ). И перевод из чисел в адрес клетки и из клетки в адрес можно было бы написать проще, за один проход и без дополнительных переменных.
Кстати, а где вообще нужны signed long? я посмотрел таблицы, там не было чисел больше 2^31-1.
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
Кстати, а где вообще нужны signed long? я посмотрел таблицы, там не было чисел больше 2^31-1.
14.04.2012, 00:10
Невнимательно смотрел значит.
К примеру (первое что пришло в голову) это номер волос - значение от -1 до 1(или двух, не помню
)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
14.04.2012, 00:52
Поправил баг с отрицательными значениями.
Проблема была в том, что это я так округлял значения... по-эльфийски. Сделал по-человечески (возможно).![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
KnightL, сиба большое за отзыв.![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
Где-то по-началу ещё было стремление, чтобы всё было аккуратно и красиво, но потом захотелось побыстрее, да и изучение форматов *db постепенно подбрасывало такие сюрпризы, которые изначальную концепцию чтения данных ставили с ног на голову ( или с головы на ноги, если смотреть относительно хода мыслей разработчиков игры
). Поэтому я решил сначала добиться полного чтения db-файлов, а потом уже отдельно посмотреть на это с позиции "когда уже всё известно".
Сейчас я пришёл к выводу, что вообще *db-файлы лучше считывать по принципу загрузки XML (родитель->дочерние элементы->братья родителя...). Это бы, думаю, упростило бы структуру считывателя с точки зрения восприятия кода. Соответственно настройку разбора формата (текстовые файлы) нужно было бы делать иначе (или теперь вообще уже не делать, так как все структуры уже довольно ясно выреверсированы). Но пока что всё осталось вот так, в виде спагетти внутри методов.![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
А вообще я сейчас в промежутках между жизнью делаю сферический в вакууме класс для работы с большими Res-архивами...
Как сделаю - выложу. Может быть кому пригодится.
Потом думаю сделать такой же сферический для *db-файлов... но пока что не знаю, как этот класс функционально оформить... в играх, как я понял, такие вещи оформляют в виде "системы работы с ресурсами" - некий класс фабрика объектов, который когда нужно грузит ресурсы и даёт нам доступ к ним в виде различных игровых объектов (или ссылок на них)...
Вообще у кого есть опыт в разработке игр, было бы неплохо узнать мнение, как лучше грузить такие *db в гипотетическую игру.![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
Как понял, разработчики библиотеки желают сразу же приобщить пользователя библиотеки к парадигме: модель->представление. Т.е. создаётся модель в виде таблицы, которая подключается к представлению в виде таблицы.
В самом общем (сферическом) случае модель в Qt позволяет создать, так скажем, табличную иерархию таблиц (где ячейка таблицы может адресовать вложенную таблицу). Соответственно, частными случаями этой мега-модели являются список, таблица и просто дерево.
В принципе "создать таблицу в Qt" -- это создать табличную модель. Хотя интерфейс управления такой таблицей мне не пришёлся по вкусу, так как он слишком универсален и неудобен для плотной работы с таблицей. Поэтому я сделал враппер (класс-обёртку) с более дружественным интерфейсом для работы с таблицами.
С одной стороны, плюсом подхода модель-представление является гибкость: не обязательно держать в памяти данные таблицы как есть, можно некоторые из них вычислять и применять динамически. Что порой очень удобно и эффективно. Но, с другой стороны, в простых случаях такой подход довольно громоздкий.
Порой такие поля попадаются.
Вообще очень приятно было услышать твоё мнение. Спасибо за замечания.![Rolleyes Rolleyes](https://www.gipat.ru/forum/images/smilies/rolleyes.png)
Проблема была в том, что это я так округлял значения... по-эльфийски. Сделал по-человечески (возможно).
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
KnightL, сиба большое за отзыв.
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:я даже попытался почитать исходный код...) Правда что-то там всего много.[right][snapback]41199[/snapback][/right]Код действительно написан довольно грязно.
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
Сейчас я пришёл к выводу, что вообще *db-файлы лучше считывать по принципу загрузки XML (родитель->дочерние элементы->братья родителя...). Это бы, думаю, упростило бы структуру считывателя с точки зрения восприятия кода. Соответственно настройку разбора формата (текстовые файлы) нужно было бы делать иначе (или теперь вообще уже не делать, так как все структуры уже довольно ясно выреверсированы). Но пока что всё осталось вот так, в виде спагетти внутри методов.
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
А вообще я сейчас в промежутках между жизнью делаю сферический в вакууме класс для работы с большими Res-архивами...
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
Потом думаю сделать такой же сферический для *db-файлов... но пока что не знаю, как этот класс функционально оформить... в играх, как я понял, такие вещи оформляют в виде "системы работы с ресурсами" - некий класс фабрика объектов, который когда нужно грузит ресурсы и даёт нам доступ к ним в виде различных игровых объектов (или ссылок на них)...
Вообще у кого есть опыт в разработке игр, было бы неплохо узнать мнение, как лучше грузить такие *db в гипотетическую игру.
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:Неужели в Qt нету встроенных таблиц?[right][snapback]41199[/snapback][/right]А вот хороший вопрос... =)
Как понял, разработчики библиотеки желают сразу же приобщить пользователя библиотеки к парадигме: модель->представление. Т.е. создаётся модель в виде таблицы, которая подключается к представлению в виде таблицы.
В самом общем (сферическом) случае модель в Qt позволяет создать, так скажем, табличную иерархию таблиц (где ячейка таблицы может адресовать вложенную таблицу). Соответственно, частными случаями этой мега-модели являются список, таблица и просто дерево.
В принципе "создать таблицу в Qt" -- это создать табличную модель. Хотя интерфейс управления такой таблицей мне не пришёлся по вкусу, так как он слишком универсален и неудобен для плотной работы с таблицей. Поэтому я сделал враппер (класс-обёртку) с более дружественным интерфейсом для работы с таблицами.
С одной стороны, плюсом подхода модель-представление является гибкость: не обязательно держать в памяти данные таблицы как есть, можно некоторые из них вычислять и применять динамически. Что порой очень удобно и эффективно. Но, с другой стороны, в простых случаях такой подход довольно громоздкий.
KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:Кстати я удивлён, увидев, что pragma влияет на g++. Если верить тому, что я читал раньше, он должен был бы их игнорить.[right][snapback]41199[/snapback][/right]Не знаю. Mingw под винду сделал это. А вообще, интересно, если pragma полностью игнорится, то как тогда в структуре адекватно считать 2-байтовые поля?
KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:В коде кстати есть довольно странное условие, не знаю, так и надо или нет... if( offset < 0 || size < 0 )... бессмысленный код вроде if(false). Ведь offset и size по типу quint32, беззнаковые. (строки 79-81 файла qresreader.cpp ).[right][snapback]41199[/snapback][/right]Есть такой момент. %) Забито автоматом на автопилоте, скорее всего. %) Всё-таки нужно в Индию съездить... вдруг там родственники есть.
![Big Grin Big Grin](https://www.gipat.ru/forum/images/smilies/biggrin.png)
KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:И перевод из чисел в адрес клетки и из клетки в адрес можно было бы написать проще, за один проход и без дополнительных переменных.[right][snapback]41199[/snapback][/right]Ты имеешь ввиду способ чтения/записи ячеек рабочих таблиц программы? Там пришлось в некоторых местах прибегнуть к дополнительным конвертациям. Вообще для чтения/записи ячеек используются variant-переменные, но почему-то (точню не припомню с ходу почему) при попытке записи чисел с точкой в ячейку с целым числом, когда я извлекал integer, почему-то из variant возвращался ноль вместо округлённого числа. Поэтому пришлось делать дополнительную конвертацию. Здесь я и сделал баг с округлением... =)
KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:Кстати, а где вообще нужны signed long? я посмотрел таблицы, там не было чисел больше 2^31-1.[right][snapback]41199[/snapback][/right]SignedLong'и попадаются по-идее там, где имеются поля типа FFFFFFFF или FFFFFFFE, ну и т.п...
![Smile Smile](https://www.gipat.ru/forum/images/smilies/smile.png)
Вообще очень приятно было услышать твоё мнение. Спасибо за замечания.
![Rolleyes Rolleyes](https://www.gipat.ru/forum/images/smilies/rolleyes.png)
24.08.2012, 05:45
Замечательная программа. ))
После нехитрых манипуляций с параметрами ритуального ножа Зак оказался в стартовой локации не с бронзовым ножом, а с луком. :lol: Вот и убилась "бессмертная" лягушка, сидящая на недоступном возвышении. ))
Вот только одно я не понял - что это за хитрые значения в столбцах "Damage min" и "Damage max" на вкладке оружия? У Unique sword они равны 2,02234 и 0,977664 соответственно (минимальный дамаг больше максимального?! О_о). В старых таблицах (например, в "db_SP_toolkit") значения совершенно другие: 20,223362 и 30.
После нехитрых манипуляций с параметрами ритуального ножа Зак оказался в стартовой локации не с бронзовым ножом, а с луком. :lol: Вот и убилась "бессмертная" лягушка, сидящая на недоступном возвышении. ))
Вот только одно я не понял - что это за хитрые значения в столбцах "Damage min" и "Damage max" на вкладке оружия? У Unique sword они равны 2,02234 и 0,977664 соответственно (минимальный дамаг больше максимального?! О_о). В старых таблицах (например, в "db_SP_toolkit") значения совершенно другие: 20,223362 и 30.
24.08.2012, 08:18
Хмм, такое чувство, что damage max это число, которое прибавляется к damage min. Например, 2,02234 + 0,977664 = 3,000004, что очень похоже на правду. Так что damage max правильно было бы переименовать в damage range наверное. А то что в 10 раз меньше - наверное там это сделали для удобства.
22.10.2015, 17:04
Прошло много времени с последнего релиза EI DB Editor'а на SourceForge.
С тех пор, DB Editor успел переехать на github: https://github.com/chemmalion/EIDBEditor.
А также вышло несколько багфиксовых релизов.
Из интересного, касательно формата базы: два "новых" поля в таблице Quick Items, которые позволяют увеличить скил воровства (stealing) и взлома замков (science), если предмет одет у персонажа. Эти значения не складываются, а берётся наибольший модификатор. Т.е. если одето два итема на +10 и +20 к воровству соответственно, то в результате будет +20.
На этом всё. Обо всех багах и замечаниях пишите сюда или на github, пофиксаю, когда будет время.
С тех пор, DB Editor успел переехать на github: https://github.com/chemmalion/EIDBEditor.
А также вышло несколько багфиксовых релизов.
Из интересного, касательно формата базы: два "новых" поля в таблице Quick Items, которые позволяют увеличить скил воровства (stealing) и взлома замков (science), если предмет одет у персонажа. Эти значения не складываются, а берётся наибольший модификатор. Т.е. если одето два итема на +10 и +20 к воровству соответственно, то в результате будет +20.
На этом всё. Обо всех багах и замечаниях пишите сюда или на github, пофиксаю, когда будет время.
22.10.2015, 20:15
По удобству и качеству оптимально. Спасибо создателям, причем огромное.
Вопрос 1 - фиксы по багам по мелочи, либо есть серьезные правки?
Просто явных накладок не встречалось.
Вопрос 1 - фиксы по багам по мелочи, либо есть серьезные правки?
Просто явных накладок не встречалось.
22.10.2015, 21:00
Для тех, кто пользуется xlsx<->res, фиксы критические. Для остальных в целом тоже довольно важные.
04.09.2016, 11:14
По просьбе Siniy 481 - вот тема с простым и качественным редактором базы. За подробностями
лучше обратиться к создателям редактора.
лучше обратиться к создателям редактора.
25.01.2019, 21:40
Вышел ещё один багфикс-релиз 1.4.4:
https://github.com/chemmalion/EIDBEditor/re...g/release_1.4.4
Связан он с обработкой юникодных-символов. Из-за бага база могла постепенно увеличиваться в размерах и накапливать мусор в тех строках, где эти символы использовались.
В частности, такую проблему вызывает символ неразрывного пробела (код 0xA0).
Визуально он выглядит так же как обычный пробел, но технически это другой символ. Для ПЗ эта разница принципиальна.
TL;DR. Баг стреляет редко, но метко. Лучше от греха подальше обновиться.
https://github.com/chemmalion/EIDBEditor/re...g/release_1.4.4
Связан он с обработкой юникодных-символов. Из-за бага база могла постепенно увеличиваться в размерах и накапливать мусор в тех строках, где эти символы использовались.
В частности, такую проблему вызывает символ неразрывного пробела (код 0xA0).
Визуально он выглядит так же как обычный пробел, но технически это другой символ. Для ПЗ эта разница принципиальна.
TL;DR. Баг стреляет редко, но метко. Лучше от греха подальше обновиться.