Evil_Finalist

История русской локализации Tales of Rebirth (PS2) Глава 7. Очистка строк от лишних данных и работа с нестандартными поинтерами https://vk.com/temple_of_tales_translations https://temple-tales.ru/games/tor/russian_localization.html В начале прошлой главы на первом изображении я наглядно показал, что блоков с поинтерами в исполняемом файле всего более 40 штук. А теперь представьте, что все ранее описанные этапы нужно повторить заново с каждым из них. В таких случаях даже программистам приходится искать вручную каждый блок и идентифицировать все поинтеры. Потому что автоматизировать этот процесс очень сложно, ведь расположение поинтеров в большинстве блоках хаотичное, так как в одних расстояние между поинтерами одно, а в других — другое. Кроме того, расстояние в одном блоке поинтеров между разными указателями тоже может отличаться. А вот насколько сильно — вы можете посмотреть на приведённом изображении ниже: Визуализация разных расстояний между поинтерами. Красным отмечены области с расстоянием по 4 байта, синим — по 8 байт, а зелёным — по 12 байт соответственно. В этом случае возникает вопрос: а как в таком беспорядке abcde будет справляться с распознаванием поинтеров? Автор данного приложения этот момент не продумал. Если мы зададим программе интервал, то при извлечении текста в рамках этого интервала приложение будет пытаться прочитать поинтеры принудительно. Иначе говоря, после считывания обычных указателей приложение рано или поздно попытается считать поинтер из той области, которая не является поинтером. И именно в этот момент в строке с извлечённым текстом от программы стоит ожидать различного рода мусора, который будет очень сильно мешать работе в целом. Эти мусорные данные среди полезного текста выглядят примерно вот так: Розовым, чёрным и зелёным цветами отмечены блоки, которые программа ошибочно принимает за поинтеры и пытается извлечь текст по этим адресам. В результате прочитанные значения могут выходить за пределы массива данных файла, что в свою очередь создаёт различную несогласованность адресов. На данном изображении это отмечено серыми стрелками. Кроме того, если при попытке считывания по ложному смещению попадается первый байт со значением 0x00, то при извлечении эта строка будет пустой и в сформированном блоке поинтера ничего, кроме тега [END], мы не увидим. Напомню, что файлы с извлечёнными строками текста содержат свой блок данных для каждого поинтера, и в этих файлах их можно спокойно копировать и удалять, а также склеивать между собой как угодно, не нарушая синтаксис. Примерно вот так: И здесь, как вы уже, скорее всего, догадались, все мусорные блоки с текстом, которые были идентифицированы ошибочно, придётся удалять вручную. По-другому от них никак не избавиться, потому что с помощью abcde этот процесс не автоматизировать. Можно удалять мусорные блоки прямо в текстовом редакторе, но для визуального облегчения всё это я копировал в эксель и уже там сортировал удобным образом. Поскольку в текстовом редакторе весь синтаксис тегов сливается с полезным текстом и различать мусорные данные там довольно непросто: есть риск ошибиться и захватить полезные строки. В экселе же есть возможность графически выделить разные строки, что явно ускоряет идентификацию. Наглядно это выглядит вот таким образом: Это ещё не всё, что хотелось бы осветить по поводу поинтеров. Дело в том, что, помимо простых указателей с поправкой, ещё существует второй тип поинтеров, которые записаны в функциях в виде инструкций прямо среди основного кода исполняемого файла. И не всегда их легко различить визуально. В нашем случае несколько таких поинтеров попадается в исполняемом файле, и работу с ними мне тоже пришлось освоить. Приложение abcde нам никак не поможет, потому что уровень сложности в этом случае резко возрастает и требует более глубоких знаний и понимания кода архитектуры процессора MIPS R5900, который используется в играх для платформы PlayStation 2. Для поиска таких поинтеров в очередной раз обращаемся к инструментам обратной разработки: IDA Pro или Ghidra. Как и в прошлый раз, опишу этот процесс, выполняемый с помощью IDA Pro. ⬜ Этап 1. Поиск функции, в которой прописан нестандартный поинтер а) Повторяем первоначальные шаги, которые были описаны в прошлой главе. Ищем нужные нам строки с текстом в исполняемом файле с помощью хекс-редактора, поинтеры которых не получилось найти. В качестве примера я выбрал строку вот с этим текстом: Chambers. Загружаем SLPS_254.50 в IDA Pro. Ждём, как приложение просчитает взаимосвязи всех функций. Далее щёлкаем по вкладке "Hex View-1" и ищем здесь начало того же текста, который нашли в хекс-редакторе. Вам необязательно сначала искать текст в хекс-редакторе, а потом в IDA Pro. Если вы достаточно хорошо ориентируетесь в IDA, то можете сразу начинать поиски текста в этом приложении. После того, как нашли строку с текстом, щёлкаем по вкладке "IDA View-A". Вы увидите вот такое окно: б) На представленном изображении в прошлом пункте наглядно видно, как чуть ниже строки с текстом программа прописывает адресацию к функции, в которой указан индекс к началу этого текста. Наводим курсором на эту взаимосвязь "# DATA XREF: .text:00153B3C↑o" и щёлкаем 2 раза: в) После того как два раза нажали на взаимосвязь "# DATA XREF: .text:00153B3C↑o", вас должно перекинуть на окно, которое по своей сути является просмотрщиком дизассемблированного кода: Таким образом мы попадаем в одну из функций, в которой прописаны определённые инструкции для работы с данной строкой. Именно здесь нам и предстоит ориентироваться в поисках нестандартного поинтера. ⬜ Этап 2. Определение верхней и нижней частей среди инструкций для формирования целого поинтера а) В первую очередь важно понять, что придётся часто переключаться между окнами "IDA View-A" и "Hex View-1", а также постоянно держать в голове поправку FF000 для точных расчётов. Можно упростить себе задачу и держать под рукой калькулятор для подсчётов в шестнадцатеричной системе счисления. Найденная область функции содержит данные сразу для работы с тремя строками: Оригинальный текст японской версии: 1) 謎の館 2) The Hidden Chambers 3) この中に何があるのか……<__>全てが謎につつまれた館。 Текущий вариант перевода строк в нашей локализации: 1) Таинственный особняк 2) [SPACE] 3) Особняк, окутанный тайнами.<__>Никто не знает, что в нём. Все они относятся к названию и описанию локации "Таинственный особняк". Но для того, чтобы вычислить каждый поинтер для всех этих строк, потребуются определённые манипуляции c идентификацией инструкций, в которых и спрятаны поинтеры. Кроме того, поинтеры для каждой строки разделены на 2 части и наша задача каждую из них найти, развернуть и правильно сложить. Перед тем, как приступить к следующему шагу, нужно немного рассказать об особенностях данного типа поинтеров. Процессоры MIPS работают с 32-битными указателями. Размер любого поинтера в памяти составляет 32 бита. Проще говоря, это 4 байта. Например: 0x0022C268. Это в свою очередь накладывает определённые ограничения, потому что любая инструкция MIPS занимает ровно 4 байта. В этот размер можно уместить: код операции, номера регистров и числовую константу (immediate). В итоге на константу в одной инструкции остаётся всего 2 байта. Это означает, что в одну инструкцию умещается только половина поинтера. Именно поэтому весь указатель собирается из двух инструкций. Первая инструкция загружает верхние 2 байта, а вторая добавляет нижние 2 байта. В этом и заключается основная задача: понять, где в инструкциях прописаны числовые константы для верхней и нижней части поинтера. б) В окне просмотра дизассемблированного кода "IDA View-A" нужно обратить внимание на следующие строки: lui $a0, 0x23 # '#' lui $a1, 0x23 # '#' lui $v1, 0x23 # '#' li $a0, unk_22C268 li $a1, aTheHiddenChamb # "The Hidden Chambers" li $v1, unk_22C290 Первая группа из трёх строк отвечает за верхние части поинтеров, а вторая группа из трёх строк — за нижние. В итоге получаем вот такую взаимосвязь: Верхняя часть 1 поинтера = lui $a0, 0x23 # '#' Верхняя часть 2 поинтера = lui $a1, 0x23 # '#' Верхняя часть 3 поинтера = lui $v1, 0x23 # '#' Нижняя часть 1 поинтера = li $a0, unk_22C268 Нижняя часть 2 поинтера = li $a1, aTheHiddenChamb # "The Hidden Chambers" Нижняя часть 3 поинтера = li $v1, unk_22C290 Для того, чтобы корректно отследить каждую часть, а потом сделать определённые изменения в соответствии с нашим переводом, возьмём вторую строку из первой группы и вторую строку из второй группы: Верхняя часть 2 поинтера = lui $a1, 0x23 # '#' Нижняя часть 2 поинтера = li $a1, aTheHiddenChamb # "The Hidden Chambers" Как только щёлкаем в любом месте по нужной нам инструкции в окне "IDA View-A", вся её часть подсвечивается соответствующим образом и в окне "Hex View-1". Пробуем нажать на "0x23" в окне "IDA View-A" (строка верхней части 2-го поинтера), а затем переключаемся на окно "Hex View-1" и наблюдаем, что IDA Pro выделяет все 4 байта этой инструкции: Первые 2 байта "23 00" в этом выделенном блоке и являются числовой константой, а именно верхней частью нужного нам поинтера. Запоминаем или записываем это значение. Далее приступаем к поиску нижней части поинтера. Для этого пробуем нажать на "aTheHiddenChamb" в окне "IDA View-A", а затем переключаемся на окно "Hex View-1" и снова наблюдаем, как IDA Pro выделяет все 4 байта другой инструкции: Здесь первые 2 байта "78 C2" тоже являются числовой константой, той самой нижней частью нужного нам поинтера. Теперь у нас на руках обе части. Перед тем как их сложить, нужно их развернуть — не забываем, что на консоли PS2 порядок построения байтов в поинтерах записывается в little-endian виде: 23 00 » 00 23 78 C2 » C2 78 Затем складываем: 00 23 + C2 78 = 00 23 C2 78 Мы практически получили готовый поинтер, но не всё так просто. Если из него вычесть поправку FF000 и в исполняемом файле SLPS_254.50 в хекс-редакторе перейти по этому адресу, то мы не попадём на нужную нам строку, потому что существует определённое правило ещё одной поправки для инструкций, но уже для верхней части. Заключается оно в том, что если 2 байта из нижней части меньше или равны значению 0x8000, то к верхней части прибавляется 1 (то есть +0x10000), а если меньше, то эта поправка не нужна. В соответствии с этим правилом корректируем полученный поинтер, так как значение нижней части поинтера в нашем случаем больше этого числа: C278 > 8000. Пересчитываем: 00 23 C2 78 - 00 01 00 00 = 00 22 C2 78 Вот только теперь мы получили правильный поинтер, от которого нужно отнять поправку FF000, о которой я просил вас не забывать: 00 22 C2 78 - 00 0F F0 00 = 12 D2 78 Открываем исполняемый файл в хекс-редакторе и убеждаемся, что все расчёты были проведены правильно и что по данному адресу находится нужная нам строка с текстом: ⬜ Этап 3. Ручное изменение нестандратных поинтеров в хекс-редакторе а) Ну а теперь, когда нам известно, как найти все нестандартные поинтеры, то можно приступить к их изменению в соответствии с тем переводом текста, который я привёл в начале второго этапа. Есть попытаться вставить текст третьей строки, то он свободно умещается в изначально отведённое пространство. Но со второй строкой сделать это не получится — при попытке укладки переведённого текста в первую строку он начнёт перекрывать текст второй строки. Потому что для первой строки в исполняемом файле всего выделено 15 байт, а наш вариант "Таинственный особняк" занимает 20 байт + ещё нужно учитывать 1 байт окончания строки со значением {00}. Итого для нашего варианта перевода необходим 21 байт, что явно превышает размер 15 байт. Так как укладка текста будет идти в изначальный адрес оригинальной первой строки, то значения поинтера здесь менять не нужно, а вот значения поинтера для второй строки придётся изменить. Для новичков это может звучать немного запутанно, поэтому приведу несколько скриншотов, чтобы стало понятно получше:

