Evil_Finalist

История русской локализации Tales of Rebirth (PS2) Глава 9. Создание лок-кита для переводчиков и редакторов (часть 1) https://temple-tales.ru/games/tor/russian_localization.html Наконец-то я подобрался к описанию одного из самых важных аспектов в истории наших локализаций - создания лок-китов. В первую очередь стоит более понятнее объяснить, что же это такое. Лок-кит (от англ. localization kit — «набор локализации») — это специально подготовленный разработчиками набор игровых данных в удобном для взаимодействия виде, которые подлежат локализации на другой язык. В основном эта разработка бывает в виде отдельного программного обеспечения (Memsource), но встречаются и иные проекты на облачной платформе (SmartCAT). В отдельных случаях они могут быть даже в виде таблиц Google. Если говорить простым языком, то это программа для переводчиков, в которой они могут свободно переводить весь игровой текст, учитывая контекст диалогов и различные комментарии от разработчиков, а также видеть любую другую информацию. Если вы попытаетесь поискать какие-нибудь официальные лок-киты в сети, то, скорее всего, ничего не найдёте. Потому что любой лок-кит — это индивидуальная разработка, предназначенная только для внутреннего использования, и к распространению она запрещена. Тем не менее, можно найти несколько скриншотов и хотя бы примерно представить, как выглядят лок-киты у разработчиков: 1) https://thehouseofthedev.com/materials/itogi-konkursa-pomoshch-v-lokalizatsii-ot-allcorrect-games 2) http://web.archive.org/web/20260123000547/https://thehouseofthedev.com/materials/itogi-konkursa-pomoshch-v-lokalizatsii-ot-allcorrect-games Я тоже захотел сделать что-то подобное для переводчиков и редакторов в своей команде, потому что опыт работы над первым проектом Tales of Symphonia дал чёткое понимание того, что было сделано не так и что именно следует поменять. Поэтому, начиная с Tales of Graces f, я старался делать аналог лок-китов практически для каждого нашего проекта, но объём выполняемых работ был так велик, что в какой-то момент я решил просить помощи и пытался привлечь к их созданию кого-то ещё. Чтобы качество проектов не падало, а создание лок-китов не затягивалось, я сделал себе установку — над лок-китами должны работать только те, кто не будет переводить, редактировать, рисовать, программировать и тестировать. Потому что если привлечь человека, выполняющего любую из этих работ, то гарантировано будет снижаться производительность проекта в целом. Вот к такому разделению задач мы и пришли. Считаю, что это идеальная организация работы — каждый занимается своим делом и никто никому не мешает. Я бесконечно признателен тем, кто в этой затее с лок-китами пошёл мне на встречу. Ведь именно благодаря этим людям удалось значительно ускорить работу над рядом проектов: @Иван Тырлов (Tactics Ogre Reborn) @Анатолий Перун (Star Ocean First Departure) @Викентий Селюцкий (Tales of the Abyss) @Юрик Машкин (Tales of Destiny PS1) @Екатерина Αгафонова (Tales of Destiny 2) @Алиса Суюшева (Tales of Legendia) Сложно подумать, в какой ситуации сейчас была бы наша команда, если бы не их помощь. Многие из них осилили создание лок-кита до самого конца, а кто-то всё ещё находится в процессе работы. Но, как бы то ни было, важно понять, что 1 человек создаёт только 1 лок-кит. Тем не менее, мне самому, как руководителю, тоже приходится заниматься лок-китами для всех остальных игр, с которыми помощи нет. Таким образом я полностью и под ключ осилил создание лок-китов по следующим нашим проектам: Tales of Graces f (PS3) Tales of Eternia (PSP) Tales of Rebirth (PSP) Valkyrie Profile Lenneth (PSP) Другая часть проектов у меня всё ещё в процессе, а некоторые из них близятся к завершению: Star Ocean 2 (PSP) Star Ocean 2 R (PC) Tales of Phantasia (PS1) Tales of Symphonia 2 (PS3) Tales of Destiny DC (PS2) Tales of Xillia 2 (PS3) Так что же такого важного таят в себе эти лок-киты, что я уделяю им так много внимания? Об этом я хочу рассказать подробно, описав каждое преимущество, так как все они облегчают работу не только с текстом, но и со всем проектом в целом: а) Хронологический порядок строк Это, пожалуй, самое главное преимущество, необходимое для полного понимания контекста в процессе перевода. Потому что в неотсортированном виде строки диалогов могут относиться к отдельным локациям. 1 файл — 1 локация. И весь текст, который на протяжении игры отображается в этой локации, будет сгруппирован в одном файле с привязкой к ней. Ещё реже бывают случаи, когда строки располагаются в хаотичном порядке. Стоит ли говорить о том, насколько неудобно переводчику ориентироваться во всём этом? Если человек знаком с сюжетом, персонажами, а ещё лучше, если проходил игру полностью и всё помнит, то это поможет ориентироваться в таком беспорядке. Но как быть тем, кто не знаком с сюжетом и не проходил игру? Именно в таких моментах и будет играть ключевую роль хронологический порядок строк. Это расположение строк сюжетных диалогов, разговоров с НИПами, различных уведомлений и многого другого в том порядке, в котором оно происходит от начала игры и до самого конца, вплоть до титров. б) Имена и пол персонажей Второе не менее важное преимущество — корректная идентификация персонажей и их пола. Создатель лок-кита проставляет все соответствующие имена в отдельной колонке, напротив строк с диалогами. Так сложилось, что в изначальных дампах текстов далеко не всегда есть информация об именах, а уж тем более о том, какого пола персонаж говорит конкретную фразу. И её наличие помогает избежать лишних проверок и запусков игры. Кроме того, это ещё сильнее позволяет углубляться в понимание контекста, так как в диалогах всегда важно понимать, кто и что сказал — у всех персонажей разный стиль речи и характер, а это играет очень важную роль в процессе перевода текста. в) Тип строки Практически в любой большой игре, помимо сюжетных диалогов и разговоров с НИПами, есть множество других строк с текстом. Это могут быть строки, относящиеся к квестам, дополнительным катсценам, различным уведомлениям, руководствам, хроникам, различным заголовкам и многое другое. Каждый тип строк требует разного подхода в процессе перевода. Например, в уведомлениях или руководствах недопустимо обращаться к игроку на "ты" (за исключением редких случаев). В лок-китах каждый тип строк выделяется визуально или прописывается в отдельной колонке, что тоже очень сильно помогает с определением текста и тем, как с ним работать. г) Местоположение Ещё одно значительное преимущество — это знание локации или отдельного места, к которому относится каждая строка. Это очень важная информация, потому что она тоже помогает углубляться в понимание контекста. Переводчику важно знать, где сейчас находятся персонажи: в каком городе, на каком этаже гостиницы или в какой области на карте мира. Данные метки также помогают быстро найти эти строки в самой игре, если требуется оперативно проверить какой-то момент. А ещё знание местоположения персонажей может очень сильно повлиять на сам процесс перевода текста, потому что бывают различные уникальные ситуации, когда кто-то из персонажей на одной из локации ведёт себя как-то иначе в соответствии с задумкой сценариста. д) Главы, планеты, миры и временные линии В каждой игре есть свои особенности в плане разделения текста — она может быть разделена по главам или каким-то другим образом. В некоторых играх персонажи путешествуют во времени, а где-то разработчики задумали повествование от лица разных персонажей. Все эти особенности по большей части тяжело как-то отмечать, но в лок-китах это легко решается отдельной колонкой, в которой прописывается, к какой части игры относится каждая строка. Всё это тоже очень важно для переводчика, потому что знание главы может помочь с корректным выражением поведения персонажа в нужном участке времени. Потому что не редки ситуации, когда один из персонажей с какого-то момента начинает вести себя совсем иначе, и это отражается в его речи. Ещё это помогает проверять текст в игре, потому что переводчик, редактор или тестеры будут знать, в каком моменте эта строка появляется. Например, если по сюжету повествование переключается на другого члена отряда и отдельная глава посвящена ему, а при взаимодействии с окружающими НИПами диалоги меняются только в рамках этой главы, то знание этого поможет тщательнее проверять диалоги в игре. К сожалению, когда человек работает с исходным текстом, то все эти моменты отследить очень тяжело, а значит, повышается вероятность совершения ошибок. е) Графическое выделение Удобство лок-китов ещё заключается в удобном графическом интерфейсе. Различные выделения всех сегментов очень сильно облегчают ориентацию среди разного типа информации в процессе локализации. Представьте себе ситуацию: сейчас вам нужно перевести только сюжетные диалоги ближайших катсцен, а в первоначальном, неотсортированном виде, в текстовом редакторе эти диалоги визуально сливаются с диалогами НИПов, диалогами из квестов и диалогами из дополнительных сценок. В случае работы с лок-китом переводчику не нужно пытаться как-то распознавать и искать сюжетные диалоги нужных катсцен, потому что они уже отмечены отдельным цветом или иным образом. ж) Другие языки Временами в процессе работы могут возникать ситуации, когда нужно оперативно проверить текст требуемой строки на другом языке. Лок-кит позволяет держать рядом несколько колонок на разных языках и постоянно обращаться к любой из них, чтобы проверить нужную информацию. Допустим, у вас под рукой японская, английская, испанская, немецкая и русская колонки с текстом. Если английские локализаторы в чём-то ошиблись, то проверить упущение можно по оригиналу на японском языке. А если возникает спорная ситуации с каким-либо именем или термином, то локализация на другом языке может помочь какой-нибудь полезной идеей, что расценивается как удобная и выгодная находка. Кроме того, если английская локализация отличается своеобразной вольностью, то японский оригинал помогает легче сориентироваться в том, а что же именно разработчики имели ввиду и какая была изначальная задумка, исказившаяся в процессе локализации на другой язык. Ещё стоит отметить такие фонетически подсказки в японском тексте как фуригана. Это даёт дополнительную пищу для размышления в процессе перевода текста. з) Озвучка Диалоги большей части современных игр в жанре японских РПГ практически всегда озвучиваются, что в принципе особо не доставляет каких-либо проблем в процессе перевода текста. Но как быть, если в игре озвучена далеко не вся часть диалогов? Есть очень много игр, где озвучены не все сюжетные кастцены. Одним из таких примеров является Tales of Eternia. В игре озвучены все сценки, а вот сюжетные диалоги — примерно на 1/3. В этом случае метки в лок-ките весьма к месту — в отдельной колонке указано, какие строки озвучены. Это очень важно, потому что интонация и сама манера голоса сэйю может сильно помочь в процессе перевода. Также не редки ситуации, когда текст и озвучка могут отличаться. Всё это хорошо помогает сориентироваться переводчику или редактору для точности перевода, чтобы текст не выбивался за пределы озвучки. и) Различные особенности Сам процесс перевода текста может иметь различные ограничения или другие особенности. Но как быть, если в отсортированном виде текст не содержит никаких данных по этому поводу? В этом и заключается очередное преимущество лок-китов, потому что здесь можно разместить сколько угодно дополнительных колонок, в которых создатель лок-кита прописывает всю необходимую информацию. Если строка требует особого подхода, например ввод пароля, то этот текст, скорее всего, будет иметь ограничение по количеству символов. Ещё бывают ситуации, когда в определённых строках текст выводится другим шрифтом, и этот шрифт в ресурсах игры имеет только верхний регистр — это тоже необходимо учитывать во время перевода. Количество уникальных ситуаций не счесть, потому что всё упирается в индивидуальные особенности игры. Иными словами, это просто отдельные заметки от разработчиков или создателя лок-кита, которые должны помогать лучше вникнуть в особенность отдельных строк текста. к) Технические метки Если у вас на руках текст в неотсортированном виде и без каких-либо дополнительных меток, то, скорее всего, вы не сможете нужным образом структурировать различные строки. В таком случае нас спасает очередное преимущество лок-китов — повторюсь, здесь можно сделать сколько угодно дополнительных колонок, прописывать в них различные данные и сортировать по ним весь текст так, как вам удобно. Например, если в игре кто-то из персонажей говорит на другом языке, который как-то особенно оформлен в тексте, а переводчику нужно просмотреть все подобные строки отдельно, то в лок-ките все они легко сортируются нажатием пары кнопок, а затем мгновенно возвращаются на место, потому что каждая строка имеет уникальный идентификатор (ID), с помощью которого всегда можно вернуть первоначальный порядок строк. л) Глоссарий Один из последних и не менее важных плюсов, который стоит упомянуть — наличие глоссария. Многие команды переводчиков сначала прорабатывают именно этот аспект. Постоянный доступ к сформированному списку различных имён, терминов и названий в лок-ките облегчает процесс работы и помогает не нарушать единообразие терминологии. За счёт постоянно доступа обеспечивается связность текста и единый стиль. На этом, пожалуй, стоит остановиться. Можно долго описывать преимущества лок-китов, ведь всё зависит от разработчиков: чем эффективнее разработка этой уникальной среды, тем быстрее и качественнее будет финальный результат локализации. Я мог бы ещё упомянуть такие дополнительные фичи, как отображение портретов персонажей с разными эмоциями или окно предварительного просмотра того, как будет выглядеть текст в самой игре с учётом подобранного шрифта, но это более глубокие нюансы, которые встречаются ещё реже. Думаю, вы всё больше и больше начинаете понимать, насколько это ценный труд. Всё это, разумеется, очень удобно, и может даже возникать ощущение, что в таком случае практически каждый элемент игры будет под рукой. Но насколько сильно лок-кит ускоряет сам процесс перевода по сравнению с работой в обычном текстовом редакторе? По моим ощущениям — в пределах от 15 до 40%, в зависимости от сноровки переводчика и редактора. Неплохо, не правда ли? Попытаюсь описать все основные моменты, из которых эти цифры получаются и складываются, что в свою очередь продолжает постоянно и стабильно экономить нам время: а) Уменьшение частых поисков информации и лишних действий Нет необходимости часто запускать игру или открывать видеопрохождение, чтобы найти нужный момент и проверить что-либо в зависимости от поставленной задачи. Кроме того, все поиски следующих катсцен или любого другого элемента сведены к минимуму. Потому что все строки расположены в хронологическом порядке и искать ничего не требуется. б) Исключение проблемы полов, имён персонажей и склонений Практически пропадает вероятность ошибиться с именами персонажей, их полом и привязки к строкам. Потому что в документе, в отдельной колонке, напротив строк с диалогами проставлены все имена. Зачастую при работе в обычном текстовом редакторе в исходном тексте могут отсутствовать метки имён персонажей или НИПов. Бывают случаи, когда рядом с сюжетными строками есть дополнительные строки с именами, но в строках, относящихся к НИПам, они отсутствуют. Это приводит к тому, что переводчик может неверно указать склонения различных слов, как того требует пол персонажа. Возможны и другие ошибки, связанные с неверной идентификацией персонажа, что ведёт за собой деформацию его характера, изначально задуманного разработчиками. в) Облегчение тяжёлой навигации и слабых ориентиров Навигация по всему лок-киту становится в разы легче благодаря множеству разных меток, отличающихся как цветом и жирностью букв, так и различными выделениями фонов. Работа в текстовом редакторе неудобна тем, что восприятие текста усложняется — он будто сливается в единое полотно, и нужно постоянно всматриваться и напрягать зрение, чтобы различать отдельные части и разбивать их в уме на сегменты. г) Быстрый просмотр текста строки на другой языке Отсутствует необходимость искать текст строки на другом языке, потому что напротив каждой строки есть колонка на другом языке. В нашем случае это японский и английский. Если у нас не будет лок-кита, то каждый раз придётся открывать дополнительный документ на другом языке и искать нужную строку. д) Полезные комментарии от создателя лок-кита Во время создания лок-кита его составитель в своей колонке может отмечать различные уникальные ситуации, чтобы потом переводчик или редактор обратили на это внимание. Например, в каком-то диалоговом окне область для текста фиксированная, и нужно уложиться в определённое количество символов. Чтобы избежать проверки этого места, можно заранее прописать необходимое число символов, и переводчик адаптирует свой перевод. Кроме того, некоторые строки активируются особым образом — для их запуска нужно что-то сделать. Знание этой информации также может повлиять на перевод текста. Ещё бывают ситуации, когда по тексту неизвестно, что именно произошло или к какому объекту подошли персонажи, а комментарий с описанием поможет переводчику сориентироваться, что в очередной раз сведёт проверки во время тестирования к минимуму. е) Возможность писать любое количество заметок Эта удобная функция есть только в лок-ките. Столбцов с заметками можно создавать сколько угодно. В то время как при работе в текстовом редакторе такой возможности нет, а заметки приходится хранить в отдельном файле. Кроме того, сам лок-кит обеспечивает возможность быстрого создания сборок с учётом хронологического порядка строк. Это достаточно удобно, потому что как только переводчик осилил новую главу, то можно вставить новый текст в игровые ресурсы и проверить его непосредственно в игре. Соответственно, это удобно и для распространения демонстрационных сборок, когда прогресс нужно обновлять в соответствии с выполненным количеством процентов, либо по главам. Стоит ли говорить о том, что работа с текстом без хронологического порядка строк практически исключает возможность создания сборок по главам? Надеюсь, я смог описать все стороны лок-китов так, чтобы вы смогли точно понять, на что они влияют сильнее всего и какой из этого можно извлечь результат. В довершение к данной главе хочу показать вам, как выглядит один из наших лок-китов к игре Tales of Eternia (PSP), над созданием которого работал я сам. Посмотреть его можно на изображении, приведённом ниже. Оформлялся он в виде электронной таблицы в Microsoft Excel. Если вам интересно «пощупать» его в самом приложении, то можете скачать документ по ссылке ниже. А уже в следующей главе на примере лок-кита по игре Tales of Rebirth (PS2) я наглядно покажу, что мне пришлось сделать, чтобы создать такой документ. Я попытаюсь оформить всё в виде инструкции для тех, кто отважится помочь нам в этом не лёгком деле с другими проектами. Скачать #1 https://temple-tales.ru/games/tor/data_design/files/Tales_of_Eternia_localization_kit_v1.0_by_Evil_Finalist.xlsx Скачать #2 (зеркало) https://disk.yandex.ru/i/j3kzCR14Ad-zYA

