Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - MetLob

Страницы: [1]
1
Ну, или ловить MetLob'а и просить написать плагин к автодампу для работы с текстом в твоей игре.
Очень "грязный" дамп текста во вложении.

Я, видимо, сам поймался...

Вот маленький ликбез к созданию проекта АвтоДампа, если поинтеры содержат размер строки.

Сначала настраиваем тип поинтеров:


Здесь таблица поинтеров начинается с 0x5BAC. Размер элемента таблицы с указателем = 16.
Сначала идут номер сообщения (4 байта), затем неизвестные 4 байта, затем оффсет (абсолютный), затем размер данных сообщения.
Поэтому выставляем параметры так:


Затем открываем файл, выбирая Дефолтный плагин. Обязательно открываем диалог с выбором указателей.
Автоматический поиск указателей ищет поинтеры (с сопутствующей инфой), размером в 16 байт. Ищет он с 0, 16, 32 и т.д., а наши указатели начинаются с позиции, кратной 12 (x5BAC), следовательно внизу, как на скрине, необзходимо проставить 12 (нажать ентер).


После этого АД автоматически найдет область с указателями. Всегда нужно проверять, верно ли он нашел, но для этого файла он справился.

После открытия файла, как уже было замечено, текст перемешан с множеством служебных кодов.
Каждый код начинается с байта 7F.
Затем у каждого кода есть продолжение: собственно код команды (2 байта):
0000 - окончание сообщения (очистка экрана)
0100 - перенос
0200 - ожидание нажатия кнопки
0800 - различные кнопки
0E00 - неизвестный мне (используется в строке Vs. <код>)
0F00 - число
1100 - переход на другое сообщение
1500 - смена цвета
1900 - кнопки L/R

Это все основные команды. Но у некоторых команд есть и параметры (4 байтовые значения):
0800: 01000000 - кнопка A
0800: 02000000 - кнопка B
0800: 03000000 - кнопка X
0800: 04000000 - кнопка Y
0800: 05000000 - кнопка ←
0800: 06000000 - кнопка →
0800: 0C000000 - Circle PAD
0800: 0D000000 - START
0800: 0E000000 - HOME
1900: 07000000 05000000 - кнопка L
1900: 08000000 06000000 - кнопка R

0F00: 00000000 - количество призраков
0F00: 01000000 - количество золота

1500: 01000000 - GREEN
1500: 02000000 - RED
1500: 03000000 - YELOW
1500: FFFFFFFF - WHITE

Необходимо создать таблицу декодирования (как вставлять, есть в документации)
Но вот тут есть проблемки формата, а именно в дурацком выравнивании:
1) Сам байт начала команды (7F) расположен в любом месте (без выравнивания)
2) Каждый КОД команды выравнивается по своему размеру: 2.
3) Каждый ПАРАМЕТР команды выравнивается по своему размеру: 4.

Отсюда получаем, что после 7F может идти 1 байт нуля, если 7F стоит на ЧЕТНОМ месте,
а после КОДА команды - иногда добавляется 2 нулевых байта, чтобы параметры начинались с позиции, кратной 4.

Я создал такую вот таблицу декодирования (в качестве переноса в АД проставил 0100):
7F0000=<END>
7F00=<#0>
7F=<#>
0200=<BTN>
080001000000=<A>
0800000001000000=<0\A>
080002000000=<B>
0800000002000000=<0\B>
080003000000=<X>
0800000003000000=<0\X>
080004000000=<Y>
0800000004000000=<0\Y>
080005000000=<←>
0800000005000000=<0\←>
080006000000=<→>
0800000006000000=<0\→>
08000C000000=<CPAD>
080000000C000000=<0\CPAD>
08000D000000=<START>
080000000D000000=<0\START>
08000E000000=<HOME>
080000000E000000=<0\HOME>
19000700000005000000=<L>
190000000700000005000000=<0\L>
19000800000006000000=<R>
190000000800000006000000=<0\R>

0E0000000000=<UNK>
0F0000000000=<GHOSTS>
0F00000000000000=<0\GHOSTS>
0F0001000000=<GOLDS>
0F00000001000000=<0\GOLDS>

1100,2=<GOTO>

150001000000=<GREEN>
1500000001000000=<0\GREEN>
150002000000=<RED>
1500000002000000=<0\RED>
150003000000=<YELOW>
1500000003000000=<0\YELOW>
1500FFFFFFFF=<WHITE>
15000000FFFFFFFF=<0\WHITE>

В этой таблице я сделал по 2 команды на 1 (с добавочными нулями и без):
Например, <#> в тексте будет означать 7F, а <#0> - 7F00.
<0\HOME> будет означать, что перед параметром команды 0800 будут два нуля: 0800 0000 E000000
При изменении текста нужно следить за нулями: просто добавляя или удаляя "0\" из команды.

В этом случае краша в игре не должно быть. Знаю - муторно, но это все, что я мог сделать на скорую руку.
При более тесном сотрудничестве смогу легко написать тулзу, которая будет фикстить бинарный файл на эти нули. Тогда проблема слежения за позицией байта будет не актуальна.

ПС: проект для АД во вложении