История русской локализации Tales of Rebirth (PS2) Глава 6. Разбор исполняемого файла ELF с помощью IDA Pro https://vk.com/temple_of_tales_translations https://temple-tales.ru/games/tor/russian_localization.html Если попалась игра, в которой куча строк текста находится в исполняемом файле и с этим некому помочь, то, скорее всего, вам прямая дорога к таким инструментам обратной разработки, как IDA Pro или Ghidra. Для новичков это очень непростое погружение, и многое в этих приложениях может быть непонятным. Тем не менее часть из этого я попытаюсь объяснить, так как со всеми текстами в файле ELF Сказаний Перерождения мне пришлось поработать очень активно. И всё это для возможности гибких изменений, чтобы работать с текстом без ограничений по количеству символов на каждую строку. На изображении наглядная визуализация распределения поинтеров на блоки по разным местам исполняемого файла: Если мы просто откроем исполняемый файл SLPS_254.50 в хекс-редакторе, то при беглом просмотре рано или поздно наткнёмся на блоки текста, которые распределены в хаотичном порядке близко к самому хвосту файла. На изображении выше я попытался визуально изобразить степень распределения текста и поинтеров в этой области. Все поинтеры скучкованы по разным блокам, а всего этих блоков более четырёх десятков. Кроме того, многие из них попадаются прямо посреди участков с записанными текстовыми данными. Всё это очень непросто отследить, высчитать, а также написать алгоритм для извлечения и вставки текста. В этом нам поможет комплекс нескольких программ. По началу мне советовали использовать специальное приложение под названием Kruptar авторства Джинни (https://magicteam.net/index.php?page=programs). С одной стороны, я посчитал его слишком запутанным, а с другой — простым, так как программа имеет ряд ограничений, а созданный в ней проект привязан к своему файлу, в котором сконцентрированы все данные. Это, в свою очередь, накладывает ряд неудобств из-за невозможности внешней манипуляций на каждом шагу. Затем мне посоветовали поэкспериментировать с IDA Pro — эта программа умеет работать с архитектурой консолей PS1-2. Впоследствии я отказался от работы с IDA Pro и перешёл на более удобный мне способ извлечения и упаковки текста в исполняемых файлах. Тем не менее иногда я до сих пор открываю различные файлы PSX-EXE или ELF в IDA Pro для поиска каких-то данных, так как эта программа строит удобную карту взаимосвязей между различными функциями. Поэтому для начала я покажу вам, как искать поинтеры к строкам текстов в исполняемом файле с использованием IDA Pro и простого хекс-редактора. ⬜ Этап 1. Поиск любого текста в SLPS_254.50 через хекс-редактор и IDA Pro а) Открываем любой хекс-редактор и ищем текст. К этому моменту у нас уже должен быть набит глаз для таких поисков. Возьмём для примера блок со строками текста, в котором находятся названия сценок. Первая строка начинается со смещения 0x1133E0, следующая с 0x1133F8 и т.д. О том, что именно этот блок является текстом, можно легко понять, если использовать на этой области преобразование кодировки текста, о которой я уже писал во втором этапе в четвёртой главе. б) Теперь загружаем SLPS_254.50 в IDA Pro. Программа автоматически распознаёт файл как "ELF for MIPS", а среди перечня работы с архитектурой процессоров должна автоматически выбрать "MIPS little endian". Нажимаем "ОК" и ждём, как приложение просчитает взаимосвязи всех функций. После полного анализа вы услышите звуковое уведомление. Затем щёлкаем по вкладке "Hex View-1" и наблюдаем по головной части данных, что программа просчитала весь файл немного не так, как располагаются значения при открытии через хекс-редактор. Дело в том, что все смещения в IDA Pro указаны сразу с учётом расположения этих данных относительно оперативной памяти консоли. Поверьте, это весьма удобно для поиска поинтеров, которые имеют не фактический адрес. А ведь практически все поинтеры в исполняемом файле ELF именно такого типа. Теперь нам нужно найти здесь начало того же текста, как это было сделано в хекс-редакторе на смещении 0x1133E0. Для этого мы открываем в верхней строке вкладку "Search" и выбираем пункт "Sequence of bytes". Далее вводим все значения той самой строки, которую нашли через обычный хекс-редактор: 99 9c 9a 6e 9a 83 9a 8d 9a 5d 99 cd 9d 61 99 a6 99 cd 99 9d. Затем нажимаем "ОК" и, если всё написано верно, программа покажет расположение того самого текста. ⬜ Этап 2. Поиск поинтеров в SLPS_254.50 а) Обратите внимание на выделенные красным цветом смещения строк в хекс-редакторе и IDA Pro на предыдущих двух изображениях. Имея на руках оба этих адреса, мы можем спокойно высчитать поправку для поиска будущих поинтеров. Для этого берём числовое значение смещения 0x2123E0 (IDA Pro) и вычитаем из него значение 0x1133E0 (хекс-редактор), а как результат получаем число поправки FF000. Теперь, когда нам известно смещение, где находится текст и число поправки, мы можем высчитать значение поинтера и адрес его расположения. б) В этом и следующем пунктах я опишу метод поиска поинтеров через любой хекс-редактор. После того, как находим любую строку с текстом, запоминаем числовое значение смещения этой строки (в нашем примере это 0x1133E0), а затем к этому числу прибавляем поправку FF000 и получаем значение 002123E0. Если попытаться найти это значение через поиск, то у вас ничего не получится, потому что текущий вид этого значения имеет тип порядка байтов big-endian. Напоминаю, что принцип построения порядка байтов в поинтерах PS2 консоли имеет вид little-endian, а это значит, что необходимо развернуть полученное значение по байтам наоборот: 00 21 23 E0 >> E0 23 21 00. в) Теперь, когда у нас на руках есть реальное значение самого поинтера, то его можно легко найти в исполняемом файле. Просто копируем 4 байта "E0 23 21 00" в строку поиска и жмём искать по всему файлу. Результатом должно быть одно найденное место, которое и будет являться поинтером. Запоминаем, что начало и конец этого поинтера находятся на смещениях 0xF5368 и 0xF536B. г) Метод поиска поинтеров через IDA Pro гораздо проще, чем через хекс-редактор. Потому что вся разница сводится к тому, что на этапе 1 в пункте "б", найденный текст по первому байту уже подсвечивается смещением, которое можно спокойно вводить в поиск в пункте "Sequence of bytes". Только не забудьте во всплывающем окне поиска поставить галочку "Find all occurences", чтобы поиск работал по всему файлу. Достаточно просто искать поинтеры таким вот способом, не правда ли? Если посмотрим на весь диапазон поинтеров, которые располагаются друг за другом выше от найденного указателя, то обнаружим, что все поинтеры, которые скучкованы в этом блоке, находятся в диапазоне от 0xF42A8 до 0xF536B. Всё, что находится за пределами этого диапазона — это уже совсем другие данные или другая группа поинтеров. Именно с этим диапазоном нам и нужно будет дальше работать. Потому что найти всё это одно дело, а составить алгоритм для правильной адресации, извлечения текстов с учётом разделителей, вставки изменённого текста с учётом пересчёта поинтеров и многого другого — совсем другая задача, которая требует использования совсем других подручных средств. В этом нам поможет приложение "abcde", которое я указал среди перечня сборника уникальных программ во второй главе, а также небольшое дополнение к нему под названием "ELF Text Injector", которое я специально заказывал у RikuKH3, чтобы облегчить себе работу по вставке текстов в ELF-файлы. Далее я поэтапно покажу, как пользоваться этими приложениями, которые не имеют графический интерфейс и в которых все настройки прописываются в основном в качестве числовых значений. ⬜ Этап 3. Установка Strawberry Perl, Python и работа с приложением abcde а) Для начала необходимо установить Strawberry Perl. Это бесплатный дистрибутив на языке программирования Perl для операционных систем Windows. Он включает в себя всё для запуска и разработки Perl-приложений. Скачать его можно с официального сайта: https://strawberryperl.com. Без этого abcde работать нормально не будет, так как приложение написано на этом языке. После этого требуется установить дистрибутив Python. "Он тоже бесплатный, но на другом одноимённом языке программирования. Его тоже можно скачать с официального сайта: https://www.python.org/downloads. Один из моих знакомых Ethanol (уважаемый программист) написал специальный код на языке Python для работы с приложением abcde. Поэтому будем использовать его наработки. б) Далее к этому пункту я прилагаю архив с приложением abcde v0.0.10, который включает в себя все готовые настройки для работы с нашим типом поинтеров. Его можно распаковать в любую папку. Внимание!!! Для корректной работы программы и всех скриптов необходимо, чтобы путь к программе не содержал никаких пробелов. В противном случае приложение не будет извлекать текст и вставлять его обратно. Скачать #1 https://temple-tales.ru/games/tor/data_design/files/abcde_v0.0.10.zip Скачать #2 (зеркало) https://disk.yandex.ru/d/CRbc-SWxnXHC-w Красным я выделил файлы, которые были созданы дополнительно для работы с приложением, а зелёным - те, которые относятся к ресурсам игры: исполняемый файл и таблица с кодами для правильной идентификации кодировки игры. в) Теперь нужно корректно настроить работу программы для извлечения строк текста. Сначала подготавливается TBL для работы с кодировкой игры (ToR.tbl). Об этом я уже рассказывал в четвёртой главе. Только разница с программой CODES в том, что abcde читает другой формат таблицы. Разделитель значений здесь другой. Кроме того, программа ругается на использование символов "<" и ">", а значит, в нашей таблице мы их опустим и заменим на "[" и "]" соответственно. Готовая таблица в формате TBL для приложения abcde прилагается в архиве, ссылка на который размещена в прошлом пункте. г) Далее настраиваем работу с поинтерами через файл "!abcde_script_skits.txt". Все строки настроек я описывать не буду — пройдусь по основным, которые необходимы для понимания принципа работы. Этой базовой информации хватает для того, чтобы работать с исполняемыми файлами консолей PS1-2 и других аналогичных файлов, в которых поинтеры лежат в открытом виде. #GAME NAME: Tales of Rebirth Здесь указывается название игры. Данная строка ни на что далее не влияет, и является по своей сути простой меткой на случай, если у вас будет накоплено много файлов данного типа для разных игр. #BLOCK NAME: Skits В этой строке прописывается название блока текста. А это на тот случай, если таких скриптов будет много в рамках одной игры. В принципе, можно даже указать название файла, если в нём всего 1 блок поинтеров и создавать другие нет надобности. #POINTER ENDIAN: LITTLE С этого параметра начинается ввод важных данных, которые дают понять, с каким типом порядка байтов программе необходимо работать: big-endian или little-endian. В нашем случае это little-endian (особенность платформы PS2), но если бы мы работали с какой-нибудь игрой на ПК, то, скорее всего, пришлось бы указать big-endian. Приложение считывает синтаксис в этой строке только в таком виде: BIG LITTLE #POINTER TABLE START: $F42A8 #POINTER TABLE STOP: $F536B Помните, как был найден диапазон поинтеров для блока названия сценок? Об этом я писал на этапе 2 после пункта "г". Именно этот диапазон и нужно прописывать в этих двух строках. Одна из них указывает начало смещения, с которого начинается таблица поинтеров для данного блока, а вторая указывает самый последний байт крайнего поинтера в этом блоке. Приложение считывает синтаксис в этих строках только в таком виде: $***** Вместо звёздочек нужно написать смещение. #POINTER SIZE: $04 Помимо типа порядка байтов, программа учитывает и размер поинтеров. Они бывают по 2 и 4 байта. Соответственно, в этой строке приложение будет считывать только следующий синтаксис: $02 $04 #POINTER SPACE: $00 Если так случилось, что между поинтерами есть какое-то пространство, то эту особенность можно прописать в этой строке. Приложение будет учитывать эти пробелы между поинтерами, а если поинтеры идут друг за другом без дополнительного пространства, как в нашем случае, то необходимо указывать просто нулевое значение. Приложение считывает синтаксис в этих строках только в таком виде: $** Вместо звёздочек нужно написать размер в байтах, которое будет соответствовать дополнительному пространству. Наглядное представление пространства между поинтерами при просмотре через хекс-редактор на изображении ниже (поинтеры выделены голубым цветом): #BASE POINTER: $-FF000 Одно из первостепенных неудобств при работе с поинтерами в исполняемых файлах это то, что всегда нужно учитывать поправку. Разумеется, в этом приложении предусмотрен учёт разницы между фактическим расположением поинтеров в файле и оперативной памяти. Здесь приложение считывает синтаксис в этой строке только в таком виде: $-***** Вместо звёздочек нужно написать размер поправки. #TABLE: ToR.tbl Ну и напоследок стоит упомянуть таблицу кодов, которую здесь тоже нужно прописывать в виде названия файла. Именно на эту таблицу приложение и будет опираться во время извлечения строк с текстом. д) Заранее подготавливаем файлы с командами для извлечения и вставки текста через командную строку: Файл 1, извлечение !abcde_dump_skits.bat perl abcde.pl -m bin2text -cm abcde::Cartographer "SLPS_254.50" "!abcde_script_skits.txt" Tales_of_Rebirth_dump_skits -s pause Файл 2, вставка !abcde_inception_skits.bat perl abcde.pl -m text2bin -cm abcde::Atlas "SLPS_254.50" Tales_of_Rebirth_dump_skits.txt pause Все файлы должны находиться в корневой папке приложения. е) После того, как закончили готовиться к работе, копируем исполняемый файл игры в директорию программы и нажимаем пакетный bat-файл "!abcde_dump_skits.bat". После обработки получаем файл с извлечёнными строками текста "Tales_of_Rebirth_dump_skits.txt". Если всё сделано корректно, то вы увидите вот такое сообщение в командной строке: ж) Файл с извлечёнными строками текста будет выглядеть примерно так: Первые несколько частей содержат дублирующую информацию из настраиваемого файла скрипта, но в немного изменённом виде, а чуть ниже уже идут строки с метками #JMP и //POINTER #0. С метками поинтеров всё просто. Для каждого поинтера есть свой индивидуальный блок с множеством сегментов. Здесь сразу указаны смещения поинтера и строки, порядковый номер и сами строки с извлечённым текстом. Когда вы сделаете множество вот таких файлов с извлечёнными строками с текстом, то все блоки с поинтерами и прилагаемыми к ним данными можете копировать между собой или объединять в один файл без ограничений, а нумерация #0, #1, #2 и т.д. не будет мешать самому процессу работы. Данные номера — это просто заметка о порядковом номере извлечения. Так что в них нет ничего особенного. А вот что касается метки #JMP, то это вспомогательный сегмент, о котором стоит рассказать подробнее в следующем пункте, так как его роль очень важна. з) #JMP — это отдельная настройка, которую программа высчитывает самостоятельно и которая потребуется нам дальше для обратной вставки изменённого текста. В извлечённом файле данная строка имеет вот такой вид: #JMP($1133E0, $1195C0) // Jump to insertion point В скобках указан диапазон смещений между первым байтом первой извлечённой строки и последним байтом последней строки. Иначе говоря, данный интервал даёт нам представление о размере той области, в которой находятся извлечённые строки с текстом. Это очень полезная информация, и её нужно куда-то выписывать отдельно. Потому что, как я говорил в начале этой главы, в исполняемом файле есть несколько десятков отдельных блоков поинтеров, соответственно, и областей с текстом тоже. При обратной вставке текст нужно укладывать строго в те области, в которых изначально находился японский текст. Только таким образом в коде игры мы ничего не сломаем. Когда я активно занимался исполняемым файлом и идентифицировал все блоки поинтеров и области текста, то составил несколько строк с диапазоном, куда программе можно укладывать текст. Если кому-то интересно, то вот этот список: 112EA0;11332E 113DBC;1195C6 119890;11C8A6 11C8A8;11D99E 11D9A0;11E36E 11E370;11E88E 11E890;11F38E 11F3C0;11FCDE 11FCE0;1200B5 120228;1206C6 1206D8;120776 120778;12280E 122B30;12A63E 12A640;12AAAE 12AB28;12AFC6 12B0E8;12B15E 12B1A0;12BACE 12BAD0;12D0FE 12DCA0;12EBBE 12EBC0;12EF76 12EFF0;130A5E Внимание!!! При обратной вставке текста программа использует файл с извлечёнными строками текста "Tales_of_Rebirth_dump_skits.txt", а это значит, что во время этого процесса менять диапазон, прописанный в строке #JMP, можно как угодно. Это очень удобно, так как объём переведённого текста всегда отличается в большую или меньшую сторону. Возможность укладки текста в доступные области ограничена лишь вашими собственными нуждами. В общем, как вам удобно, так и выбирайте. Но к этому нужно подходить с умом, потому что когда областей мало, то расчёты сводятся к минимуму, а когда нужно работать с огромным количеством областей, то тут уже требуется провести достаточно большое количество расчётов. и) После того, как были извлечены все строки с названиями сценок в диапазоне 0xF42A8 - 0xF536B, их все можно переводить в этом документе ТХТ, но это достаточно неудобно, так как файл слишком большой, и в нём не так просто ориентироваться. А если учесть то, что таких файлов придётся сделать несколько десятков, то приходит понимание, что всё это нужно как-то систематизировать. В этом нам поможет Microsoft Excel. Для этого я создаю отдельную таблицу с фильтрами для столбцов, а также присваиваю каждой строке свой ID, чтобы всегда можно было развернуть порядок строк на обратный, как оно есть в исходном файле, а также сместить все лишние строки вниз, чтобы они не мешали во время процесса перевода. К этому пункту прилагаю готовый файл для экселя, а также на изображении ниже наглядно показываю, как выглядит текст до сортировки текста и после того, как всё упорядочено: Скачать #1 https://temple-tales.ru/games/tor/data_design/files/Skits.xlsx Скачать #2 (зеркало) https://disk.yandex.ru/i/z-J4JIO7-zVtSw к) Как только текст переведён, можно отсортировывать все строки согласно корректным значениям алфавитного порядка по колонке ID, а затем выделить весь текст и скопировать его в файл с извлечёнными строками "Tales_of_Rebirth_dump_skits.txt". л) Обратная вставка строк с текстом в исполняемый файл осуществляется через командную строку. Для этого просто запускаем пакетный bat-файл, о подготовке которого я упоминал ранее: Файл 2, вставка !abcde_inception_skits.bat perl abcde.pl -m text2bin -cm abcde::Atlas "SLPS_254.50" Tales_of_Rebirth_dump_skits.txt pause Если всё сделано корректно, то вы увидите вот такое сообщение в командной строке: Внимание!!! Всегда проверяйте числовые значения, которые прописаны в командной строке после вставки. Приложение прописывает там весь диапазон области для вставки, а также сколько байт было записано. Если общий объём вашего переведённого текста будет превышать установленный диапазон для вставки, то в командной строке программа уведомит вас о том, сколько байт было превышено. м) В завершении этого этапа хочу отметить, что перед тем, как вставлять текст обратно в исполняемый файл, необходимо отредактировать файл с таблицей кодов. Так как для извлечения текста нужен один набор кодов, а для обратной вставки он немного поменяется, потому что в файле шрифта игры при адаптации кириллицы приходится использовать многие коды для русских букв. Именно поэтому всегда нужно иметь наготове 2 файла с таблицей кодов: для японской версии и для русской. Это далеко не всё. Ведь всегда можно улучшить и как-то оптимизировать процесс запаковки или вставки текста. В самом начале главы я упоминал про дополнительную программу "ELF Text Injector" авторства RikuKH3. Дело в том, что работа с abcde хоть и решает множество задач, но во время вставки текста всегда тянет за собой весь дистрибутив, а также не учитывает оптимизацию текста. Именно поэтому в какой-то момент мне захотелось облегчить процесс. Я заказал у RikuKH3 данную программу и кратко описал задачу: что именно мне требуется для работы с Tales of Rebirth, а также чтобы это по необходимости можно было применить к любым другим файлам. Использование данной программы полностью заменяет пункт "л" на этапе 3. Приложение вы можете скачать из таблицы сборника уникальных программ во второй главе. А уже саму настройку и использование программы я опишу на этапе 4. ⬜ Этап 4. Использование ELF Text Injector для оптимизации вставляемого текста а) В первую очередь важно понять, что ELF Text Injector распознаёт синтаксис abcde и для вставки использует файл извлечённого текста "Tales_of_Rebirth_dump_skits.txt". Ничего заново настраивать не нужно. Кроме того, приложение также подхватывает таблицу кодов TBL. Всё, что требуется, это подготовить файл с командами для вставки текста через командную строку, а также создать дополнительный файл "tor_elftext.lst" со списком диапазона смещений, в которые будет укладываться текст. Выглядит этот файл со списком вот так: б) Обратная вставка строк с текстом в исполняемый файл осуществляется через командную строку. Для этого просто запускаем пакетный bat-файл, о подготовке которого я упоминал в прошлом пункте: !1_Text_Injector_RUN.bat @copy /y SLPS_254.50 SLPS_254.50_new > NUL tor_elftext.exe -LittleEndian "tor_elftext.tbl" "!2_ELF_Russian_compiled.txt" "SLPS_254.50_new" @pause Если всё сделано корректно, то в командной строке вы увидите вот такое сообщение: Как и в случае с abcde, данная программа уведомляет о том, сколько байт было записано из доступного диапазона. в) Но это всё, по сути, тоже самое, что и при использовании самого abcde. А вот что гораздо важнее — ELF Text Injector делает оптимизацию текста и экономит место во время укладки в заданный диапазон. Для полного понимания плюсов этого алгоритма на нём стоит остановиться подробнее. Дело в том, что разработчики множества игр используют как раз-таки этот метод. Его суть заключается в том, что если в процессе перевода имеется две и более строки с одинаковым текстом, то есть дубликаты, то программа укладывает только одну строку, а все поинтеры содержат адрес к этой самой строке. В результате у нас не записываются остальные дублирующие строки, а значит, происходит экономия места. Если попытаться изобразить это в хекс-редакторе, то выглядеть это будет примерно так:

Конечно! Куда без этого xD Тем не менее, в будущих главах я перейду на описание моментов, когда самому приходилось в проекте делать всё остальное, что не было сделано (в техническом плане).

История русской локализации Tales of Rebirth (PS2) Глава 5. Разбор дополнительных файлов и начало работы с оверлеями https://vk.com/temple_of_tales_translations https://temple-tales.ru/games/tor/russian_localization.html Пока Рейнджер был занят написанием кода по моему заказу, я искал остальные не найденные тексты, которые относились преимущественно к части игрового меню (хроника, различные описания, руководство, названия предметов и врагов, открытия, магазины и многое другое). Таким образом, через просмотр оперативной памяти эмулятора во время игрового процесса я обнаружил текст в следующих файлах: а) 11190.bin — хроника (краткое описание всех событий игры). б) 11181.pak3 — меню (заголовки, кнопки, настройки и многое другое). в) 00013.pak3 — различный текст, который отображается в сражениях (в том числе и диалоги, которые появляются на движке боевой системы). г) 11217.bin — энциклопедия (описания врагов, руководство и история сражений). д) SLPS_254.50 — заголовки, кнопки, имена, названия и описания (сценки, враги, тактика, скрытые характеристики, приёмы, предметы, сплавка, рецепты, титулы, открытия и локации), а также другие различные тексты, которые не используются в игровом процессе. По мере того, как RangerRus обновлял приложение ToR toolkit, я подкидывал ему вышеперечисленные файлы, которые тоже просил разобрать. С 11190.bin особо проблем не было, так как это самый обычный текстовик: в головной части находятся поинтеры, а всё, что ниже — это склейка строк с разделителем {00} между ними. Перед тем как приступить к описанию следующих файлов, нужно рассказать об отдельных особенных файлах, которые частенько встречаются в нашем деле фанатских локализаций. Речь пойдёт об оверлеях (overlays). Чтобы получше объяснить, что это и для чего, пожалуй, стоит немного рассказать о характеристиках консолей старого поколения. PS1 на борту имела 2 МБ оперативной памяти и 1 МБ видеопамяти, а уже более старший брат PS2 обладал 32 МБ и 4 МБ видеопамяти. В рабочем режиме консоли сначала загружают данные в оперативную память. Для разного рода игр PlayStation 1-2 этого могло хватать, но для более сложных этого было уже недостаточно. Поэтому в качестве решения была придумана система разделениях одной программы на отдельные сегменты (оверлеи), где каждая часть является отдельным файлом. Во время игрового процесса, по мере необходимости, главный исполняемый файл может подгружать и выгружать нужные оверлеи. К примеру, если вы исследуете какую-то локацию в игре, то в оперативной памяти находится главный исполняемый файл и составляющие, а как только вы вступаете в битву, то система будет выгружать часть ненужных данных и подгружать оверлей, отвечающий за все скрипты, которые необходимы в этой части игрового процесса. Именно таким типом файлов и является 11217.bin. Этот файл служит запуском и просмотром всей энциклопедии. Соответственно, среди всех этих данных оверлея и лежит текст описаний врагов, всего руководства и историй сражений. В первой 1/5 части файла находится основной код, а чуть ниже — поинтеры, которые записаны не прямыми указателями к строкам, а с учётом расположения этого файла в оперативной памяти консоли. Это означает, что для работы с этими поинтерами нужно высчитать разницу между фактическим расположением строк и расположением в оперативной памяти. Иногда эту разницу называют "поправкой". В нашем случае поправка для многих оверлеев в Tales of Rebirth (PS2) является числовым значением 2D8900. Высчитать эту разницу можно двумя способами. Первый способ для продвинутых пользователей, которые понимают, как работать с отладчиком эмулятора PCSX2. В тот момент я даже близко не понимал, что это за функционал и как к нему подступиться. Поэтому пришлось пойти по более простому пути. Второй способ заключается в том, что, зная месторасположение поинтеров и области текста, вы запоминаете смещение первого символа из области текста, а потом ищете поинтер с наименьшим значением адреса из всего набора поинтеров. Затем берём значение наименьшего поинтера и вычитаем из него значение фактического адреса первого символа из области текста. В итоге мы получаем число, которое и будет являться той самой поправкой. Внимание!!! Иногда с помощью второго способа высчитывания вы можете сразу не найти корректное число поправки. Если так случилось, то вам, скорее всего, попалась ситуация с расположением строк в обратно порядке. Это когда строки в файле располагаются от последнего к первому. В таком случае вам нужно начать поиски не сверху вниз, а с самого низа к верху. Если даже в этом случае вам не улыбнулась удача, то, скорее всего, вы столкнулись с ситуацией, когда строки в области текста не идут по старшинству от меньшего к большему и наоборот, а просто имеют хаотичный порядок. В этом случае корректное высчитывание поправки может затянуться на очень долгое время. Тогда больше ничего не остаётся, кроме как методом тыка пробовать вычитать значения в произвольном порядке. Это далеко не всё, что следует рассказать об этом типе файлов. На приведённом изображении ниже я наглядно показал, что помимо основных областей, в хвосте файла есть область с дополнительным кодом и условно пустая область, заполненная нулевыми значениями. Работать обычным образом с такой структурой не представляется возможным и, разумеется, это накладывает множество ограничений. В первую очередь нужно сразу понять, что ничего лишнего стирать в оверлеях нельзя. Потому что это код, который в процессе работы может что-то переписывать среди своих данных. Именно поэтому пустую область исполняемых файлов использовать так просто нельзя, потому что если вы всё же попытаетесь записать туда какие-то данные, то вы рискуете нарушить обычный порядок вещей, который был задуман разработчикам. В самом худшем случае это может привести к зависаниям и вылетам, либо просто повлечёт за собой удаление текста во время игрового процесса. Без понимания принципа работы системы не так уж просто найти причину пропадания текста. Именно поэтому в пустые области оверлеев нельзя размещать любые данные. Следующее ограничение вытекает из принципа самого устройства оверлеев. Раз уж мы не можем ничего прописывать в пустые области, то не можем и увеличивать в размерах сам файл. Так как запись оверлея в оперативную память жёстко привязана к определённому смещению, а значит, после записи этого файла в оперативную память следуют какие-то другие не менее важные данные. Область работы исполняемого файла и оверлеев — это особая область работы с кодом в оперативной памяти на консоли, в которой слишком узкие рамки. Это не тот тип файлов, которые можно спокойно расширять (как, например, файлы с диалогами). Следовательно, мы подходим к тому, что записывать новые данные мы можем только в ограниченную область текста оверлея. В нашем случае у файла 11217.bin это диапазон: 6B70 — 134FE. Когда мы только начинали работать с текстом этого файла, я даже и не подозревал, что нам не хватит места на весь объём переведённого текста. В демонстрационных релизах локализации мне приходилось сокращать часть строк, чтобы текст умещался. Но это не было решением проблемы. Потому что сокращать приходилось очень много. Впоследствии эту проблему нам помог решить программист Ethanol, которому пришлось переписать приличную часть кода игры, чтобы чтение половины текста происходило не из оверлея, а совсем из другого места, но об этом я расскажу гораздо позже в другой главе, когда дело дойдёт до описания реверс-инжиниринга. В итоге на тот момент я попросил Рейнджера написать алгоритм, который высчитывает количество знаков переведённого текста. Если общее значение превышает число под отведённое пространство в оверлее, то программа об этом уведомляет. Таким образом это было лишь временное решение, чтобы уже можно было проверять изменения в игре. Следующие файлы 11181.pak3 и 00013.pak3 оказались ещё одним типом контейнеров. Внутри 11181.pak3 находился такой же обычный бинарный файл с текстом, как и описанный мной выше 11190.bin. В контейнере он шестой по счёту. Здесь располагался текст отдельной части меню (заголовки, кнопки, настройки и многое другое). Я попросил Рейнджера сделать распаковку и запаковку текста без работы с самими контейнером по отдельности. А вот описанию контейнера 00013.pak3 уделю побольше внимания. Внутри находятся три оверлея, которые подгружаются во время сражений. Последний из них содержит нужный нам текст для перевода. Структура этого файла выглядит примерно так: - Основной код (~80%) - Поинтеры - Дополнительная область с кодом - Поинтеры - Дополнительная область с кодом - Поинтеры - Дополнительная область с кодом - Область текста - Дополнительная область с кодом - Область текста - Поинтеры - Дополнительная область с кодом - Область текста - Дополнительная область с кодом - Поинтеры - Дополнительная область с кодом - Пустая область (~10%) Как видите, здесь очень много областей разного типа, распределённых на части. Тем не менее с этим файлом мы справились, и проблем он нам особо не доставил, потому что огромная часть текста этого файла используется только в режиме отладки (debug mode) для нужд разработчиков. Часть строк я спокойно сокращал, чтобы уместился весь наш перевод. Это можно делать без проблем, потому что большая часть функционала режима отладки из кода Tales of Rebirth была удалена, в отличие от других игр серии, например, Tales of Eternia и Tales of Phantasia. И поэтому в этой игре он вообще никак не задействуется. Но мы ещё вернёмся к этому файлу и остальным оверлеям в 00013.pak3, так как здесь тоже придётся проделать некоторые манипуляции во время реверс-инжиниринга. Ведь этот оверлей содержит в себе определённые ограничения, с которыми я столкнусь чуть позже, и это будет очень сильно мешать созданию качественной локализации этой игры. Что же касается всех остальных текстов игрового меню, которые находились в исполняемом файле SLPS_254.50, то RangerRus не захотел связываться с поиском всех поинтеров этого файла, объяснив это тем, что поиск будет слишком проблемным и долгим. Поэтому он предложил сделать так: выписать начало и конец всех смещений с полезным текстом; сделать их извлечение и обратную упаковку. Разумеется, я отказался, так это автоматически накладывало бы слишком жёсткое ограничение по количеству символов на 1 строку. Работать без изменения поинтеров — ужасная затея. Представьте себе ситуацию, когда для одной строки выделено 3 байта, а слово в этой строке "Axe". Без изменения поинтеров мы можем уместить только 3 символа на русском языке. А теперь помножьте это на 100, 1000 и более случаев с разного рода уникальных ситуаций. Вот примерно о таком хаосе и идёт речь, если пытаться переводить текст игры без изменения поинтеров. Об этой проблеме того времени и как она решалась я расскажу в следующей главе. Ведь в конце концов нам всё же удастся дотянуться до всего и изменить почти всё, что будет нужно для локализации.