Tales Of Rebirth Сказания Перерождения テイルズ オブ リバース ДАТА ВЫХОДА: 16 декабря 2004 (япония) ЖАНР: jRPG ИГРОВЫЕ ПЛАТФОРМЫ: PlayStation 2 ИЗДАТЕЛЬ: Namco ЯЗЫК ПЕРЕВОДА: Русский РАЗРАБОТЧИК: Namco Tales Studio ЯЗЫК ОЗВУЧКИ: Японский БОЕВАЯ СИСТЕМА: 3-Line Linear Motion Battle System (1) Технический план: (2) Текстовый план: 100% Разбор ресурсов 100% Сюжет 100% Текстуры 100% НИП’ы и надписи 100% Видеоролики 100% Сценки 100% Вставка контента 100% Квесты 100% Редактирование 100% Синопсис 090% Тестирование 100% Меню и интерфейс 100% Глоссарий УЧАСТНИКИ ПЕРЕВОДА: 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 (Динара Овчинникова) Начало проекта: 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 ССЫЛКИ НА РУСИФИКАТОРЫ: Демо перевод v0.005: https://temple-tales.ru/translations/tor_ps2_ru_patch_v0.005.zip Демо перевод v0.012: https://temple-tales.ru/translations/tor_ps2_ru_patch_v0.012.zip Демо перевод v0.040: https://temple-tales.ru/translations/tor_ps2_ru_patch_v0.040.zip Демо перевод v0.075: https://temple-tales.ru/translations/tor_ps2_ru_patch_v0.075.zip Демо перевод v0.201: https://www.zoneofgames.ru/games/tales_of_rebirth/files/7667.html Полный перевод v1.000: 2-3 квартал 2026 Страница перевода на сайте: http://temple-tales.ru/translations_torps2.html Группа в ВК: ВК https://vk.com/temple_of_tales_translations Канал Ютуба: https://www.youtube.com/channel/UCJfDLKD1ClnKgLBdf7eblNA Обсуждение перевода на форуме сайта: http://temple-tales.ru/forum/index.php?showtopic=262 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Сбор средств на оплату услуг переводчика японского Tales Of Rebirth завершён. Начало: 26 января 2021 | Конец: 7 июля 2024 | Общее время: ~3 года 5 месяцев Собрано: 200 136,63 / 200 000 последнее обновление от 07.07.2024 Карта СберБанк: 5469 9802 0654 4716 ЮMoney/Яндекс кошелёк: 410011235819402 Список донатеров: http://temple-tales.ru/donations_tor_ps2.txt -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