2
Мне тупо любопытно, а в чем заключается перевод ручками (не голосовыми сообщениями же...) и написание отдельной спец. программы?
Игра то вообще в хакинге не нуждалась вроде. Текст в текстовиках, графика в стандартном NITRO формате.


3
О, наконец-то! Респект ✊
Я намучался с портированием перевода Cave Story без твоего софта.

Да, жаль, я неудачное время для перерыва выбрал.

Кстати, как дела с CoD? Нигде не выкладывал?

4
Весь интерфейс программы - это один большой баг, пользоваться этим недоразумением невозможно, это чудовищно. Сравните, например с Tahaxan (который тоже не шедевр).

Возможно, не так все очевидно, как этим пользоваться. Недостатков достаточно. Но из интерфейса там всего, по сути, 7 кнопок - больше и не нужно.
Мне норм. Все игры, которые хакал на DS, бегло просматриваю здесь, чтобы быстро найти нужный файл: текст, картинку, пак и т.д. и сразу в хексе можно понять, что с файлом делать дальше.
Соглашусь по части интерфейсов самих оригинальных плагинов.
Но это не важно. Для меня удобство, как для хакера, именно в простом интерфейсе библиотечки для написания плагинов (2 типа: для поддержки каких-либо игр целиком по ID, либо поддержки каких-либо форматов, не зависимо от кода игры).

Ну а в данной теме обсуждению подлежит не сам Тинке со своим интерфейсом, а его функциональность по пересбору DSi ромов.
Если есть у кого интерес к написанию плагинов, могу в отдельной теме подробно описывать, как это делать на примерах. И выкладывать свои.

5
Исправил для Tinke шифрование Secure Area (SA) в NDS ромах (любого типа DS|DSiEnh|DSi, в том числе DSiWare)

Если Вы замечали, что в Tinke SecureArea CRC почти всегда пишет (false), хотя на самом деле ром только что скачан и валидный.

Это связано с тем, что CRC для Secure Area необходимо считать для шифрованных первых 800h байт этой области. А для большинства NDS ромов SA дешифрован.
В предыдущей версии DSi-мода я добавил исправленный перерасчет CRC, шифруя первые 800h байт данных SA.
Но эта ситуация не была проблемой. Теперь для валидных ромов писалось правильное "true".

Однако, главное мною было упущено.
При изменении в Tinke кода игры (NTR-код рома), который и является ключом шифрования для SA, я забыл обновлять SA.
Проблема касалась в основном игр DSi, где запускаемые бинарники (arm9.bin) у большинства ромов имели зашифрованные SA данные.
Хотя у большинства чистых NDS-ромов SA дешифрована, некоторые ромы, так или иначе, могут содержать зашифрованную SA.

Обновил билд. Ссылка та же.

6
Ромхакинг и программирование / DSi Romhacking
« : 15 Август 2019, 16:39:23 »
Пожалуйста )
Если будут баги какие-то, то сюда пишите, и со скринами.
Буду допиливать, если что-то не так.


7
Всем привет.
Я наконец-то добрался до своих исходников с работами по модификации Tinke c поддержкой DSi ромов, написанных в конце 2017 года.

Билд без плагинов (актуальный) от 18 января 2018 года:
https://drive.google.com/open?id=1WbKOqEukgjSUKDCOs9n8kts-l_euHS0a

Для кого нужно сделать свой билд со своими настройками, вот моя ветка проекта (пока автор не объединил ветку с основным):
https://github.com/MetLob/tinke/tree/DSi

Плагины забираем с оффициалной ветки.

8
 :) Напросился))) Всегда помогу, чем смогу.

ПС: Я тоже пятницу отмечаю, только гости у меня. Это вообще нормально, что мы пятницу отмечаем?!

9
Видимо я опоздал немного с описанием... :'(

10
не RLE там.

Там RLE. Только сжата графика не целым файлом, а построчно. Да и RLE разная, тут только 2-байтовые нули сжимаются.
Вот спецификация (Offset - Size - Value):

HEADER
----------
0x00 - 6 - magic "rle02\0"
0x06 - 2 - width (176)
0x08 - 2 - height (208); 176x208 - resolution of n-Gage
0x0A - 2 * height - row pointers, offset = data offset + 2 * pointer value (указатели на сжатый блок данных для каждой строки, относительно начала данных)
0x?? - 4 - data size / 2 (половина размера данных, или количество 2-х байтовых значений)

RLE DATA BLOCK
--------------------
0x00 - 2 - value
Если (первый бит 0), то это количество нулевых пикселей, по 2 байта (пишем их в результат)
Иначе - это количество считываемых пикселей, по 2 байта (считываем эти значения и записываем в результат)
Могут быть нюансы какие-нибудь, нужно проверять. Но как-то так. Пиксель, судя по всему 16-битный, может RGB555 без первого бита.

11
Да, уже началась.

12
Да не, скорее всего скрины взяты со страницы, когда перевод был только в процессе.

13
Я же не переводчик...  :-\ Меня и в ридми достаточно упомянуть. Но ваше дело)

14
Я готовил софт для вставки текста под покемонов данной серии. Если ты чисто хочешь переводом заняться, могу скидывать текст, а сам буду перевод вставлять и тебе скидывать ром для дальнейшей работы.

Шрифт тоже рисовал... очень схожий с образцами на скринах от PokeRus.

Страницы: [1]