История русской локализации Tales of Rebirth (PS2) Глава 4. Разбор основных форматов и поиск данных в оперативной памяти https://vk.com/temple_of_tales_translations https://temple-tales.ru/games/tor/russian_localization.html После того, как мы с Рейнджером определились с идентификацией всех основных форматов в главном архиве DAT и отсортировали их по папкам, мне нужно было решить, какие следующие форматы файлов заказать для разбора. Так как у меня уже был небольшой опыт работы над переводом Tales of Symphonia, я понимал, что, скорее всего, не вся часть текста будет в 2-3 разных форматах. Это было бы слишком просто. Если так случается, что диалоги — в одном формате, другой особый тип диалогов или текстов описаний — во втором, а весь текст менюшной составляющей — в третьем, то это неимоверная удача. Примерно так было в следующих играх: Tales of Xillia 1-2 (весь текст в одном формате), Tales of Legendia (диалоги и сценки в одном формате, а тексты меню — во втором) и в Tales of Symphonia: Dawn of the New World (весь текст диалогов, как и в Легендии, в одном формате, а все тексты, относящиеся к меню, скомпилированы во втором формате). Но Сказания Перерождения не тот случай. Это одна из тех игр старой школы, где каждая мелочь находится в разных местах и форматах. И, к сожалению, я не сразу сообразил, где все они располагаются. В будущем из-за этого мне придётся разбираться долго и кропотливо в каждом из них, потому что по каким-то мистическим обстоятельствам привлекать сторонних людей для помощи со многими другими нашими проектами получалось хорошо, а вот с Tales of Rebirth постоянно не везло. После долгих поисков и изучений файлов стало понятно, что основной текст с диалогами, сценками и прочим находится в файлах формата SCE. Однако они были сгруппированы по разным типам контейнеров. Основные диалоги находились в контейнерах SCPK, а сценки — в SKT (Рейнджер почему-то назвал этот тип контейнеров SCE, как и расширение текстового формата). В итоге вторая часть заказа для Рейнджера заключалась в разборе форматов SCPK и SCE. Я не стал заказывать разбор SKT, так как посчитал излишним работать с ещё одним уровнем распаковки и запаковки. Поэтому я попросил хакера сделать так, чтобы программа сразу извлекала файлы SCE из SKT и делала дампы текстов из них без вмешательства пользователя. Спустя несколько лет я об этом пожалею, потому что отдельную распаковку для SKT всё же нужно было заказать. Кроме того, как выяснится в будущем, в ресурсах будут контейнеры и других типов: PAK0, PAK1, PAK2 и PA3. Но об этом я расскажу позже в другой главе. В итоге в первые месяцы работы над переводом я решил пойти по пути отсеивания. Запустил игру и начал искать остальные встречающиеся тексты на экране через просмотр оперативной памяти эмулятора. Здесь стоит отдать должное уважаемому ромхакеру Артёму Филатову (TTEMMA). Он первый посоветовал этот способ и тем самым облегчил страдания, чтобы мне не пришлось искать бесконечно иголку в стоге сена, перебирая все распакованные файлы из главных архивов. Выбор пал на hex-редактор HxD. Ниже я распишу метод поиска через оперативную память и заострю внимание на каждом этапе по отдельности. Так как данный метод позволяет очень точно найти нужный файл, а также очень сильно облегчает процесс различных манипуляций практически с любыми файлами. ⬜ Этап 1. Работа с таблицей кодов а) Перед тем, как приступить к поиску текста в Tales of Rebirth, нужно настроить работу с таблицей кодов, так как в этой игре своя уникальная кодировка. Здесь стоит вспомнить помощь ромхакера StorMyu. В предыдущей главе я упоминал, что он предоставил таблицу кодов (TBL). Выглядит она примерно вот так: б) Если кому-то интересно, как она выглядит полностью, то можете скачать таблицу по этой ссылке (https://disk.yandex.ru/d/5Wk3yHVYCIHpxw) и оценить масштаб работы программиста. В ней около 3,5 тысяч знаков и значений, которые ему пришлось идентифицировать. Это очень муторная и кропотливая работа. Знаю не понаслышке, потому что мы делали то же самое с таблицей кодов для Tales of Phantasia (PS1). Кстати, в некоторых местах таблица у него неточная. Это я заметил уже в процессе работы над проектом. Поэтому со временем эту таблицу пришлось подкорректировать в соответствии с правильными значениями. Для наглядности приведу несколько примеров с изменениями: было > стало E27B=洲 > E27B=秀 E27C=秀 > E27C=秋 E27D=完 > E27D=終 E27E=終 > E27E=繍 E27F=繍 > E27F=習 в) Затем я настраиваю преобразование кодов в приложении CODES (упоминал во 2-й главе), которое отдельно заказывал у RangerRus специально для таких вот манипуляций. Чтобы можно было сделать быстрое преобразование из обычной японской кодировки Shift-JIS в уникальные значения игры и обратно. 99 A3; 82 9f; 99 A4; 82 a0; 99 A5; 82 a1; 99 A6; 82 a2; 99 A7; 82 a3; 99 A8; 82 a4; 99 A9; 82 a5; 99 AA; 82 a6; 99 AB; 82 a7; 99 AC; 82 a8; 82 9f; 99 A3; 82 a0; 99 A4; 82 a1; 99 A5; 82 a2; 99 A6; 82 a3; 99 A7; 82 a4; 99 A8; 82 a5; 99 A9; 82 a6; 99 AA; 82 a7; 99 AB; 82 a8; 99 AC; ⬜ Этап 2. Преобразование кодировки текста а) Теперь переходим непосредственно к описанию поиска текстов через оперативную память с последующим нахождением этого блока данных среди распакованных файлов игры. В первую очередь выбираем нужный текст на экране и делаем скриншот. б) Затем через программу для работы со скриншотами HprSnap выбираем нужную область текста, которую нужно распознать. в) После этого выбранную область вставляем в рабочее окно онлайн-сервиса Google Keep и дожидаемся обработки изображения. А потом жмём кнопку "Распознать текст". г) Далее копируем распознанный текст в один из рабочих файлов программы CODES, а потом запускаем обработку файла для преобразования символов из кодировки Shift-JIS в кодировку игры. д) И после, имея на руках преобразованный файл, открываем текстовый файл с преобразованными кодами в любом удобном hex-редакторе и выбираем область текста, которую нужно будет искать в оперативной памяти. ⬜ Этап 3. Поиск текстов через оперативную память а) Открываем hex-редактор HxD, нажимаем в верхней строке "Инструменты", а потом выбираем пункт "Открыть основную память". Из представленного списка процессов выбираем эмулятор PCSX2 и нажимаем "ОК". б) После того, как hex-редактор загрузит все значения эмулятора из оперативной памяти, открываем поиск с помощью горячих клавиш CTRL+F, затем выбираем вкладку "Hex-значения" и вставляем тот набор значений или текст, который я отметил в пункте "д": e8 93 9d 64 99 cd e8 fc 99 ba 99 b5 99 e3 99 c8. А теперь нажимаем "Найти всё" и ждём, когда редактор найдёт все адреса, в которых встречается данный текст. в) В появившемся списке найденных адресов просматриваем несколько совпадений, выбираем для проверки первый из них и сверяем его с нашим преобразованным текстовым файлом. Если всё совпадает, то это значит, что мы нашли область того самого файла, в котором находится данный текст. Внимание!!! Бывает так, что некоторые найденные данные могут не находиться в том файле, который необходимо найти. Если в следующем шаге поиски не увенчались успехом, то нужно проверять остальные найденные совпадения до тех пор, пока не найдёте нужный файл. По большей части это происходит потому, что разработчики организовали скрипт игры таким образом, чтобы данные из определённых мест дополнительно копировались в отдельные области оперативной памяти. Поэтому во время поиска вы можете наткнуться на дубликаты этих данных. Ещё бывают случаи, когда текст в оперативной памяти конструируется из отдельных блоков разных строк, но при просмотре оперативной памяти это может выглядеть так, будто это одна целая строка. г) Теперь, когда в оперативной памяти найден файл с нужным нам текстом, можно приступить к поиску самого этого файла в распакованном архиве. Для этого мы открываем приложение Total Commander и находим директорию с распакованными файлами из архива DAT.BIN, а потом нажимаем в верхней строке на кнопку "Инструменты" и выбираем пункт "Поиск файлов". В открывшемся окне настраиваем поиск файлов в соответствии с тем, как указано на скриншоте ниже. Нужно обязательно поставить галочку в пункте "HEX-код", если мы будем искать текст из шестнадцатеричных значений. В поле с текстом вводим набор значений, который я отметил в пункте "д": e8 93 9d 64 99 cd e8 fc 99 ba 99 b5 99 e3 99 c8. После этого жмём на кнопку "Начать поиск" и ждём завершения. Как я показал на примере ниже, данный текст находится в файле 11190.bin. Это своеобразный текстовый файл, в котором находится весь текст хроники. Внимание!!! На последнем этапе вам может показаться, что можно было пропустить поиск текста через оперативную память и после пункта "д" (выбор преобразованного текста) сразу приступить к пункту "и" (поиск с помощью Total Commander). Да, так сделать можно, и в какой-то момент вам будет сопутствовать удача, но рано или поздно вы столкнётесь с тем, что таким способом найти можно не все тексты. Потому что часто бывает, что текст находится совсем не там, где вы ищете с помощью Total Commander. Допустим, если какой-то из распакованных файлов — матрёшка, а в нём находится нужный нам текст, но он сжат или зашифрован, то поиск не увенчается успехом. Поиск текста через оперативную память позволяет убедиться в том, что текст действительно находится в оперативной памяти, и код игры его обрабатывает. Разумеется, при условии, что текст представлен в обычном виде, а не в виде глифов (бывают и такие случаи). Кроме того, поиск через оперативную память позволяет выбрать из найденной области любой диапазон значений и использовать их для дальнейшего поиска с помощью Total Commander. Также найденный текст можно попробовать изменить и посмотреть, как отобразятся изменения в реальном времени во время игрового процесса. Это очень удобно для проверки различных значений кодировки текста. А ещё данным методом можно искать в оперативной памяти не только текст, но и любые другие данные, если вы понимаете, как это нужно делать.