История русской локализации Tales of Rebirth (PS2) Глава 8. Подготовительный этап работы с текстовыми файлами https://temple-tales.ru/games/tor/russian_localization.html Как только разобрались со всеми основными файлами, поинтерами и таблицей кодов, можно приступать к организации удобной среды для работы с текстом и его обратной вставки. Но перед этим я хочу ненадолго вернуться на 12 лет назад и показать на примере нашего первого проекта Tales of Symphonia, как плохо была организована работа по обработке текстовых файлов. Как говорится, первый блин комом. В самом процессе перевода текста и его обратной вставке выявилось очень много неудобств, которые впоследствии привели к выработке удобных алгоритмов, чтобы не топтаться на месте и не выполнять двойную, а зачастую даже тройную работу. Так уж сложилось, что RangerRus сформировал свою таблицу кодов для Симфонии в простой нумерации от <0001> до <9999> без возможности её правки, а я принял это как данность. Соответственно, в каком виде текст был извлечён, так мы с ним и работали. Мне даже не приходила голову мысль о том, что можно повлиять практически на всё что угодно на любом этапе в каждом процессе. В итоге мы получили чуть более 900 файлов вот в таком виде: На первый взгляд может показаться, что это даже удобно, так как бывают случаи, когда текст нагромождён куда большим количеством тегов, а также не имеет меток имён персонажей, в чём ориентироваться ещё сложнее. Но тут стоит уточнить: мы не пытались придать какой-то иной вид всем этим файлам ТХТ. Это значит, что переводчики каждый раз, снова и снова, открывали и закрывали буквально все файлы в текстовом редакторе — вручную. Это постоянно плодило много лишних операций. Ещё больше масла в огонь подливало приличное количество дубликатов строк, перевод которых постоянно приходилось копировать. А что ещё хуже, так это изменение перевода какого-то важного и часто встречающегося термина, который потом приходилось переправлять во всех остальных файлах. Звучит ужасно, не правда ли? Это пример абсолютной неорганизованности как самого процесса работы, так постобработки текста. В какой-то момент я решил сделать небольшую навигацию по файлам и, по сути, это был первый толчок к тому, чтобы в будущем создавать собственные лок-киты для облегчения работы с переводом, но об этом я расскажу позже в следующей главе. Как выглядела попытка первого варианта облегчения работы с кучей текстовых файлов можно посмотреть на изображении, приведённом ниже: В данной таблице указана общая информация по каждому файлу: название, тип, локация, описания, наличие НИПов, наличие диалогов с Зелосом (квест), наличие диалогов с котисами, процент перевода и редактирования, хронологический порядок файлов относительно сюжета и многое другое. Данный файл создавался мной в виде таблицы Excel в течение нескольких месяцев. Для того, чтобы заполнить все эти данные, мне потребовалось пройти игру ещё один раз, попутно проставляя различные метки напротив названий файлов. Это немного облегчило работу над переводом текста, но незначительно, так как файл создавался уже ближе к концу перевода. Когда мы приступили к следующему проекту, мне очень сильно захотелось создать какую-то свою среду для работы с текстом, которая бы не просто помогала, а значительно ускоряла процесс перевода и редактирования. Да так, чтобы это было возможно даже в том случае, когда всю игру переводит не только один человек. Но чтобы всё это работало как часы, нужно заблаговременно выполнить ряд задач. Именно об этом и пойдёт речь в этой главе. Я покажу полный процесс обработки текстовых файлов, начиная с извлечения текстов и заканчивая формированием единой таблицы Excel для создания лок-кита. ⬜ Этап 1. Создание списка файлов и их копирование/перемещение с помощью приложения copyfiles а) Во время работы над переводом Tales of Symphonia у меня не было необходимости постоянно копировать и перемещать файлы по разным директориям и поддиректориям. Потому что практически все основные файлы всегда находились в каком-то одном месте. Но как только я принялся работать с файлами Tales of Graces f и Tales of Rebirth, то выяснилось, что там каждый файл мог находиться в своей директории или в поддиректории — это с самого начала доставляло головную боль. Повторив процесс копирования из одного места в другое несколько десятков раз, я понял, что теряю очень много времени на решение элементарных задач, которые каждый раз должны выполняться автоматически, чтобы вообще на них не отвлекаться. Сначала я подумал о приложении Total Commander и создании пакетного bat-файла, в котором хотел прописывать все действия, но меня всё равно не устраивал ручной процесс создания списков и адресов. Поэтому я в очередной раз спросил RangerRus, не может ли он сделать такую программу, которая по моей команде будет создавать списки с адресами и копировать все нужные файлы в одно место, а потом, с помощью другой команды, перемещать всё обратно в исходные директории. Разумеется, такую простую задачу он выполнил очень быстро и своей программе дал название "copyfiles". С тех пор я пользуюсь ей при работе практически со всеми нашими проектами. Она продолжает стабильно экономить много времени. Я даже стал воспринимать её как какой-то стандарт, и без создания списка обратного перемещения файлов больше не работаю. Ссылка для скачивания данного приложения приведена во второй главе. А теперь я немного опишу её, чтобы было понятно, насколько она удобна и как вообще ей пользоваться. В качестве примера возьмём все распакованные контейнеры SCPK из Tales of Rebirth. Для этого нужно воспользоваться приложением ToR toolkit, которое распаковывает все файлы формата SCPK в каждую отдельную одноимённую папку. После того, как мы получили 744 папки с нумерацией от 10197 до 11180, важно понять, что в каждой папке находится множество файлов разных форматов. Наша задача с помощью copyfiles выбрать какой-то один формат и задать условия, при выполнении которых приложение составит список путей к файлам, а также скопирует их все в одно место. Я выбираю файлы формата SCE, потому что именно в них находятся сюжетные диалоги и многие другие строки, которые нужно переводить. Перемещаем папку SCPK со всеми 744 директориями в корень той папки, где находится copyfiles, затем создаём пакетный bat-файл, в котором прописываем следующие условия: copyfiles_3.copyfiles_+1_format.bat copyfiles.exe copyfiles SCPK *.sce* pause Запускаем этот файл, и программа автоматически скопирует все файлы расширения SCE в папку copyset_out_dir, а также создаст файл copyset.ini, в котором сформирован список всех скопированных файлов, а также их исходный путь. Данные манипуляции можно применять абсолютно к любым типам файлов. ⬜ Этап 2. Склейка всех ТХТ-файлов в единый файл с помощью приложения TXTCompile а) Теперь с помощью ToR toolkit из всех файлов SCE можно извлечь текст. Программа извлекает текст в файлы ТХТ и присваивает им те же названия. Наша дальнейшая задача склеить все ТХТ-файлы в единый файл. Делается это для того, чтобы работать со всем текстом в одном месте, а не мучаться с каждым файлом по отдельности. В этом нам поможет приложение TXTCompile, которое тоже создал RangerRus по моему заказу. В сети можно найти аналоги этой программы, но использовать многие из них при определённых условиях оказалось неудобно. Поэтому я попросил Рейнджера сделать ещё одно приложение, которое удобным образом склеивало бы все файлы ТХТ в единый файл. Кроме того, в этом файле должны быть отдельные строки с метками и названиями файлов, которые были склеены. А уже после различных изменений в этом файле программа должна расклеивать единый ТХТ-файл на исходные отдельные составляющие с полным сохранением структуры данных по количеству строк и кодировке (процесс расклейки будет описан в одной из следующих глав). Перемещаем все файлы ТХТ в корень той папки, где находится TXTCompile, затем создаём пакетный bat-файл, в котором прописываем следующие условия: TXTCompile_v1.0_compile+name_txt.bat TXTCompile_v1.0.exe compile *.txt COMPILED.txt pause Запускаем этот файл, и программа автоматически склеит все файлы расширения ТХТ в единый файл COMPILED.txt. Созданный файл COMPILED.txt выглядит вот так: ⬜ Этап 3. Создание списка дубликатов строк и их отсеивание с помощью приложения TxSrt а) На этом этапе необходимо максимально обработать полученный файл COMPILED.txt так, чтобы конечный результат был наиболее удобным для переводчиков и редакторов. Огромную помощь в этом сослужит приложение TxSrt, которое тоже создал RangerRus по моему заказу. Потому что рано или поздно дубликаты строк будут доставлять такую огромную боль, что задумаешься о том, чтобы вообще навсегда избавиться от проблем с ними. К слову, сам Рейнджер продолжил использовать эту программу в своих будущих проектах. Итак, для начала нужно проанализировать файл COMPILED.txt. Для этого создаём пакетный bat-файл, в котором прописываем следующие условия: TxSrt_1-maketab.bat TxSrt.exe maketab COMPILED.txt pause Запускаем этот файл, и программа проанализирует весь COMPILED.txt на предмет дубликатов строк, а в качестве отчёта создаст файл COMPILED.COPYTAB.txt. Чтобы лучше всего показать эффективность этой программы, я пропущу через неё склейку всех файлов диалогов из игры Tales of Graces f. Ведь в этой игре у нас получается чуть более 1 300 000 строк. Столько не сможет принять даже Microsoft Excel, так что для проведения теста это подойдёт отлично. Если вам интересно всё содержимое COMPILED.txt из PS3-версии Tales of Graces f, то вы можете скачать архив с этим файлом по ссылке чуть ниже, а содержание COMPILED.COPYTAB.txt выглядит примерно вот так: Скачать #1 https://temple-tales.ru/games/tor/data_design/files/tales_of_graces_f_ps3_scenario_compiled.zip Скачать #2 (зеркало) https://disk.yandex.ru/d/Zw7IO7Z2MIuJNQ То есть в COMPILED.COPYTAB.txt мы видим просто список всех строк, которые имеют хотя бы 1 дубликат. Соответственно, в этот список не попадают строки, у которых дубликатов нет. Кроме того, список формируется по порядку чтения файла с первой строки до последней. Теперь закрадывается вопрос: а что делать с полученным файлом-отчётом? Его можно спокойно редактировать и удалять все ненужные строки. Важно понимать то, что если вы удалили какую-то строку, то в будущем это очень сильно повлияет на конечный файл. Так как те самые удалённые строки после сортировки дубликатов будут присутствовать по всему документу. В этом и заключается главная задача — оставить в файле те строки, от которых нам нужно избавиться, чтобы не видеть их дубликаты во время работы с текстом. Для первого теста я ничего удалять в файле COMPILED.COPYTAB.txt не буду, а уже на следующем шаге покажу, что у нас получится в обработанном файле. б) Чтобы получить новый отсортированный файл с учётом файла-отчёта, создаём пакетный bat-файл, в котором прописываем следующие условия: TxSrt_2-unsort.bat TxSrt.exe unsort COMPILED.txt pause Запускаем этот файл. Программа выполнит свою работу и создаст рядом ещё один файл, но уже отсортированный — COMPILED.UNSORTED.txt. У нас получился файл примерно с ХХХ строками. Большая разница, не правда ли? Было 1 308 304 строк, а теперь стало 24 696. Если более 1 миллиона строк приводит в ужас, то с несколькими десятками тысяч уже можно спокойно работать. Я попытаюсь показать разницу между двумя файлами на приведённом изображении ниже: В этом отсортированном файле можно спокойно всё переводить так, как вам хочется. в) Давайте попробуем немного изменить COMPILED.COPYTAB.txt и удалить теги с именами персонажей. Ведь это очень важная часть, которая позволяет понять, к какому персонажу относится та или иная строка. Я удалил эти строки: <04>($Gf) <04>($Kf) <04>($Hf) <04>($Ff) После этого запускаем новую сортировку с помощью bat-файла TxSrt_2-unsort.bat. После обработки открываем полученный файл COMPILED.UNSORTED.txt и наблюдаем в нём следующие изменения: Теперь все строки с тегами имён персонажей остались на своих местах, а все остальные дубликаты строк программа отсеяла. ⬜ Этап 4. Формирование таблицы Excel для работы над переводом и редактированием текста а) На этом этапе нам нужно удобно уложить отсортированный файл COMPILED.UNSORTED.txt в таблицу Excel. Но сделать это необходимо особым образом, чтобы в процессе работы с текстом можно было крутить любой столбик как угодно, устраивать дополнительную сортировку строк под любые нужды, а также писать столько заметок, сколько захочется. Ведь в этом и заключается главное преимущество таблиц, в отличие от простых ТХТ. Гибкая среда в Excel позволяет настроить всё это практически без ограничений. Степень того, насколько можно сделать рабочий процесс удобнее и легче — зависит только от вас. Более подробно об этом я расскажу в следующей главе, а сейчас просто покажу, как я копирую содержимое файлов ТХТ в таблицу Excel и какие базовые настойки в создаваемой таблице нужно сделать в первую очередь. Для начала сразу стоит запомнить то, что Excel может скопировать не все знаки из буфера обмена. Например, если в начале каких-то строк стоят кавычки, то при вставке Excel обязательно их удалит. Чтобы этого избежать, сначала при помощи автозамены нужно заменить все кавычки на какой-то отдельный уникальный набор символов, а после вставки — снова при помощи автозамены — вернуть кавычки. Таким образом кавычки у вас останутся на месте. Есть и другие особенности, но всё это познаётся на практике. На приведённом ниже изображении я показываю, как это выглядит: Скачать #1 https://temple-tales.ru/games/tor/data_design/files/tales_of_graces_f_ps3_scenario_compiled.xlsx Скачать #2 (зеркало) https://disk.yandex.ru/d/HNFs3gAYD3xVXQ

