Распаковка базы Database(lmp).res
#41
res


Файлы вложений
.zip   res.zip (Размер: 2.25 KB / Загрузок: 313)
Ответ
#42
Robin, спасибо большое! Smile
Ответ
#43
Обновил версию проги. Smile

* Сделал прямую запись в RES
* Сделал прямую запись в XLSX
* Соответственно сделал возможным вызывать прогу с параметрами командной строки Smile

* Сделал одну кнопку для загрузки всех форматов (RES/XLSX/*db)

* Теперь когда прога сохраняет в RES, она оставляет оригинальные неподдерживаемые файлы (например пока что adb) из оригинального RES. А если оригинального RES не было (т.е. например работали изначально с XLSX), то сохраняются оригинальные неподдерживаемые файлы конечного RES файла (если он уже был).

* Добавил функцию последних 5-ти загрузок Smile
* Дописал названия полей
* Написал readme.txt о том, что может быть непонятно Smile

С командной строкой работать так:
dbeditor.exe pathtofilename.res <- сделает pathtofilename.xlsx
dbeditor.exe pathtofilename.xlsx <- сделает pathtofilename.res

Так как прога не консольная, то нужно учитывать, что она сразу же после вызова возвращает управление, не дожидаясь своего завершения. Если нужно дождаться завершения работы проги в консоле, тогда нужно, например, вызывать так:
start /wait dbeditor.exe pathtofilename.res

Соответственно получается ещё один сценарий работы с прогой:
* Бросаем res файл на прогу и получаем рядом с ним xlsx
* Бросаем xlsx файл на прогу и получаем рядом с ним res
Ответ
#44
Молодец! Отличная прога!!! Так держать!
Ответ
#45
Си-иба Smile
Ответ
#46
ELF, в последней версии EIDB Editor'а довольно странный и противный баг с SignedLong полями. А именно при редактировании или импортировании из xlsx он прибавляет к отрицательным числам 1. В итоге хочешь к примеру записать -1 а он выдает 0, хочешь записать -2 а на деле -1. ><
Ответ
#47
Гы) вот так баг Smile попробуем разобраться на досуге =)
Ответ
#48
Забавная программа Smile я даже попытался почитать исходный код...) Правда что-то там всего много. Неужели в Qt нету встроенных таблиц? Кстати я удивлён, увидев, что pragma влияет на g++. Если верить тому, что я читал раньше, он должен был бы их игнорить. (я не говорю что я собирал твою программу под Linux. Никогда не собирал ничего под Qt. Под GTK+ да, под XLib да, под Qt - никогда Smile ) В коде кстати есть довольно странное условие, не знаю, так и надо или нет... if( offset < 0 || size < 0 )... бессмысленный код Smile вроде if(false). Ведь offset и size по типу quint32, беззнаковые. (строки 79-81 файла qresreader.cpp ). И перевод из чисел в адрес клетки и из клетки в адрес можно было бы написать проще, за один проход и без дополнительных переменных.
Кстати, а где вообще нужны signed long? я посмотрел таблицы, там не было чисел больше 2^31-1.
Ответ
#49
Невнимательно смотрел значит. Smile К примеру (первое что пришло в голову) это номер волос - значение от -1 до 1(или двух, не помнюSmile)
Ответ
#50
Поправил баг с отрицательными значениями.
Проблема была в том, что это я так округлял значения... по-эльфийски. Сделал по-человечески (возможно). Smile


KnightL, сиба большое за отзыв. Smile

KnightL,Пятница, 13 Апреля 2012, 22:56 Написал:я даже попытался почитать исходный код...) Правда что-то там всего много.[right][snapback]41199[/snapback][/right]
Код действительно написан довольно грязно. Smile Где-то по-началу ещё было стремление, чтобы всё было аккуратно и красиво, но потом захотелось побыстрее, да и изучение форматов *db постепенно подбрасывало такие сюрпризы, которые изначальную концепцию чтения данных ставили с ног на голову ( или с головы на ноги, если смотреть относительно хода мыслей разработчиков игры Smile ). Поэтому я решил сначала добиться полного чтения db-файлов, а потом уже отдельно посмотреть на это с позиции "когда уже всё известно".

Сейчас я пришёл к выводу, что вообще *db-файлы лучше считывать по принципу загрузки XML (родитель->дочерние элементы->братья родителя...). Это бы, думаю, упростило бы структуру считывателя с точки зрения восприятия кода. Соответственно настройку разбора формата (текстовые файлы) нужно было бы делать иначе (или теперь вообще уже не делать, так как все структуры уже довольно ясно выреверсированы). Но пока что всё осталось вот так, в виде спагетти внутри методов. Smile

А вообще я сейчас в промежутках между жизнью делаю сферический в вакууме класс для работы с большими Res-архивами... Smile Как сделаю - выложу. Может быть кому пригодится.

Потом думаю сделать такой же сферический для *db-файлов... но пока что не знаю, как этот класс функционально оформить... в играх, как я понял, такие вещи оформляют в виде "системы работы с ресурсами" - некий класс фабрика объектов, который когда нужно грузит ресурсы и даёт нам доступ к ним в виде различных игровых объектов (или ссылок на них)...
Вообще у кого есть опыт в разработке игр, было бы неплохо узнать мнение, как лучше грузить такие *db в гипотетическую игру. Smile

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

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 Порой такие поля попадаются.


Вообще очень приятно было услышать твоё мнение. Спасибо за замечания. Rolleyes
Ответ
#51
Замечательная программа. ))
После нехитрых манипуляций с параметрами ритуального ножа Зак оказался в стартовой локации не с бронзовым ножом, а с луком. :lol: Вот и убилась "бессмертная" лягушка, сидящая на недоступном возвышении. ))

Вот только одно я не понял - что это за хитрые значения в столбцах "Damage min" и "Damage max" на вкладке оружия? У Unique sword они равны 2,02234 и 0,977664 соответственно (минимальный дамаг больше максимального?! О_о). В старых таблицах (например, в "db_SP_toolkit") значения совершенно другие: 20,223362 и 30.
Не бойтесь неприятностей. Если они еще не случились, то они где-то в будущем,
а если уже случились - то в прошлом. То есть сейчас и здесь их нет.
Ответ
#52
Хмм, такое чувство, что damage max это число, которое прибавляется к damage min. Например, 2,02234 + 0,977664 = 3,000004, что очень похоже на правду. Так что damage max правильно было бы переименовать в damage range наверное. А то что в 10 раз меньше - наверное там это сделали для удобства.
Ответ
#53
Прошло много времени с последнего релиза EI DB Editor'а на SourceForge.
С тех пор, DB Editor успел переехать на github: https://github.com/chemmalion/EIDBEditor.
А также вышло несколько багфиксовых релизов.

Из интересного, касательно формата базы: два "новых" поля в таблице Quick Items, которые позволяют увеличить скил воровства (stealing) и взлома замков (science), если предмет одет у персонажа. Эти значения не складываются, а берётся наибольший модификатор. Т.е. если одето два итема на +10 и +20 к воровству соответственно, то в результате будет +20.

На этом всё. Обо всех багах и замечаниях пишите сюда или на github, пофиксаю, когда будет время.
Ответ
#54
По удобству и качеству оптимально. Спасибо создателям, причем огромное.
Вопрос 1 - фиксы по багам по мелочи, либо есть серьезные правки?
Просто явных накладок не встречалось.
Ответ
#55
Для тех, кто пользуется xlsx<->res, фиксы критические. Для остальных в целом тоже довольно важные.
Ответ
#56
По просьбе Siniy 481 - вот тема с простым и качественным редактором базы. За подробностями
лучше обратиться к создателям редактора.
Ответ
#57
Вышел ещё один багфикс-релиз 1.4.4:
https://github.com/chemmalion/EIDBEditor/re...g/release_1.4.4

Связан он с обработкой юникодных-символов. Из-за бага база могла постепенно увеличиваться в размерах и накапливать мусор в тех строках, где эти символы использовались.

В частности, такую проблему вызывает символ неразрывного пробела (код 0xA0).
Визуально он выглядит так же как обычный пробел, но технически это другой символ. Для ПЗ эта разница принципиальна.

TL;DR. Баг стреляет редко, но метко. Лучше от греха подальше обновиться.
Ответ


Перейти к форуму:


Пользователи, просматривающие эту тему: 2 Гость(ей)