История русской локализации Tales of Rebirth (PS2) Глава 3. Начальный этап исследования игровых ресурсов https://vk.com/temple_of_tales_translations https://temple-tales.ru/games/tor/russian_localization.html Дело было в 2014 году. После хакинга Tales of Symphonia я снова обратился к RangerRus по поводу разбора ресурсов Tales of Rebirth PS2-версии. Он ответил, что в головной части главных архивов DAT.BIN, FLD.BIN, MOV.BIN отсутствуют указатели к файлам. Это означает, что основные бинарники являются просто склейкой файлов. Где искать таблицу с указателями — неизвестно. В тот период у меня не было хороших знакомых на сцене ромхакинга, да и я сам понятия не имел, где именно среди файлов искать эту таблицу. Сам RangerRus тоже не понял, где искать, хотя, скорее всего, ему просто не хотелось тратить время на её поиски. Почему я так решил? Дело в том, что сейчас я сам могу спокойно разобраться в большей части таких моментов, когда бинарник находится в одном месте, а таблица к нему — в другом. Метод поиска я чуть позже распишу в следующей главе. А тогда я попытался связаться с французским ромахакером StorMyu, который в 2010 году основал собственный мультиязычный проект по переводу Tales of Rebirth. Он занимался сразу обеими версиями: PS2 и PSP. На одном из форумов он не отвечал, потому пришлось попытать удачу через электронную почту. В итоге StorMyu пошёл мне на встречу и согласился помочь, правда, только небольшой консультацией. Делиться наработками в виде программ он не захотел. StorMyu дал понять, что таблица находится в исполняемом ELF-файле, а ещё указал смещение (т.е. офсет - так называют адрес, указывающий на начало определённых данных в заданном файле), с которого начинается сама таблица. Также он предоставил таблицу кодов (TBL) к текстам игры. И на этом, пожалуй, всё. Но эта помощь стала отправной точкой, и дело наконец-то пошло в гору. Таблица находилась по смещению 0xD76B0 в файле SLPS_254.50. Так как ToR — игра для консоли PS2, то принцип построения порядка байтов в поинтерах здесь имеет вид little-endian, что характерно для этой платформы. Это тип поинтеров, у которых порядок байтов начинается от большего значения к меньшему, так что легко можно прочитать и понять адрес, если просто развернуть этот порядок. Для простоты понимания, поинтеры (указатели) - это участок памяти размером по 2 или 4 байта, указывающий на начало данных другого участка памяти (в нашем случае - файлов, строк, таблиц и т.д.). После этого RangerRus сделал первую ревизию приложения ToR toolkit. На тот момент она могла лишь распаковывать и запаковывать главные архивы DAT.BIN, FLD.BIN, MOV.BIN с учётом декомпрессии и компрессии внутренних файлов. Практически все файлы в бинарниках имели тип сжатия 3 (LZSS+RLE). Но благо, что в сети уже была программа COMPTOE по работе с этим типом сжатия. За неё стоит сказать спасибо уважаемому ромхакеру Carlos Ballesteros Velasco (Soywiz). Это такой интересный человек, руководивший испанской командой "Tales Translations", которая занималась фанатскими переводами игр серии Tales of (https://blog.tales-tra.com). За время своей деятельности они успели перевести на испанский язык Tales of Destiny (PS1), Tales of Eternia (PSP), Tales of the Abyss (PS2) и Tales of Vesperia (X360). Soywiz решил не утаивать свои труды и поначалу размещал репозитории практически всех своих проектов. Правда, в какой-то момент он перестал это делать, но в будущем нам ещё повезёт: репозиторий перевода Tales of the Abyss (PS2) был одним из последних загруженных на GitHub, что очень сильно помогло уже в нашем проекте по переводу TotA. Впрочем, это уже совсем другая история. Гораздо позже я обнаружил, что почти во всех играх Namco Tales Studio используется тип сжатия 3 (LZSS+RLE). Так что в будущем программа COMPTOE позволит нам распаковать практически любой файл во множестве игр серии Tales of и даже совладать с особыми контейнерами-матрёшками. Если все файлы в главном архиве сжаты, то это нормально. Так делают многие разработчики. Но если разжатый файл является контейнером, а внутри него — множество файлов, и среди них есть те, которые сжаты снова, а в разжатом виде опять определяются как контейнеры, то это уже второй уровень — в глубину. То есть когда внутри контейнера находится ещё один контейнер. Бывает даже три уровня в глубину и более. Поверьте на слово: например, в ресурсах Tales of Graces f (PS3) встречаются файлы, которые удаётся достать только лишь погрузившись в глубину на три уровня и более. Временами я буду делать лирические отступления, чтобы немного рассказать вам о том, как работа с Tales of Rebirth положительно повлияла на множество других наших переводов. А ещё, пользуясь моментом, планирую освещать деятельность других команд и людей, которые были причастны к нашему общему делу и оставили в нём свой след. Возвращаясь к анализу главных архивов, стоит пройтись по всем основным форматам, которые там находятся. Здесь я приступил к изучению того, что находится внутри каждого из них и что следует сразу отсекать. В файлах FLD.BIN для локализации нет ничего необходимого, поэтому описание этого файла я опущу. В MOV.BIN находятся все видеофайлы в формате PSS (видео MPEG2 и аудио SS2). Но обрабатывать их все необязательно. Для локализации потребуются только эти файлы: 00.mpg - опенинг 13.mpg - титры 17.mpg - сюжетный видеоролик в Белсасе 18.mpg - эпилог 19.mpg - пролог И вот мы подбираемся к самому основному архиву - DAT.BIN. Именно здесь и находится всё самое основное, что мы будем искать.