История русской локализации Tales of Rebirth (PS2) Глава 7. Очистка строк от лишних данных и работа с нестандартными поинтерами 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://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 делает оптимизацию текста и экономит место во время укладки в заданный диапазон. Для полного понимания плюсов этого алгоритма на нём стоит остановиться подробнее. Дело в том, что разработчики множества игр используют как раз-таки этот метод. Его суть заключается в том, что если в процессе перевода имеется две и более строки с одинаковым текстом, то есть дубликаты, то программа укладывает только одну строку, а все поинтеры содержат адрес к этой самой строке. В результате у нас не записываются остальные дублирующие строки, а значит, происходит экономия места. Если попытаться изобразить это в хекс-редакторе, то выглядеть это будет примерно так:

История русской локализации Tales of Rebirth (PS2) Глава 5. Разбор дополнительных файлов и начало работы с оверлеями 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://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. Также найденный текст можно попробовать изменить и посмотреть, как отобразятся изменения в реальном времени во время игрового процесса. Это очень удобно для проверки различных значений кодировки текста. А ещё данным методом можно искать в оперативной памяти не только текст, но и любые другие данные, если вы понимаете, как это нужно делать.

Спасибо большое за отзыв. Все мнения важны как ни крути) Заниматься собрались тем, что нам интересно. А именно Reborn + PS1 + PSP. Но уже в процессе стало понятно, что кроме Reborn мы скорее всего не вытянем PSP, а PS1 под вопросом. Поэтому на текущий момент только про Reborn речь, а всё остальное если получится, то получится. По поводу SS <> PS1. Не сказал бы уж, что SS-версия прям катастрофически лучше. Для меня по крайней мере они не сильно существенны, но чего не скажешь о PSP и Reborn. Там уже значительный вклад от разработчиков.

Спасибо большое за отклик! Напиши мне в ВК: https://vk.com/evil_finalist Обсудим.

История русской локализации Tales of Rebirth (PS2) Глава 3. Начальный этап исследования игровых ресурсов 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://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 — ему посвящена отдельная запись (https://vk.com/wall-181931421_2526). Рейнджер справился с главными архивами и базовыми форматами, а потом ушёл со сцены фанатских переводов. В процессе работы с готовым материалом я обнаружил, что при первичном анализе файлов было пропущено много текстов и текстур. На самом деле ресурсы Tales of Rebirth таят в себе гораздо больше сюрпризов и ограничений, чем могло показаться на первый взгляд. Необходимо было найти всё остальное, но на тот момент я понятия не имел, как к этому подступиться. Именно поэтому мне пришлось искать других умельцев, которые могли бы решить разные задачи или помочь в ромхакинге добрым советом. Обо всех этих людях я непременно расскажу в будущих записях. Очень часто поиски и просьбы о помощи заходили в тупик, и ряд задач приходилось решать самому. Со временем анализ структуры файлов привёл к пониманию того, что даже без знания языков программирования можно вполне справляться своими силами — не обязательно всегда просить о помощи там, где оступился. Тем не менее, методом проб и ошибок можно очень долго блуждать и ни к чему не прийти. Именно поэтому я хочу рассказать свою историю погружения в ромхакинг и сцену фанатских переводов на примере проекта Tales of Rebirth. Начну с самого начала, когда я ещё был совсем зелёным, и дойду до текущего момента, когда могу решить достаточно большое количество задач в наших проектах, до сих пор не зная при этом ни одного языка программирования. И так может абсолютно каждый, потому что люди придумали очень много вспомогательных материалов и программ. А если что-то не получалось найти или хотя бы подобрать близкие аналоги, то я заказывал у разных ромхакеров уникальные программы, которые задумывались так, чтобы облегчать процесс работы над переводами практически для любого желающего. Разумеется, я планирую показать всё это наглядно, со скриншотами, а также загрузить все описанные программы, чтобы любой, кто захочет, мог ими воспользоваться. Надеюсь, для кого-то эти будущие записи станут полезными, а кто-то, может быть, и вовсе посмеётся от души ввиду дилетантского подхода в начале пути, так как многие проблемы можно было действительно решить ещё тогда. Но не стоит забывать, что если не знаешь где искать, то многие задачи воспринимаются настолько неподъёмными, что кажется, будто ищешь иголку в стоге сена. Искренне извиняюсь, если мой стиль письма в техническом плане местами будет непонятным, но по-другому многие стороны этой локализации никак не объяснить.