История русской локализации Tales of Rebirth (PS2) Глава 1 + Глава 2 https://vk.com/temple_of_tales_translations https://temple-tales.ru/games/tor/russian_localization.html Все ссылки для скачивания программ указаны в статье на сайте. Глава 1. Сборник базовых программ Первое, с чего стоит начать, – это описания базовых программ. Большая часть из них вам должна быть знакома, а какими-то, скорее всего, вы уже пользуетесь (например, Microsoft Excel). В статье я приложил таблицу, в которой указал их основные функции, сослужившие службу во время реализации нашего проекта, а также ссылки для скачивания этих программ. Отдельно стоит упомянуть онлайн-сервис Google Keep. Для его работы обязательно требуется аккаунт в Google. Это очень мощный инструмент по распознаванию текста на изображениях, который выдаёт лучший результат по сравнению с конкурентами. В нашем деле он очень сильно пригодился во время составления лок-кита, но об этом я расскажу позже. 01. Microsoft Excel - Программа для работы с электронными таблицами. 02. Notepad++ - Продвинутый текстовый редактор. 03. WinMerge - Приложение для сравнения и слияния текстовых файлов. 04. Google Keep - Оптическое распознавание текста, дающее результат высокой точности. 05. Photoshop - Продвинутый графический редактор. 06. Jasc Paint Shop Pro 9 - Простой графический редактор. 07. OPTPiX iMageStudio 3.12a - Графический редактор для создания и редактирования текстур платформы PS2. 08. HprSnap 5.6 - Программа для быстрого захвата изображений с экрана и их редактирования. 09. Crystal Tile 2 - Универсальный редактор тайловой графики. 10. TileMolester v0.19b - Альтернативный редактор тайловой графики. 11. TiledGGD v2.1.2.1 - Альтернативный редактор тайловой графики. 12. Texture Finder v2.1 - Утилита для поиска текстур в различных файлах. 13. Hex Editor Neo v6.54 - Универсальный hex-редактор с огромным набором функций. 14. HxD 2.5 - Простой hex-редактор с минимальным набором функций. 15. Total Commander 11.56 Extended - Гибкий файловый менеджер. 16. UltraISO 9.7.6.3860 - Создание и редактирование различных форматов образов CD/DVD-дисков. 17. Sony Vegas - Универсальный видеоредактор для монтажа видео и аудиообработки. 18. TMPGEnc Video Mastering Works 5 - Приложение для перекодирования видео. 19. PSS demux v1.05 - Инструмент для расклейки видеофайлов формата PSS на отдельные части: видео (MPEG2) и аудио (WAV). 20. Cube Media Player 2 - Проигрыватель для извлечения аудио- и видеофайлов из игр на платформе PS2. 21. MFAudio 1.1 - Аудио конвертер форматов платформы PS2. 22. Audacity - Аудиоредактор звуковых файлов, который предназначен для работы с несколькими дорожками. 23. ps2str - Инструмент для склеивания аудио (SS2) и видео (MPEG2) файлов в формат PSS. Глава 2. Сборник уникальных программ В этой главе я кратко описал все программы, которые были созданы специально для работы над этим проектом и указал ссылки для их скачивания. Многие из них универсальны – они стабильно продолжают облегчать процесс работы над нашими проектами. А ещё я упомянул зарубежные разработки фанатов, без которых многие моменты дались бы гораздо тяжелее в плане перевода и укладки текста. Впоследствии в остальных главах я частенько буду ссылаться на эти программы, так как о них нужно будет рассказать подробнее. 01. ToR toolkit Разработчик: RangerRus - Распаковка/запаковка файлов форматов dat, scpk, sce. - Распаковка/запаковка отдельных файлов: 11190.bin, 11181.pak3, 00013.pak3, 11217.bin. 02. CODES Разработчик: RangerRus - Программа для обработки текстов с заданной таблицей кодов (tbl). (Только для работы с текстами; не работает с некоторым диапазоном HEX-значений между строками 0d и 0a) 03. TXTCompile Разработчик: RangerRus - Склейка всех текстовых файлов в единый массив данных с указанием исходных названий файлов. - Расклейка единого массива данных на отдельные текстовые файлы. 04. TxSrt Разработчик: RangerRus - Анализ текстового файла и создание списка дубликатов строк этого файла. - Сортировка и удаление из текстового файла заданных дубликатов строк. - Обратная сортировка текстового файла с возвращением заданных дубликатов строк. 05. copyfiles Разработчик: RangerRus - Копирование всех файлов заданного типа во всех директориях и поддиректориях в отдельную папку. - Обратное перемещение всех файлов заданного типа из общей папки в исходные директории и поддиректории. 06. COMPTOE Разработчик: Soywiz - Компрессор/декомпрессор файлов, которые имеют тип сжатий 1 (LZ77) или 3 (LZSS+RLE). 07. HexFileReplace Разработчик: XiGMA - Вставка "файла 1" в любой "файл 2" по заданному смещению. 08. Mass Replace HEX Разработчик: XiGMA - Программа для обработки текстов с заданной таблицей кодов (tbl). (В отличие от приложения CODES, работает со всеми диапазонами HEX-значений) 09. GameScriptEditor Разработчик: Lady3millennium - Специализированный текстовый редактор с рядом уникальных функций, который упрощает работу с текстом в процессе перевода, а также имеет окно предварительного просмотра с преобразованным текстом в соответствии с набором различных условий. 10. ExtractorExcelToText Разработчик: Lady3millennium - Извлечение текста из Excel в текстовый файл с заданным диапазоном и возможностью перезаписи. 11. SearchingDuplicatedStrings Разработчик: Lady3millennium - Анализ текстового файла и упорядоченное создание списка дубликатов строк этого файла. (В отличие от приложения TxSrt, сортирует все дубликаты в одном месте для того, чтобы можно было отследить количество дубликатов каждой строки) 12. TextToHexConverter Разработчик: Lady3millennium - Преобразование текста в шестнадцатеричные значения. (В отличие от онлайн-декодеров, данная программа не имеет ограничений и позволяет работать с текстами больших размеров и любым количеством строк, а также позволяет задавать нужные интервалы и символы между значениями) 13. Pakomposer (v1.9fix2) Разработчик: Infernal - Распаковка и запаковка контейнеров, которые имеют тип 0, 1 и 3. - Анализирует файлы и применяет декомпрессор COMPTOE, если файлы имеют тип сжатий 1 (LZ77) или 3 (LZSS+RLE). - Анализирует распакованные файлы и применяет компрессор COMPTOE, если файлы необходимо сжать типом 1 (LZ77) или 3 (LZSS+RLE). 14. abcde Разработчик: abw - Универсальное извлечение и вставка текста с гибким набором настроек. 15. ELF Text Injector Разработчик: RikuKH3 - Вставка дампа текста, созданного через приложение "abcde: Atlas + Cartographer", в заданный файл с учётом оптимизации (дубликаты строк заменяются одной общей строкой, адрес к которой присваивается всем прилегающим к ней поинтерам). 16. ToR MFH to TIM2 Extractor Разработчик: TTEMMA - Извлечение файлов TIM2 из контейнера MFH. 17. TextRangeModule Разработчик: TTEMMA - Вставка заданных значений в любой файл по заданному смещению. (В отличие от приложения HexFileReplace, здесь заданные значения и смещения указаны только в отдельном текстовом файле) 18. SFM2 module Разработчик: Ethanol - Извлечение/вставка текста из типа файлов SFM2. 19. Pakomposer (v1.10fix2) Разработчик: Ethanol - Обновлённая версия программы старой программы "Pakomposer v1.9fix2", которая корректно строит парсинг файлов, а также учитывает формат разметки области хранения данных для контейнеров. 20. tn_anp3 Разработчик: SymphoniaLauren - Конвертор графических файлов из формата anp3 в TIM2. 21. ToR Toolset (PSP) Разработчик: Vash - Распаковка/запаковка типов файлов: dat, scpk, skt, sce. 22. armips Разработчик: Kingcom - Реверс-инжиниринг через ассемблер armips для применения различных хаков.