Ориентировочная дата выпуска полной русской локализации 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) Технический план: (2) Текстовый план (диалоги): 100% Разбор ресурсов 100% Сюжет 095% Текстуры 100% НИПы 100% Видеоролики 100% Надписи 100% Вставка контента 100% Сценки 090% Редактура 100% Квесты 090% Тестирование 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% Саундтрек (трек-лист)

Немного о будущих переводах игр серии Star Ocean На данный момент в свободном доступе можно найти переводы трёх игр серии Звёздного океана: Star Ocean 1 (SNES), Star Ocean 4 (PC) и наш последний релиз Star Ocean 6 (PC). Также нам есть что показать из текущих проектов и будущих начинаний, но всему своё время — весь 2026 год мы будем заняты работой над завершением и выпуском локализаций Tales of Rebirth и Valkyrie Profile Lenneth. Тем не менее хотим дать надежду тем, кто ждёт любую информацию о переводе остальных игр серии Star Ocean. Сейчас у нас идёт активная работа над Star Ocean 2 (PSP и R), а ещё запущен процесс над Star Ocean: First Departure (PSP) и Star Ocean: Integrity and Faithlessness (PS3 и PS4). Более подробно обо всём этом расскажем в 2027 году. Стоит ожидать выпуск демок и видеодемонстраций по каждому проекту. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Идёт сбор средств на оплату услуг программистов и переводчика японского Star Ocean 2: The Second Story R + Star Ocean 2: Second Evolution: Собрано: 137 432,66 / 350 000 Карта Сбербанка: 5469 9802 0654 4716 ЮMoney/Яндекс кошелёк: 410011235819402 последнее обновление от 06.03.2026 Список донатеров: https://temple-tales.ru/donations_so2.txt

Star Ocean 6: The Divine Force Звёздный океан 6: Божественное провидение スターオーシャン6 THE DIVINE FORCE ДАТА ВЫХОДА: 27 октября 2022 ЖАНР: jRPG ИГРОВЫЕ ПЛАТФОРМЫ: Personal Computer ИЗДАТЕЛЬ: Square Enix ЯЗЫК ПЕРЕВОДА: Русский РАЗРАБОТЧИК: tri-Ace ЯЗЫК ОЗВУЧКИ: Английский, Японский БОЕВАЯ СИСТЕМА: Real-Time Battle System (1) Технический план: (2) Текстовый план: (3) Создание русского кавера на опенинг: 100% Разбор ресурсов 100% Сюжет 100% Перевод и адаптирование лирики 100% Текстуры 100% НИПы 100% Создание инструментальной версии 100% Вставка контента 100% Надписи 100% Запись вокала 100% Редактура 100% Экстра-сценки 100% Правки 100% Тестирование 100% Квесты 100% Сведение 100% Журнал 100% Монтирование видео 100% Меню и интерфейс 100% Вставка в игру 100% Глоссарий УЧАСТНИКИ ПЕРЕВОДА: Evil Finalist (Вадим Стрежов): руководство проекта, разбор ресурсов, редактура (сюжет, экстра-сценки, квесты, НИПы и меню), работа с текстурами, вставка контента Kagiri-To (Павел Хезин): перевод (сюжет, экстра-сценки, квесты, НИПы и меню) JackKaif (Антон Землянский): редактура (экстра-сценки) Polka (Динара Овчинникова): работа с текстурами, русский логотип RikuKH3: хакинг, разбор ресурсов УЧАСТНИКИ ТЕСТИРОВАНИЯ v1.00: Evil Finalist (Вадим Стрежов): тестирование на PC и платформе Steam Deck OLED (ядро GE-Proton8-32) Coronel Karol (Каролина Лебедева): тестирование на PC Litrics (aka Syrin) (Анастасия Степанова): тестирование на PC Kayner (aka Kronen10) (Кирилл Опарин): тестирование на PC ZeroCold1981 (Юрий Усков): тестирование на PC Начало проекта: 06.12.2022 Завершение перевода текстов: 31.05.2025 Редактура: 01.06.2025 — 29.12.2025 Тестирование: 01.01.2025 — 29.12.2025 Дата релиза: 30.12.2025 ССЫЛКИ НА РУСИФИКАТОРЫ: Полный перевод v1.00 для платформы PC (Steam): Локализация с текстурами геймпада Xbox: https://www.zoneofgames.ru/games/star_oceanthe_divine_force/files/11145.html Локализация с текстурами геймпада PlayStation 4: https://www.zoneofgames.ru/games/star_oceanthe_divine_force/files/11146.html Локализация с текстурами геймпада PlayStation 5: https://www.zoneofgames.ru/games/star_oceanthe_divine_force/files/11147.html Файлы для замены вступительного опенинга на русский кавер: https://www.zoneofgames.ru/games/star_oceanthe_divine_force/files/11148.html Страница перевода на сайте: http://temple-tales.ru/translations_so6_pc.html Группа в ВК: https://vk.com/temple_of_tales_translations Канал Ютуба: https://www.youtube.com/channel/UCJfDLKD1ClnKgLBdf7eblNA Публичный сервер в ДИСКОРДЕ: https://discord.gg/hwrDj8Yxsh Звёздный океан: Божественное провидение - проект на данный момент на ранней стадии работы. Лишь только недавно уважаемый прогер RikuKH3 почти полностью закончил разбор ресурсов игры. За хакинг и труд художницы открываются отдельные сборы. По той причине, что бесплатно игру ни кто хакать не будет. Перевод осуществляется с английского языка, но со сверкой с японскими терминами. В текущем отрезке видеодемонстрации представлены оба пролога за Рэймонда и Летисию + немного боевой системы. ОБРАТИТЕ ВНИМАНИЕ! На текущей стадии перевода русификация совместима как с пираткой, так и с лицензионной Steam версией. Все ачивки полностью поддерживаются. Кряк для данной игры был создан и из игры убрали Denuvo. Работоспособность проверена. Для подписчиков в VK Donut и Boosty текущая сборка всегда доступна. Поддержать нас, а также получить доступ к различным материалам в нашем творчестве и другим бонусам можно через подписки: VK Donut: https://vk.com/donut/temple_of_tales_translations VK Donut: https://vk.com/donut/temple_of_tales_quiz VK Donut: https://vk.com/donut/temple_of_tales_music Boosty: https://boosty.to/temple-tales Альтернативный способ поддержки: Карта Сбербанка: 5469 9802 0654 4716 Карта ВТБ: 4272 2908 4659 124 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Сбор средств на оплату программиста и художника Star Ocean 6: The Divine Force завершён. Начало: 13 декабря 2022 | Конец: 27 октября 2023 | Общее время: ~10 месяцев Собрано: 81 578,14 / 80 000 последнее обновление от 27.10.2023 Карта ВТБ: 4272 2908 4659 1246 ЮMoney/Яндекс кошелёк: 410011235819402 Список донатеров: https://temple-tales.ru/donations_so6_pc.txt -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Мы обязаны напомнить о прогрессе перевода Дела валькирии, так как следующие записи будут посвящены в основном предстоящему выпуску Сказаний Перерождения. Переводчик Валькирии ещё в прошлом году закончил перевод всех диалогов, а также сделал их вычитку (об этом мы упоминали в этой записи: https://vk.com/wall-181931421_3895). Ему осталось перевести совсем немного, в основном различные описания предметов и навыков. Но, помимо текстовой составляющей, в Valkyrie Profle нам ещё есть чем заняться — это работа с видеороликами, текстурами, рамками диалогов и вставка текста в них, отдельная обработка заключительных титров и т.д. Доработкой всего этого мы приступим после релиза нашей локализации Tales of Rebirth. Также напоминаем: если вы желаете поиграть в текущую версию перевода, то доступ открыт тем, кто вкладывался в проект, а также всем подписчикам в VK Donut и Boosty. Текущая информация о переводе всех пунктов игры: (1) Технический план: 100% Разбор ресурсов 035% Текстуры 025% Видеоролики 040% Вставка контента 080% Редактура 033% Тестирование (2) Текстовый план: 100% Сюжет 100% НИПы 100% Квесты 100% Глоссарий 075% Меню и интерфейс 090% Работа над размерами рамок всех диалогов 050% Работа с файлами титров --------------------------------------------------------------------------------------------------------------- Идёт сбор средств на оплату услуг программиста и переводчика Valkyrie Profile: Lenneth Собрано: 137 500 / 200 000 последнее обновление от 01.02.2026 Карта ВТБ: 4272 2908 4659 1246 ЮMoney/Яндекс кошелёк: 410011235819402 Список донатеров: http://temple-tales.ru/donations_vp1_psp.txt