История русской локализации Tales of Rebirth (PS2) Введение Добрый вечер! На связи админ Evil Finalist. Пришло время делиться с вами информацией о процессе работы над Сказаниями Перерождения, который длился все эти годы. Так как этот проект стоит особняком и о нём лучше рассказывать совершенно в другом ключе, то придётся посвятить этому несколько постов. Ведь работа над Tales of Rebirth приближается к концу, а перед всеми релизами, вышедшими из-под нашего пера (Tales of Eternia и Star Ocean 6: The Divine Force), мы делимся интересной информацией. Впоследствии все записи по этой теме соберём в отдельную статью и выложим её на нашем сайте. А пока что напишу немного вводных слов, чтобы вы понимали, чего стоит ожидать в ближайшие месяцы. Эта история про одну из самых капризных локализаций, которую мы пытались начать в 2014 году. Подумать только, прошло почти 12 лет. Какое-то время меня не покидала мысль, что этому не будет конца и края. Но особая любовь к этой видеоигре не давала опустить руки. Tales of Rebirth не является каким-то эталоном или шедевром в жанре японских RPG, но у неё есть своя уникальная сердцевина, явно выделяющаяся на фоне других тайтлов. Она может затянуть и не отпускать. За прошедшие годы работы над проектом у нас накопилось множество интересных ситуаций. На сегодняшний день большая часть из них не представляла бы таких трудностей, как 5-10 лет назад. Ведь тогда я совершенно ничего не понимал: ни в разборе ресурсов игр, ни в монтировании видео, ни в обработке текстур, поинтерах и в том, как с ними взаимодействовать, а также как работать с hex-редактором и со многим другим. Особую сложность добавляло ещё то, что эта игра не была официально переведена на английский язык, а также в сети отсутствовали какие-либо фанатские релизы – так было вплоть до конца 2024 года. В нашей команде никогда не было постоянного программиста или ромхакера, как у наших коллег по цеху, который всегда мог бы быть на подхвате и решать любые проблемы в каждом проекте. Поэтому на начальном этапе нам посильную помощь оказал RangerRus – ему посвящена отдельная запись (vk.com/wall-181931421_2526). Рейнджер справился с главными архивами и базовыми форматами, а потом ушёл со сцены фанатских переводов. В процессе работы с готовым материалом я обнаружил, что при первичном анализе файлов было пропущено много текстов и текстур. На самом деле ресурсы Tales of Rebirth таят в себе гораздо больше сюрпризов и ограничений, чем могло показаться на первый взгляд. Необходимо было найти всё остальное, но на тот момент я понятия не имел, как к этому подступиться. Именно поэтому мне пришлось искать других умельцев, которые могли бы решить разные задачи или помочь в ромхакинге добрым советом. Обо всех этих людях я непременно расскажу в будущих записях. Очень часто поиски и просьбы о помощи заходили в тупик, и ряд задач приходилось решать самому. Со временем анализ структуры файлов привёл к пониманию того, что даже без знания языков программирования можно вполне справляться своими силами – не обязательно всегда просить о помощи там, где оступился. Тем не менее, методом проб и ошибок можно очень долго блуждать и ни к чему не прийти. Именно поэтому я хочу рассказать свою историю погружения в ромхакинг и сцену фанатских переводов на примере проекта Tales of Rebirth. Начну с самого начала, когда я ещё был совсем зелёным, и дойду до текущего момента, когда могу решить достаточно большое количество задач в наших проектах, до сих пор не зная при этом ни одного языка программирования. И так может абсолютно каждый, потому что люди придумали очень много вспомогательных материалов и программ. А если что-то не получалось найти или хотя бы подобрать близкие аналоги, то я заказывал у разных ромхакеров уникальные программы, которые задумывались так, чтобы облегчать процесс работы над переводами практически для любого желающего. Разумеется, я планирую показать всё это наглядно, со скриншотами, а также загрузить все описанные программы, чтобы любой, кто захочет, мог ими воспользоваться. Надеюсь, для кого-то эти будущие записи станут полезными, а кто-то, может быть, и вовсе посмеётся от души ввиду дилетантского подхода в начале пути, так как многие проблемы можно было действительно решить ещё тогда. Но не стоит забывать, что если не знаешь где искать, то многие задачи воспринимаются настолько неподъёмными, что кажется, будто ищешь иголку в стоге сена. Искренне извиняюсь, если мой стиль письма в техническом плане местами будет непонятным, но по-другому многие стороны этой локализации никак не объяснить.

Всё работает. Этот тот же самый японский образ. Просто он сверху нами отредактирован под нужды локализации. Но тут следует понимать, что md5 чек сумма (или CRC32) будет отличаться, а значит для работы pnach надо будет отредактировать строку с чек суммой на ту, которая будет у локализованного образа.

Там же всё написано. Особенно в пункте "дополнительный хакинг". У нас перевод полностью с японского языка, который прошёл кропотливую редактуру.

Ориентировочная дата выпуска полной русской локализации v1.000 Сейчас у нас идёт завершение редактуры Сказаний Перерождения и подготовка к финальному тестированию. Ориентировочную дату выпуска полной русской локализации v1.000 мы наметили на середину или конец лета этого года. Те, кто давно следит за переводом этой игры, знают, что мы пытались начать этот проект ещё аж в 2014 году, но сразу столкнулись с рядом проблем и ограничений. Радует, что теперь вся самая сложная работа в техническом плане осталась позади. За это время накопилось столько всего, чем непременно хочется поделиться в отдельных записях. В ближайшие месяцы до выпуска перевода мы запишем и покажем вам несколько видеодемонстраций, а также расскажем о проработке глоссария, как мы уже делали это по Tales of Eternia и Star Ocean 6: The Divine Force. Но это далеко не всё, на чём мы остановимся. Ряд последующих новостей будет также посвящён самому процессу нашей локализации Сказаний Перерождения. Ожидайте дальнейших новостей. Страница нашей локализации: https://temple-tales.ru/translations_torps2.html Немного истории в числах: - Начало проекта: 19.08.2014 - Пауза: середина 2015 — конец 2020 - Демо перевод v0.005: 30.12.2020 - Демо перевод v0.012: 26.07.2021 - Демо перевод v0.040: 26.06.2022 - Демо перевод v0.075: 08.07.2023 - Демо перевод v0.201: 27.09.2024 - Завершение проекта: 1 квартал 2026 - Дата релиза: 2-3 квартал 2026 УЧАСТНИКИ ПРОЕКТА: - Evil Finalist (Вадим Стрежов): руководство проекта, разбор ресурсов, вставка контента, работа с текстурами и видео, перевод (меню) - Coronel Karol (Каролина Лебедева): редактура и перевод (сценарий, сценки, квесты, НИПы, хроника и меню), перевод глоссария - Shiro: перевод (сценарий, сценки, квесты, НИПы, хроника и меню) - Polka (Динара Овчинникова): работа с текстурами, логотип - RangerRus: хакинг, разбор ресурсов ДОПОЛНИТЕЛЬНЫЙ ХАКИНГ: - Ethanol - Julian Lightfellow - SymphoniaLauren - Stewie - StorMyu - Evil Finalist - Riku_KH3 - TTEMMA - RedCode УЧАСТНИКИ ТЕСТИРОВАНИЯ v1.000: - OldSchool Jill (Юлия Андреева): тестирование на эмуляторе PCSX2 - Litrics (aka Syrin) (Анастасия Степанова): тестирование на эмуляторе PCSX2 - Lost Dreamer (Сергей Аненко): тестирование на эмуляторе PCSX2 - Coronel Karol (Каролина Лебедева): тестирование на эмуляторе PCSX2 - Evil Finalist (Вадим Стрежов): тестирование на PS2 FAT и платформе Steam Deck OLED УЧАСТНИКИ ТЕСТИРОВАНИЯ ДЕМОПЕРЕВОДОВ: - Scorp666ion (Максим Гребенщиков) - Dmitry Caelum (aka Stella) (Дмитрий Каелум) - Vikent (Викентий Денисов) - Kagiri-To (Павел Хезин) - Coronel Karol (Каролина Лебедева) - Evil Finalist (Вадим Стрежов) - Allegretto (Евгений Овчинников) - Polka (Динара Овчинникова) УЧАСТНИКИ СОЗДАНИЯ РУССКОГО КАВЕРА "Good Night / Спокойной ночи": * Кавер выполнен командой Harmony Team - Roanne: вокал - Cleo-chan, j.am, Polka, Yuki Eiri: перевод и адаптация лирики - HaruWei, Epistafy: звукорежиссура - Evil Finalist: Работа с субтитрами ⬜ ТЕКУЩАЯ ИНФОРМАЦИЯ О ЛОКАЛИЗАЦИИ ВСЕХ ПУНКТОВ ИГРЫ: (1) Технический план: 🟢 100% Разбор ресурсов 🟡 095% Текстуры 🟢 100% Видеоролики 🟢 100% Вставка контента 🟡 090% Редактура 🟡 090% Тестирование (2) Текстовый план (диалоги): 🟢 100% Сюжет 🟢 100% НИПы 🟢 100% Надписи 🟢 100% Сценки 🟢 100% Квесты 🟢 100% Битвы 🟢 100% Глоссарий (3) Текстовый план (меню): 🟢 100% Синопсис 🟢 100% Энциклопедия 🟢 100% Бестиарий (названия) 🟢 100% Бестиарий (описания врагов) 🟢 100% Открытия 🟢 100% Титулы 🟢 100% Предметы 🟢 100% Рецепты 🟢 100% Форс (приёмы) 🟢 100% Куб форс 🟢 100% Тактика 🟢 100% Скрытые способности 🟢 100% Локации (описания) 🟢 100% Руководство (сражения) 🟢 100% Магазины (названия) 🟢 100% Система поставки продуктов 🟢 100% Кнопки и другие мелочи (меню) 🟢 100% Кнопки и другие мелочи (сражения) 🟢 100% Настройки 🟢 100% Магазин бонусов 🟢 100% Титры 🟢 100% Саундтрек (трек-лист) (4) Дополнительный хакинг: 🟢 100% Реверс-инжиниринг для поддержки субтитров в видеороликах (софтсабы) 🟢 100% Реверс-инжиниринг для поддержки субтитров в битвах (софтсабы): а) проставление таймингов в соответствии с текстом и озвучкой б) проставление имён озвученных персонажей и сверка с озвучкой в) субтитры дополнительных сюжетных диалогов, победных лозунгов, реплик во время исполнения приёмов и т.д. 🟢 100% Реверс-инжиниринг для поддержки полной кириллицы в текстуре 00001.tm2: а) расширение количества русских букв до 33-х для 3-х типов шрифта в битвах и меню б) приведение в полное соответствие кодировки в диалогах и во всех остальных областях игры, значения которых отличались в) исправление отображения всех символов кириллицы во всплывающих названиях скрытых способностей во время битв 🟢 100% Исправление отображения ширины знаков в диалогах 🟢 100% Центрирование текста в сценках 🟢 100% Перенос кнопки "Далее" в отдельных сценках 🟢 100% Уменьшение размера пробела между словами (в 2 раза) 🟢 100% Исправление отображения знака ";" 🟢 100% Добавление новых иконок стихий вместо кандзи 🟢 100% Исправление ограничения вывода текста в битве с Вальту 🟢 100% Добавление предмета "яблочное желе" в 4 магазина в начале игры (как в PSP-версии) 🟢 100% Перенос строки "СНАРЯЖЕНИЕ ЗАКАЛЕНО" вниз для корректного отображения других всплывающих строк (в битвах) 🟢 100% Исправление алфавитной сортировки названий врагов в энциклопедии 🟢 100% Расширение окон описаний врагов в энциклопедии 🟢 100% Перенос и расширение вместимости текста в энциклопедии 🟢 100% Исправление моноширинного шрифта на обычный во всплывающих строках при получении ингредиентов из волшебного котелка 🟢 100% Исправление моноширинного шрифта на обычный в разных строках меню в пунктах поставки продуктов 🟢 100% Исправление моноширинного шрифта на обычный в разных строках энциклопедии 🟢 100% Добавление дополнительной строки в названии типов ландшафта на карте мира и центрирование текста в обоих строках 🟢 100% Исправление переносов строк и отображения ширины знаков в хронике 🟢 100% Перестановка ячеек, всплывающих при приготовлении блюд после битв для их корректного отображения Оставайтесь с нами. Дальше будет только интереснее ; ) ------------------------------------------------------------------------------------ Наше основное сообщество по переводам ВКонтакте: https://vk.com/temple_of_tales_translations Наше сообщество по конкурсам ВКонтакте: https://vk.com/temple_of_tales_quiz Наше музыкальное сообщество ВКонтакте: https://vk.com/temple_of_tales_music Наш телеграм-канал: https://t.me/temple_tales Наш Discord: https://discord.gg/hsbhqPyCW2 Наш YouTube канал: https://www.youtube.com/@temple-tales

Скачать с сайта: https://temple-tales.ru/translations_toeps1.html Группа в ВК: https://vk.com/temple_of_tales_translations Канал Ютуба: https://www.youtube.com/channel/UCJfDLKD1ClnKgLBdf7eblNA Японский > Русский Рады представить вам финальную версию нашего перевода Сказаний Этернии. На этот проект мы потратили 1,5 года. Общее время работы над переводом составило около одного года, а всё остальное время ушло на редактирование, тестирование, работу с текстурами и видео. Данный проект представляет собой перевод текста и текстур на русский язык, а также включает в себя русский кавер опенинга игры. Версия 1.00 позиционируется как полная, а её перевод составляет 100% от общего количества контента. Игра была переведена полностью с японского языка в одно лицо уважаемой Каролиной Лебедевой (Coronel Karol). Раздачи на рутрекере созданы не будут, так как содержимое нашего перевода не соответствует правилам этого ресурса. Скачать перевод можно по ссылке выше в сообщении. Желаем вам приятной и увлекательной игры! УЧАСТНИКИ ПРОЕКТА: - Вадим Стрежов (Evil Finalist): руководство проекта, работа с текстурами и видео, вставка контента - Каролина Лебедева (Coronel Karol): перевод (сюжет, сценки, квесты, НИПы и меню), редактура - Riku_KH3: хакинг, разбор ресурсов, работа с шрифтами, внедрение субтитров в сценки - Артём Филатов (TTEMMA): хакинг окон рамок и координат построения текста УЧАСТНИКИ ТЕСТИРОВАНИЯ v1.00: - Анастасия Степанова (Litrics aka Syrin): тестирование на эмуляторе PPSSPP - Юрий Усков (ZeroCold1981): тестирование на эмуляторе PPSSPP - Каролина Лебедева (Coronel Karol): тестирование на эмуляторе PPSSPP и консоли PS Vita - Вадим Стрежов (Evil Finalist): тестирование на эмуляторе PPSSPP и консоли PS Vita УЧАСТНИКИ КАВЕРА "Flying": - Екатерина Шадринцева (miru): вокал - Динара Овчинникова (Polka): перевод с английского, адаптирование лирики - Егор Зрайковский (БАКА): звукорежиссура - NeXoGone: работа с видео - Вадим Стрежов (Evil Finalist): работа с субтитрами Альтернативная ссылка на VK Video: https://vk.com/video-181931421_456239190 ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: 1. Перевод словаря имён и терминов: https://temple-tales.ru/games/toe/dictionary.html 2. Перевод интервью с разработчиками: https://temple-tales.ru/games/toe/interview.html

ВНИМАНИЕ, КОНКУРС!!! Перед выпуском нашего полного перевода Tales Of Eternia мы хотим объявить о начале второго конкурса "Найди ошибку". Его суть очень проста. Кто найдёт больше всего орфографических, пунктуационных и лексических ошибок, а также опечаток, тот и станет победителем. Всего будет 3 призовых места. Конкурс продлится до 31 января 2025 года 20:00 по московскому времени. Не упустите свой шанс! ВСЕ ПОДРОБНОСТИ ЧИТАЙТЕ В НАШЕМ ОТДЕЛЬНОМ СООБЩЕСТВЕ ПО КОНКУРСАМ: https://vk.com/temple_of_tales_quiz ✅ Призы: А) Игровые консоли – Sony Playstation Vita (Fat) – Nintendo Switch Lite Б) Лицензионные диски - Tales of Graces f Remastered (PS5) - Tales of Graces f Remastered (Switch) - Tales of Symphonia Remastered Chosen Edition (Switch) - Tales of Arise (PS4) - Tales of Arise (PS5) - Tales of Vesperia + Tales of Berseria + Tales of Zestiria Compilation (PS4) В) Лицензионные фигурки (тип А) - Tales of Berseria - Velvet ~ 1/8 scale (Kotobukiya) - Tales of Zestiria - Edna ~ 1/8 scale (Alter) - Tales of Zestiria - Sorey ~ 1/8 scale (Kotobukiya) - Tales of Zestiria - Mikleo ~ 1/8 scale (Kotobukiya) - Tales of Zestiria - Alisha Diphda ~ 1/8 scale (Alter) - Tales of the Abyss - Luke fone Fabre ~ 1/8 scale (Alter) - Tales of Vesperia - Yuri Lowell ~ Ichiban Kuji Tales of Series (Banpresto) - Tales of Vesperia - Raven ~ 1/8 scale (Alter) - Tales of Vesperia - Flynn Scifo ~ 1/8 scale (Alter) - Tales of Graces f - Asbel Lhant ~ 1/8 scale (Alter) - Tales of Graces f - Cheria Barnes ~ Ichiban Kuji Tales of Series 20th Anniversary (Banpresto) - Tales of Xillia - Milla Maxwell ~ 1/8 scale (Alter) - Tales of Xillia - Milla Maxwell ~ Ichiban Kuji Tales of Series (Banpresto) - Tales of Xillia - Jude Mathis ~ 1/8 scale (Alter) - Tales of Xillia 2 - Ludger Will Kresnik ~ Ichiban Kuji Tales of Series 3 (Banpresto) Г) Лицензионные фигурки (тип Б) - Tales of Phantasia - Dhaos ~ Trading figure (Kotobukiya) - Tales of Phantasia - Mint Adenade ~ Trading figure (Kotobukiya) - Tales of Phantasia - Klarth F. Lester ~ Trading figure (Kotobukiya) - Tales of Phantasia - Chester Barklight ~ Trading figure (Kotobukiya) - Tales of Phantasia - Suzu Fujibayashi ~ Trading figure (Kotobukiya) - Tales of Destiny - Rutee Kartret ~ One Coin Grande Figure Collection (Kotobukiya) - Tales of Destiny - Lion Magnus ~ One Coin Grande Figure Collection (Kotobukiya) - Tales of Destiny 2 - Judas ~ One Coin Grande Figure Collection (Kotobukiya) - Tales of Symphonia - Kratos Aurion ~ One Coin Figure Series (Kotobukiya) - Tales of Symphonia - Shihna Fujibayashi + Corrine ~ One Coin Figure Series (Kotobukiya) - Tales of Symphonia - Lloyd Irving ~ One Coin Figure Series (Kotobukiya) - Tales of Symphonia - Collet Brunel ~ One Coin Figure Series (Kotobukiya) - Tales of Symphonia - Genius Sage ~ One Coin Figure Series (Kotobukiya) - Tales of the Abyss - Guy Cecil ~ One Coin Grande Figure (Kotobukiya) - Tales of the Abyss - Jade Curtiss ~ One Coin Grande Figure (Kotobukiya) - Tales of the Abyss - Natalia Luzu Kimlasca-Lanvaldear ~ One Coin Grande Figure (Kotobukiya) - Tales of the Abyss - Anise Tatlin ~ One Coin Grande Figure (Kotobukiya) - Tales of Vesperia - Raven ~ One Coin Figure Collection (Kotobukiya) - Tales of Vesperia - Flynn Scifo ~ One Coin Figure Collection (Kotobukiya) - Tales of Vesperia - Duke Pantarei ~ One Coin Figure Collection (Kotobukiya) - Tales of Vesperia - Rita Mordio ~ One Coin Figure Collection (Kotobukiya) - Tales of Vesperia - Patty Fleur ~ One Coin Figure Collection (Kotobukiya) - Tales of Vesperia - Estellise Sidos Heurassein ~ One Coin Figure Collection (Kotobukiya) ✅ Искать ошибки можно только в двух играх с нашим русским переводом: - Tales Of Phantasia (версия перевода 1.01) Скачать игру с переводом можно тут: https://temple-tales.ru/translations_topps1.html - Tales Of Eternia (версия перевода 1.00) Скачать игру с переводом можно тут: https://temple-tales.ru/translations_toeps1.html Все остальные неразыгранные призы перейдут в следующий конкурс, который планируется в 2025 году. Кроме того, список призов будет пополняться. Не бойтесь попробовать свои силы. Если вам понравится такая инициатива, то мы продолжим и дальше радовать вас подобными идеями. Желаем вам удачи!

Внедрение искусственных субтитров в сценки Мы уже не раз упоминали об уважаемом программисте Riku_KH3, который проделал огромную работу по многим нашим проектам. Но сегодня мы хотим вам рассказать об его уникальном хаке, который многих программистов просто ставит в ступор. Речь пойдёт про искусственные субтитры к тем сценкам (skits), которые доступны в английской версии игры. Изначально субтитры для обоих версий (PS1 и PSP) разработчиками предусмотрены не были. Сценки просто озвучены, и в них можно увидеть небольшие анимации с аватарками персонажей. Многим игрокам по разным причинам тяжело воспринимать на слух, и мы очень рады тому, что Riku_KH3 согласился внедрить искусственные субтитры. Отображаются они тем же шрифтом, что и все диалоги персонажей. Результат можно посмотреть на скриншоте, приложенном к этой записи. Данные сценки запускаются на карте мира при нажатии кнопки "SELECT".

Вы когда-нибудь задумывались о том, насколько разработчики и переводчики заботятся об удобстве чтения текста в диалогах? Бывает и такое, что даже официальные переводы не могут похвастаться ровными переносами строк. В основном это связано с тем, что в одних играх переносы строк автоматические и фиксированные, а в других их необходимо делать вручную. В Сказаниях Этернии есть чёткое ограничение по количеству как самих строк, так и количеству символов в одной строке. Если превысить показатель хотя бы на одну букву, то будет рушиться вся конструкция рамки и переносов. В этой записи мы хотим похвалить нашу переводчицу @Coronel Karol (Каролина Лебедева), которая во время всей своей работы над проектом старалась учитывать эти моменты, и по возможности красиво выровняла буквально все диалоги и различные описания в меню. Поистине достойный труд, как и любое достижение программистов в хакинге видеоигр! Результат можно посмотреть на нескольких скриншотах, приложенных к этой записи. Помимо этого, мы также хотим продемонстрировать показательные примеры плохих переносов текста в одном из официальных переводов – Tales Of Symphonia. Около 10-ти скриншотов будут размещены в одном из комментариев под записью в ВК, дискорде или телеграме. Гораздо большее количество примеров и спорные моменты официального перевода размещены в нашем сервере в дискорде, а также в группе в телеграме: Наш Discord сервер https://discord.gg/nGXe6yqZrW Ссылка на чат со скриншотами: https://discord.com/channels/1006944382856994816/1006947251362480178/1299643863127953439 Телеграм: https://t.me/temple_tales/1237/1467