Valkyrie Profile: Lenneth Дело валькирии: Леннет ヴァルキリープロファイル −レナス− ДАТА ВЫХОДА: 22 декабря 1999 (PS1), 2 марта 2006 (PSP) ЖАНР: jRPG ИГРОВЫЕ ПЛАТФОРМЫ: PlayStation Portable ИЗДАТЕЛЬ: Square Enix ЯЗЫК ПЕРЕВОДА: Русский РАЗРАБОТЧИК: tri-Ace ЯЗЫК ОЗВУЧКИ: Английский, Японский БОЕВАЯ СИСТЕМА: Turn-Based Battle System (1) Технический план: (2) Текстовый план: 100% Разбор ресурсов 100% Сюжет 035% Текстуры 100% НИПы 025% Видеоролики 100% Квесты 040% Вставка контента 100% Глоссарий 080% Редактирование 075% Меню и интерфейс 033% Тестирование 090% Работа с размерами рамок для всех диалогов 050% Работа с файлами титров УЧАСТНИКИ ПЕРЕВОДА: Evil Finalist (Вадим Стрежов): руководство проекта, вставка контента, работа с текстурами Dangaard (Владимир Лымарев): переводчик (сюжет, квесты, НИПы, меню, и многое другое), редактирование Polka (Динара Овчинникова): логотип, подбор шрифтов Riku_KH3: хакинг, разбор ресурсов ТАКЖЕ СВОЙ ВКЛАД В РАЗВИТИЕ ПРОЕКТА ВНЕСЛИ: Moonbear (Александр Уткин): помощь с рамками диалогов yurrrbannn (Юрик Машкин): помощь с идентификацией титров Начало проекта: 11.05.2023 Демо перевод v0.33: 23.06.2024 Завершение проекта: ??? Дата релиза: ??? ССЫЛКИ НА РУСИФИКАТОРЫ: Демоперевод v0.33 (Английская озвучка): https://www.zoneofgames.ru/games/valkyrie_profile/files/9161.html Демоперевод v0.33 (Японская озвучка): https://www.zoneofgames.ru/games/valkyrie_profile/files/9160.html Полный перевод v1.00: Ожидается в 2026-2027 годах Страница перевода на сайте: http://temple-tales.ru/translations_vp1_psp.html Группа в ВК: https://vk.com/temple_of_tales_translations Канал Ютуба: https://www.youtube.com/channel/UCJfDLKD1ClnKgLBdf7eblNA Публичный сервер в ДИСКОРДЕ: https://discord.gg/hwrDj8Yxsh На данный момент проект находится на ранней стадии. А начали работать над ним мы ещё весной 2023 года. На самом деле, прошло гораздо больше времени. Поиски программиста для работы над первой частью игры продолжались с 2017 года. Те, кто пробовали разбираться в ресурсах игр от разработчиков tri-Ace, знают, что там чёрт ногу сломит. Наверное именно поэтому за все эти два с лишним десятка лет так никто и не сдвинулся с мёртвой точки. Это одна из причин, почему в эпоху PS1 эту часть игры и её сиквел на PS2 пираты обошли стороной. Наше почтение Riku_KH3, трудящемуся над этой игрой! Нам повезло, что, спустя столько лет, именно Рику согласился помочь - и не только с разбором самой игры, но и с написанием автоматического выравнивания рамок под стать переведённому тексту. С этим тоже были определённые сложности, так как в игре на каждое окно диалогов прописаны данные: координаты, ширина и высота рамки. Править всё это вручную было бы нереально. Самое страшное позади. Кроме того, мы очень рады тому, что работать над игрой согласился известный и уважаемый человек в переводческой деятельности - Владимир Лымарев (Dangaard). Кто-то уже знает о его достижениях, а мы просто расскажем тем, кто слышит о нём впервые. Владимир переводил многие игры в сериях Final Fantasy и Silent Hill, а также коснулся и Metroid'ов. Он также участвовал в неофициальных переводах книг "Песни льда и огня" (7kingdoms.ru) и, помимо этого, написал целую кучу материала по японским рпг для сайта Final Fantasy Forever (ffforever.info): прохождения, новеллизации, штампы японских ролевых игр, аналитику и многое другое. И это далеко не всё. Безгранично рады потрудиться вместе над шедевральным проектом - VALKYRIE PROFILE. Если данный проект найдёт определённый отклик у аудитории, то тогда мы постараемся продолжить дело и с сиквелом Valkyrie Profile 2: Silmeria. Но об этом пока рано говорить, так как сначала нужно полностью осилить историю Леннет. Прилагаем часовую видеодемонстрацию сюжета от пролога и до конца нулевой главы. На выбор представлено два видеоролика: с японской и английской озвучкой. Да, как и многие наши прошлые проекты, в этом мы тоже стараемся реализовать перевод для обоих вариантов озвучки. В довершение всего, стоит отметить ещё один не менее важный момент. К сожалению, не все проекты удаётся осилить и осуществить должным образом в виду малой заинтересованности аудитории или отсутствия интереса переводчиков. Все проекты мы распространяем бесплатно и денег за них не требуем. Мы не занимаемся продажей. Наше творчество — от фанатов для фанатов! Но есть несколько проектов, которые удастся выполнить только лишь благодаря сборам на оплату услуг переводчиков и программистов. Дело валькирии — один из них. Полный релиз Valkyrie Profile только в ваших руках! Если вы желаете отблагодарить нашу команду за труды, то мы будем вам очень признательны. Поверьте, этот проект очень сильно нуждается в финансовой помощи, так как стоимость его реализации высокая. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Идёт сбор средств на оплату услуг программиста и переводчика Valkyrie Profile: Lenneth Собрано: 154 000 / 200 000 последнее обновление от 08.04.2026 Карта ВТБ: 4272 2908 4659 1246 ЮMoney/Яндекс кошелёк: 410011235819402 Список донатеров: http://temple-tales.ru/donations_vp1_psp.txt Перевод планируется выпускать: БЕСПЛАТНО -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Есть большие подозрения на то, что это отредактированный машинный перевод. Тем не менее, если это не так, то официальная локализация всё равно выглядит как обычный подстрочник. Переведено с английского, а ещё без учёта японского глоссария. Это значит, что профуканы все отсылки к Монгольской империи, Славянской мифологии, России, Казахстану, Афганистану, Таджикистану, Пакистану, Узбекистану, Киргизии, Китаю и т.д. Удивительно, но получилось всё так, что русофобская локализация (английская) была переведена на русский язык на официальном уровне и собрала все эти изменения. Я не знаю как это назвать, кроме как проявлением русофобии. Это точно не выглядит так, как будто переводчики не разобрались. Многие названия легко можно найти через поиск. Поэтому я уверен, что изменения были целенаправленными. Если интересно как будет выглядеть шрифт в нашем порте перевода на PC, то мы использовали оригинальный шрифт с PS3-версии:

Портирование нашего перевода Tales of Xillia PS3-версии на PC (Remastered) https://temple-tales.ru/translations_tox1-remastered.html Рады сообщить, что у нас закончилась подготовка к портированию нашего перевода PS3-версии, и теперь ведутся активные работы. Кроме того, в очередной раз напоминаем (об этом ранее говорили в этой записи: https://vk.ru/wall-181931421_4200): мы не ограничиваемся только переносом текста и кавера опенинга, а также обработкой текстур. Так как у нас в процессе перевод Tales of Xillia 2 с японского, мы перепроверяем весь текст Tales of Xillia, согласовывая глоссарий двух частей. Это необходимо для того, чтобы в обоих переводах были общие термины, названия и имена. Помимо этого, после портирования текста нам придётся заново протестировать эту игру. А ещё мы снова вычитываем весь текст и стараемся убирать вольности перевода, которые были допущены. Поэтому мы также обновим перевод и для PS3-версии. А поскольку сейчас все наши основные силы сосредоточены на том, чтобы довести до конца Tales of Rebirth (PS2), ожидать готовности портирования перевода Эксиллии на PC стоит только после выпуска Сказаний Перерождения. ⬜ Текущая информация о процессе портирования: 100% Разбор ресурсов PC-версии 025% Портирование текста 035% Текстуры 000% Видеоролики 050% Вставка контента 000% Редактура 000% Тестирование PC-версии 000% Тестирование PS3-версии

Да, действительно странно. А какая OS стоит? У меня всё нормально подхватывалось на Win10 и Win11. В прошлом, до Win10, были проблемы в разных играх. Решалось это вот этой программой XOutput. Это эмулятор контроллера Xbox360. Можно делать подмену архитектуры между DirectInput и Xinput.

Какой у тебя геймпад? У меня от Xbox One нормально всё подхватывает. Без всяких танцев с бубнами.

О снаряжении Star Ocean 6: The Divine Force https://temple-tales.ru/articles/about_equipment_star_ocean_6_the_divine_force.html Представляем вашему вниманию подробный анализ перевода различного оружия и брони из нашей локализации Звёздного океана 6 от Лебедевой Каролины (Coronel Karol). Создавая снаряжение, разработчики тщательно подошли к тому, чтобы оно как можно лучше вписывалось в атмосферу игры. Поэтому у нас есть и средневековое оружие, названия которого упоминается в различных европейских и азиатских легендах, мифическая броня, известная многим по древнему эпосу разных стран мира, а также предметы с более редкими названиями, ассоциирующимися с космосом. В этом глоссарии перечислены далеко не все отсылки, упоминаемые в игре. Большая часть источников, откуда была взята соответствующая информация, была опубликована на английском, немецком, французском, ирландском, итальянском, хинди, норвежском, польском и японском языках в различных электронных книгах и печатных изданиях. Призываем прочитать данную статью, ведь вы откроете для себя много нового — мы гарантируем! С текстом материала можно ознакомиться на нашем сайте, пройдя по ссылке в самом начале записи.

Как вам наш перевод Звёздного океана 6? Прошёл почти месяц после выпуска нашей локализации SO6. За это время общее количество скачиваний русификатора и готовых сборок по всем ссылкам с нашего сайта и Zone of Games составило около 850 раз (данные от 5 февраля 2026 года). Кто уже успел пройти игру полностью или находится в процессе прохождения? Если не затруднит, то просим оставить свой отзыв о переводе в отдельном обсуждении нашего сообщества: https://vk.com/topic-181931421_54576924 В очередной раз выражаем огромную благодарность всем, кто поддержал наш проект материально во время сборов средств. Также отдельное почтение тем, кто оказал поддержку после выпуска Звёздного океана 6. Эти средства мы распределили на сборы по текущим проектам. Все донаты можно отследить по следующим ссылкам: https://temple-tales.ru/donations_tox2.txt https://temple-tales.ru/donations_so2.txt https://temple-tales.ru/donations_vp1_psp.txt На новогодних каникулах мы немного отдохнули, а теперь снова в бой! Продолжаем трудиться над следующими релизами. Сейчас идёт завершение редактирования Tales of Rebirth (PS2) и подготовка к финальному тестированию. Ещё мы приступили к доработке нашего перевода Tales of Xillia (PS3) и его портированию на PC. Нужно очень многое пересмотреть и правильно синхронизировать имена и термины с нашим проектом Tales of Xillia 2. Кроме того, необходимо устранить различные вольности в тексте, которые всё ещё там остались. Не так давно уважаемая Юлия Андреева (https://vk.com/id40713751) прошла игру с нашим переводом и прислала около 400 замечаний, что будет очень кстати. Следите за новостями и оставайтесь с нами. Дальше будет только интереснее ; )

Спасибо за такой тёплый отзыв) Не затруднит продублировать его здесь в нашем сообществе? https://vk.com/topic-181931421_54576924 Без понятия в чём дело. Да, полный.

Спасибо огромное! И тебя тоже с наступившим Новым годом! Будем стараться. Как минимум, ещё 1 локализацию мы точно выпустим в 2026 году, а может быть и даже 2. Там уже как справимся. Если возникнут какие-то трудности с прохождением Star Ocean 6: The Divine Force, то советую обратить к этому ультимативному прохождению: https://gamefaqs.gamespot.com/ps5/335271-star-ocean-the-divine-force/faqs/80587 В этих трудах, от уважаемого AzMuch, можно найти практически любые ответы по игре. Если не затруднит, то прошу потом оставить отзыв о локализации SO6 в этом обсуждении нашего сообщества: https://vk.com/topic-181931421_54576924