-
Похожие публикации
-
Автор: 0wn3df1x
Lost & Found: A This Bed We Made Story
Метки: Приключение, Интерактивная литература, Решения с последствиями, Выбери себе приключение, 3D Разработчик: Lowbirth Games Издатель: Lowbirth Games Серия: This Bed We Made Дата выхода: 05.08.2026 Отзывы Steam: 125 отзывов, 93% положительных -
Автор: 0wn3df1x
Inkwellers
Метки: Приключение, Инди, Головоломка, Кооператив, Совместная кампания Разработчик: ScrumptiousSprouts sp. z o.o. Издатель: ScrumptiousSprouts sp. z o.o. Дата выхода: 28.05.2026 Отзывы Steam: 102 отзывов, 89% положительных
-
-
Продвигаемые темы
-
-
Последние сообщения
-
Автор: HELS891 · Опубликовано:
Русификатор Yukan Madam Club 有閑夫人倶楽部 Дата выхода 27 марта 2026(только в Японии) Сайт игры:https://www.empress-game.com/yukanmadam/ Жанр: Визуальная новелла Разработчик: Empress Издатель: Empress Платформы: Windows Описание: Главный герой только что перевёлся в новую школу и ещё не обзавёлся близкими друзьями. Но однажды он знакомится с Крисом — красивым светловолосым юношей из своего класса; они быстро находят общий язык и становятся близки. Когда Крис приглашает его к себе домой, герой обнаруживает, что тот живёт в невероятно роскошном особняке с бассейном во дворе, а комната Криса выглядит куда богаче, чем его собственная. Однажды, когда Крис выходит из комнаты, герой случайно находит на его компьютере файл и заглядывает в него — там оказывается огромное количество фото и видео, на которых Крис занимается сексом с женщиной, очень похожей на его мать... Крис открывает ему правду об их запретных отношениях между родителем и ребёнком и даже предлагает герою самому переспать с матерью, если тот этого пожелает. Не в силах противостоять соблазну и собственным желаниям, герой в итоге поддаётся и вступает в связь с мамой Криса... Это становится началом: вскоре он начинает заводить отношения с матерями других одноклассников и даже познаёт запретную любовь со своей собственной матерью... Куда же в итоге приведёт эта запретная родительская любовь?
Сделал нейросетевой перевод:
Rio1.arc - Google Диск - Файл с русским переводом. (Просто добавить в папку игры с заменой и всё) translation_complete3_ready.tsv - Google Диск — Таблица, в которой работал. (для тех кто хочет сам поработать над переводом) -
Автор: Alex Po Quest · Опубликовано:
У меня Опера. Там нема. Но стоит расширение. Нужно было выделить текст. Но почему-то не выделялся. Б-я-да, короче. -
Автор: bruce7 · Опубликовано:
Архитектура инструмента для распаковки и обратной упаковки ресурсов PS3-игры Ниже — безопасный подход к разработке утилиты для фанатского перевода, редактирования шрифтов, текстурных атласов, строк и субтитров в The Ratchet & Clank Trilogy (HD Collection) либо похожей PS3/Vita-игре. Подход рассчитан только на легальный моддинг: собственные носители, личные дампы, homebrew-среду и уже доступные для редактирования ресурсы. Он не включает обход DRM, подписи исполняемых модулей, ключи, защищённые EBOOT/SPRX или другие системные механизмы защиты. 1. Общий анализ задачи Какие структуры обычно встречаются в ресурсах PS3-игр Игровые данные редко состоят из независимых файлов «как на ПК». Обычно применяются контейнеры одного или нескольких уровней: Тип структуры Назначение Обычный архив Последовательность файлов с таблицей содержимого (TOC). bigfile / packfile Большой бинарный файл с ресурсами, доступными по offset и size. PSARC Контейнер Sony, часто содержащий сжатые файлы и таблицу записей. Внутренний контейнер Формат движка: строки, текстуры, модели, шрифты, субтитры в собственных бинарных блоках. Таблица смещений Список адресов начала ресурсов или секций. Таблица размеров Список размеров исходных или сжатых данных. Таблица имён / хешей Имена файлов либо хеши путей, если имена не хранятся открыто. Индексный бинарник Отдельный файл, сопоставляющий языки, архивы, шрифты, видео и ресурсы. Условная структура архива может выглядеть так: +-------------------------------+ | Header | | magic: "PACK" / "PSAR" / ... | | version | | file_count | | toc_offset | | data_offset | +-------------------------------+ | TOC / File entries | | entry[0]: offset, size, hash | | entry[1]: offset, size, hash | | ... | +-------------------------------+ | Name table / string table | +-------------------------------+ | Resource data | | file 0 | | padding | | file 1 | | padding | | ... | +-------------------------------+ Почему архив может перестать загружаться после перепаковки Даже если содержимое ресурса изменено корректно, движок может отклонить архив, если нарушена его структура: смещение файла в TOC указывает на старый адрес; поле размера не соответствует фактическому числу байтов; нарушено выравнивание данных; не обновлена CRC32 или другой хеш; изменился порядок записей; файл должен быть сжат, но записан несжатым; таблица имён, хешей или индексов не соответствует содержимому; сдвинулись внутренние указатели внутри самого ресурса; изменена endian-последовательность чисел; изменился формат текстуры, но метаданные остались прежними. Что обычно называют «проверкой веса» Фраза «проверка веса файла» технически неоднозначна. В игровых форматах это может означать: Возможное значение Что это на практике Размер файла Поле size в заголовке, TOC или внешнем индексе. Сжатый размер compressed_size, если ресурс хранится сжатым. Исходный размер uncompressed_size, нужный для выделения буфера и распаковки. Размер контейнера Поле archive_size или ожидаемый конец файла. Размер записи Размер блока в TOC, включая служебные поля. CRC Контрольная сумма, часто CRC32. Хеш MD5, SHA-1 или пользовательский алгоритм для проверки данных/пути. Выравнивание Размер округляется до 0x10, 0x80, 0x800, 0x1000 и т. п. Padding Заполняющие байты между ресурсами, часто 00, FF или специальный шаблон. Правильная цель инструмента — не отключать проверку, а определить формат и корректно пересчитывать зависимые поля. 2. Юридическая и этическая рамка Инструмент следует проектировать для работы только с: собственными легально полученными данными; личными дампами; тестовыми или homebrew-ресурсами; открытыми, распакованными, незащищёнными контейнерами; модами, распространяемыми без оригинальных игровых ассетов. Не следует: извлекать и распространять чужие коммерческие игровые ресурсы; публиковать игровые архивы, текстуры, видео и бинарники целиком; заниматься обходом DRM, подписей, шифрования, лицензионных проверок; модифицировать защищённые системные модули ради снятия ограничений. Если требуемая часть логики находится в защищённом EBOOT/SPRX либо зависит от криптографически защищённого контейнера, безопасная граница работы — анализ уже распакованных открытых ресурсов, использование существующих легальных средств извлечения и создание патчей/манифестов, а не распространение оригинального содержимого. 3. CLI-проектирование инструмента Утилита должна быть предсказуемой, воспроизводимой и по умолчанию не портить исходники. Пример имени: rctool. rctool list archive.bin rctool inspect archive.bin rctool extract archive.bin —out ./extracted rctool pack ./extracted —out ./archive_packed.bin rctool verify original.bin modified.bin rctool diff-toc original.bin modified.bin rctool font-report ./game_resources —dump-glyphs rctool atlas-verify font_atlas.dds font_metrics.bin rctool subtitle-report subtitles.bin rctool psarc list data.psarc rctool psarc extract data.psarc —out ./psarc_extracted rctool psarc pack ./psarc_extracted —out ./data_mod.psarc Полезные параметры —format auto|psarc|bigfile|custom —endian auto|big|little —alignment 0x800 —dry-run —strict —verbose —json-report report.json —manifest manifest.json —keep-order —verify-checksums —no-compress Принципы CLI Исходный файл никогда не перезаписывается по умолчанию. Любая распаковка создаёт манифест. Упаковка работает только на основе манифеста. —dry-run показывает будущие offsets, размеры и расхождения без записи файла. verify проверяет структуру независимо от запуска игры. Все неизвестные поля и подозрительные записи логируются. 4. Структура парсера ресурсов Парсер не должен быть «набором жёстких смещений». Лучше разделить чтение формата на явные слои. Базовые поля, которые нужно искать Поле Типичный размер Назначение Magic / signature 4—16 байт Идентификатор формата: например, PSAR. Version 2 или 4 байта Версия контейнера. Endianness Не всегда явно Обычно определяется по magic/version/count. Header size 4 байта Размер заголовка. File count 4 байта Число записей в TOC. TOC offset 4/8 байт Адрес таблицы файлов. Name table offset 4/8 байт Адрес строковых имён, если есть. Data offset 4/8 байт Начало области ресурсов. Entry offset 4/8 байт Смещение конкретного файла. Packed size 4/8 байт Размер хранимых данных. Unpacked size 4/8 байт Размер после распаковки. CRC/hash 4—32 байта Целостность данных или идентификатор пути. Flags 4 байта Сжатие, тип данных, язык, платформа и т. п. Alignment 4 байта или константа Требуемое выравнивание блока. Endianness PS3 часто использует big-endian, но это не означает, что каждый ресурс обязательно big-endian. В одном проекте могут сосуществовать: big-endian заголовки движка; little-endian DDS-текстуры; little-endian сжатые блоки; собственные форматы с фиксированным порядком байтов. Нельзя выбирать порядок байтов «по платформе». Его нужно подтвердить наблюдением. Пример: Bytes: 00 00 01 00 Big-endian: 0x00000100 = 256 Little-endian: 0x00010000 = 65536 Если архив содержит 256 файлов, big-endian здесь правдоподобен. Если 65536 — вероятно, интерпретация неверна. Указатели на внутренние секции В ресурсах могут быть внутренние адреса: font_table_offset glyph_count atlas_texture_id string_table_offset language_table_offset subtitle_track_offset video_cue_table_offset Важно установить, что представляет собой offset: абсолютное смещение от начала файла; относительное смещение от начала секции; относительное смещение от текущей структуры; виртуальный адрес, который не следует путать с file offset; индекс записи, а не смещение. 5. Безопасное исследование «проверки веса» Цель исследования: найти зависимые поля и правила их обновления. Рекомендуемый процесс 1. Сохранить нетронутый оригинал Работать только с копией: original/ work/ output/ reports/ Для каждой версии фиксировать: имя файла; размер; SHA-256 для локальной идентификации; дату; использованную версию инструмента. 2. Открыть бинарник в hex-редакторе Подходящие инструменты: ImHex; 010 Editor; HxD; wxHexEditor; любой hex-diff-инструмент. Искать: читаемый magic; повторяющиеся записи одинаковой длины; числа, похожие на offsets; возрастающие значения, кратные 0x10/0x800/0x1000; ASCII/UTF-8/UTF-16-строки; хеши длиной 4, 16, 20 или 32 байта. 3. Сопоставить TOC с реальными данными Для каждой записи проверить: offset + stored_size <= archive_file_size offset >= data_region_start offset % alignment == 0 Если ресурс начинается по offset 0x12000, а следующая запись начинается с 0x12800, то: real data range: [0x12000, 0x12800) allocated span: 0x800 stored size: может быть меньше 0x800 padding: allocated span - stored size 4. Выполнить минимальный контролируемый эксперимент Например, заменить один текстовый ресурс на вариант: той же длины; на 1 байт длиннее; на 16 байт длиннее; на 1 байт короче. Затем сравнить результаты упаковки или файлы, обработанные известным инструментом, если он существует. Так можно увидеть: какие поля меняются; где лежит size; меняется ли архивный размер; пересчитывается ли CRC; сохраняется ли прежний allocation span; сдвигаются ли последующие записи. 5. Построить таблицу наблюдаемых полей Пример рабочей таблицы: Offset Размер Предполагаемое поле Значение до Значение после Уверенность 0x0C 4 file_count 1532 1532 высокая 0x10 4 toc_offset 0x40 0x40 высокая 0x24 4 archive_size 0x028A4000 изменилось средняя 0x144 4 entry[0].offset 0x8000 0x8000 высокая 0x148 4 entry[0].size 0x1A2C изменилось высокая 0x14C 4 entry[0].crc32 изменилось изменилось средняя 6. Сравнивать CRC, MD5, SHA-1 и пользовательские хеши Если 4-байтовое поле меняется после изменения содержимого, проверьте кандидаты: zlib.crc32(data) & 0xFFFFFFFF Для распространённых хешей: hashlib.md5(data).digest() hashlib.sha1(data).digest() hashlib.sha256(data).digest() Но совпадение не следует предполагать: поле может быть: CRC от распакованных данных; CRC от сжатых данных; CRC от имени/пути; хешем другой секции; ID записи; пользовательским алгоритмом. 7. Реализовать dry-run До фактической упаковки вывести отчёт: Entry 0042: strings_ru.bin old offset: 0x00124000 new offset: 0x00124000 old packed size: 0x00003A20 new packed size: 0x00003B10 alignment: 0x800 padding required: 0x4F0 checksum: CRC32 9A0B1C2D status: valid 8. Не отключать проверки Если игра отвергает модифицированный архив, правильный вопрос: «Какие метаданные формат ожидает и как они вычисляются?» А не: «Как отключить проверку?» 6. Алгоритм распаковки Результат распаковки extracted/ manifest.json files/ 0000_unknown.bin 0001_menu_strings.bin 0002_font_atlas.dds 0003_font_metrics.bin reports/ extract_report.json suspicious_entries.json Пример манифеста { "format": "custom_bigfile", "source_file": "archive.bin", "source_size": 42614784, "endianness": "big", "header": { "version": 3, "file_count": 1532, "toc_offset": 64, "data_offset": 49152, "alignment": 2048 }, "entries": [ { "index": 0, "name": "0000_unknown.bin", "name_hash": "0xA1B2C3D4", "original_offset": 49152, "stored_size": 6700, "unpacked_size": 6700, "flags": 0, "compression": "none", "checksum_type": "crc32", "checksum": "0x19D5A0F3", "alignment": 2048 } ] } Пошаговый алгоритм Открыть файл в бинарном режиме. Прочитать минимальный заголовок. Проверить magic и версию. Определить endian-порядок. Прочитать размер заголовка и расположение TOC. Прочитать все записи TOC. Для каждой записи: извлечь offset, stored_size, unpacked_size, flags; проверить выход за границы файла; проверить выравнивание; извлечь блок; проверить CRC/hash, если алгоритм известен; определить сжатие по флагам или сигнатуре; распаковать известный формат, например zlib/deflate; сохранить файл и метаданные. Записать манифест. Создать отчёт о подозрительных местах. Подозрительные записи Нужно фиксировать, но не игнорировать: offset + size > archive_size; offset не выровнен; два файла перекрываются; размер распакованных данных не совпадает с unpacked_size; неизвестный compression flag; checksum не совпадает; пустой файл с необычными флагами; запись с offset 0, но ненулевым размером. 7. Алгоритм обратной упаковки Обратная упаковка должна быть детерминированной: одинаковый вход и параметры дают одинаковый результат. Основной порядок работы Прочитать manifest.json. Проверить, что все ожидаемые файлы существуют. Сохранить исходный порядок записей. Для каждого файла: прочитать изменённые данные; сжать тем же способом, что указан в манифесте; определить фактический stored size; обновить unpacked size; вычислить checksum нужного типа. Рассчитать новые offsets с учётом alignment. Создать новый TOC. Записать заголовок, TOC, имена и метаданные. Записать блоки данных и padding. Обновить размер контейнера, если он хранится. Выполнить внутреннюю проверку созданного файла. Сравнить структуру с оригиналом через verify и diff-toc. Важное решение: перемещать файлы или сохранять исходные места Есть два режима. Режим A: полная перепаковка Все offsets рассчитываются заново. Плюсы: подходит для значительных изменений; не ограничивает размер конкретного ресурса; проще алгоритмически. Минусы: все последующие данные могут сдвинуться; внешние ссылки на offset могут стать невалидными; архив может сильнее отличаться от оригинала. Режим B: in-place / фиксированные слоты Файлы остаются на старых offsets и не могут превысить выделенный span. Плюсы: минимальные отличия; безопаснее, если внешний бинарник хранит offsets; удобно для маленьких текстовых правок. Минусы: новый файл нельзя сделать больше доступного места; приходится перераспределять резерв или сокращать данные. Для первой версии полезно поддержать оба режима: rctool pack extracted —mode rebuild rctool pack extracted —mode in-place Проверки после сборки header.file_count == len(entries) entry.offset % alignment == 0 entry.offset + entry.stored_size <= archive_size no_ranges_overlap(entries) stored_size == len(stored_data) unpacked_size == len(unpacked_data) checksum(entry_data) == entry.checksum 8. Работа со шрифтами и атласами Шрифт в игре часто состоит минимум из двух частей: текстурный атлас — изображение с пикселями символов; таблица метрик — бинарная структура, объясняющая движку, где искать глиф и как его рисовать. Иногда добавляются: таблица Unicode/codepoint → glyph index; kerning pairs; несколько атласов для разных размеров; fallback-шрифт; таблицы языков; стиль текста: обводка, тень, цвет, масштаб. Где может быть таблица глифов Она может находиться: рядом с текстурой в одном контейнере; в отдельном .bin, .fnt, .font, .dat; внутри бинарника движка; внутри локализационного пакета; в ресурсной записи, найденной по имени или хешу. Признаки таблицы: последовательность структур фиксированного размера; значения x/y/width/height, не превышающие размеры атласа; ASCII-коды 0x20—0x7E; количество записей, близкое к 96, 128, 256, 512, 1024; повторяющиеся значения advance/width; ссылки на одну и ту же текстуру. Варианты хранения символов Модель Пример Direct ASCII Glyph 65 = A. Unicode codepoint U+0410 → глиф А. Индексная таблица Codepoint → индекс → запись глифа. Custom encoding Байтовые коды игры отображаются в собственную таблицу. Смешанная схема ASCII напрямую, расширенные символы через lookup table. Типичная запись глифа struct Glyph { uint32_t codepoint; // U+0041, U+0410 и т. п. uint16_t atlas_index; // номер атласа uint16_t flags; float u0; // левая UV-координата float v0; // верхняя UV-координата float u1; // правая UV-координата float v1; // нижняя UV-координата int16_t bearing_x; // смещение пера по X int16_t bearing_y; // смещение пера по Y uint16_t width; uint16_t height; int16_t advance_x; // на сколько сдвигать курсор }; В другом формате UV могут быть не float, а пиксельными координатами: struct Glyph { uint16_t codepoint; uint16_t x; uint16_t y; uint16_t width; uint16_t height; int16_t advance; int16_t bearing_x; int16_t bearing_y; }; Добавление кириллицы без поломки латиницы Безопасная стратегия: Сначала извлечь существующие символы и создать отчёт. Определить диапазоны: ASCII: U+0020—U+007E; кириллица: U+0400—U+04FF; часто нужные символы: Ё, ё, №, длинное тире, кавычки. Не заменять латинские глифы, если их индексы используются напрямую. Добавить новые записи в свободный диапазон либо расширить таблицу только после понимания её структуры. Внести символы в codepoint lookup table. Добавить пиксели символов в атлас. Обновить UV/координаты, размеры и advance. Проверить fallback-логику: некоторые движки заменяют неизвестный символ ? или пустым глифом. Почему может понадобиться новый атлас Если в исходном атласе нет свободного места, новые глифы некуда разместить. Варианты: уплотнить существующие символы; использовать пустые/неиспользуемые глифы; увеличить разрешение атласа, если формат и движок это допускают; добавить второй атлас, если таблица поддерживает atlas_index; уменьшить размер шрифта; выбрать компактный набор символов. Нельзя просто увеличить DDS/текстуру, не проверив, где хранится ширина, высота, mipmap count и формат пикселей. Проверка границ глифа Для атласа 1024 × 1024: 0 <= x < 1024 0 <= y < 1024 x + width <= 1024 y + height <= 1024 Для нормализованных UV: 0.0 <= u0 <= u1 <= 1.0 0.0 <= v0 <= v1 <= 1.0 Автоматический font-report Отчёт должен содержать: Atlas: font_0.dds Resolution: 1024 x 1024 Glyph entries: 248 Unique codepoints: 246 Duplicate codepoints: U+003F, U+0410 Out-of-bounds glyphs: 2 Missing Russian characters: U+0401, U+0451, U+042A Unused atlas area: 31.4% Идеально также создать: CSV с метриками; JSON для дальнейшего анализа; PNG-превью с сеткой и подписанными glyph indices; перечень символов, реально используемых в переводе, но отсутствующих в шрифте. 9. PSARC и привязка к контейнеру Если ресурсы находятся в PSARC или похожем контейнере, его нужно рассматривать как отдельный слой. PSARC ├─ archive TOC ├─ block/deflate metadata ├─ file path table или hash table └─ внутренние ресурсы ├─ font atlas ├─ font metrics ├─ strings ├─ subtitles └─ texture packages Требования к PSARC-адаптеру Прочитать заголовок контейнера. Прочитать и сохранить TOC. Сохранить порядок файлов. Сохранить размеры блоков и признаки сжатия. Извлечь внутренние файлы. Создать отдельный PSARC-манифест. При сборке применить исходное выравнивание и порядок. Выполнить валидацию offsets, размеров и блоков. Внешние зависимости После изменения PSARC нужно проверить, есть ли другой файл, который хранит: путь к архиву; хеш ресурса; индекс файла в архиве; ожидаемый размер; offset; версию пакета; таблицу языков; список загружаемых ресурсов. Если такая зависимость найдена, корректно обновляется или валидируется именно её открытая ресурсная структура. Работа с защищёнными исполняемыми модулями и механизмами платформы остаётся вне рамок инструмента. 10. Субтитры и видео Субтитры могут быть реализованы несколькими способами. Вариант Что редактируется Строки текста + таймкоды Таблица строк и cue table. Текстуры субтитров Атлас изображений и таблица кадров. Предрендеренные изображения Последовательность текстур/спрайтов. Встроенные в видео Практически не редактируются без исходного видеопайплайна. Скриптовые события Команды показа текста с timestamp и ID строки. Что проверить формат времени: кадры, миллисекунды, ticks; FPS: 25, 30, 50, 60 или иной; ID строки и соответствие локализационной таблице; порядок cue-записей; длительность отображения; кодировку текста; максимальную длину строки; переносы, теги и управляющие символы; привязку к конкретному ролику или главе. Типичная структура cue struct SubtitleCue { uint32_t start_time; uint32_t end_time; uint32_t string_id; uint16_t style_id; uint16_t flags; }; При текстурных субтитрах вместо string_id могут быть: uint16_t atlas_id; uint16_t sprite_id; Нельзя менять порядок или количество записей без проверки того, как ролик или сценарий обращается к ним. 11. Рекомендуемый стек Python: лучший старт для исследования Python хорошо подходит для первого рабочего прототипа. Библиотека Назначение struct Чтение и запись чисел заданного endian-порядка. pathlib Безопасная работа с путями. argparse CLI. json Манифесты и отчёты. logging Диагностика. zlib CRC32, deflate, zlib. hashlib MD5/SHA-1/SHA-256 для исследования. dataclasses Описание header/entry структур. pytest Unit-тесты. Пример чтения big-endian числа: import struct file_count = struct.unpack(">I", data[0x08:0x0C])[0] Little-endian: file_count = struct.unpack("<I", data[0x08:0x0C])[0] C# Подходит, если нужен GUI: удобная работа с бинарными файлами; WPF/Avalonia для интерфейса; просмотр atlas/glyph table; drag-and-drop для архивов; Windows-ориентированный пайплайн. Rust / C++ Подходят для финального производительного инструмента: строгая работа с бинарными структурами; контроль ошибок; большие архивы; потоковая обработка; безопасное разделение модулей. Но начинать исследование формата обычно быстрее в Python. Инструменты анализа 010 Editor — шаблоны бинарных форматов. ImHex — pattern language, визуальный анализ. HxD — быстрый просмотр и сравнение. QuickBMS — быстрые экспериментальные скрипты для распаковки известных форматов. vbindiff / Beyond Compare / Hex Fiend / HxD — побайтовое сравнение. Kaitai Struct — декларативное описание формата и генерация парсеров. 12. MVP-архитектура rctool/ cli.py config.py formats/ base.py custom_archive.py psarc.py parsers/ header_parser.py toc_reader.py font_table_parser.py subtitle_parser.py services/ extractor.py repacker.py verifier.py diff_service.py manifest_service.py codecs/ compression_handler.py checksum_validator.py texture_adapter.py models/ archive_header.py archive_entry.py font_glyph.py manifest.py reporting/ logger.py json_report.py font_report.py tests/ test_header_parser.py test_toc_reader.py test_repacker.py test_alignment.py fixtures/ Назначение модулей Модуль Ответственность header_parser Чтение и валидация заголовка. toc_reader Чтение записей файловой таблицы. entry_extractor Извлечение конкретных блоков. compression_handler Сжатие/распаковка известных алгоритмов. checksum_validator CRC/hash-проверки и пересчёт. repacker Сборка контейнера, offsets и padding. manifest_serializer Сохранение метаданных извлечения. font_table_analyzer Глифы, метрики, codepoint table, UV. psarc_adapter Поддержка PSARC как отдельного формата. CLI interface Команды и параметры пользователя. logger/reporter Диагностика, отчёты, dry-run. 13. Тестирование Не хранить игровые ассеты в репозитории В репозитории должны находиться только: синтетические тестовые архивы; минимальные искусственные текстуры; тестовые таблицы глифов; обезличенные фрагменты заголовков при необходимости; генераторы фикстур. Не следует добавлять оригинальные данные игры. Набор тестов Unit-тесты чтение big-endian и little-endian значений; чтение header; чтение TOC; выравнивание 0x10, 0x80, 0x800, 0x1000; проверка диапазонов; CRC32; сжатие и распаковка; сериализация манифеста; проверка UV и границ глифов. Интеграционные тесты synthetic archive -> extract -> pack -> verify -> byte-identical result Если архив собирается без изменений, ожидаемый результат: original.bin == repacked.bin Побайтовая идентичность крайне полезна: она доказывает, что парсер и упаковщик верно воспроизводят формат хотя бы для неизменённого случая. Тесты изменения размера Файл без изменения длины. Файл увеличен на 1 байт. Файл увеличен до следующего alignment boundary. Файл уменьшен. Несколько файлов изменены одновременно. Сжатый файл, у которого packed size меняется непредсказуемо. Проверка отчётом rctool verify original.bin repacked.bin —structure-only rctool diff-toc original.bin repacked.bin 14. Типичные ошибки Ошибка Последствие Перепутан big-endian и little-endian Неверные offsets, sizes, counts; файл не читается. Не учтён padding Следующий ресурс начинается не там, где ожидает TOC. Изменён порядок записей Внешние индексы или хеш-таблицы указывают не на тот ресурс. Не обновлена offset table Движок читает старые адреса. Не обновлены size fields Переполнение, обрезание или отказ загрузки. Не пересчитан CRC/hash Формат определяет ресурс как повреждённый. Нарушено выравнивание Ошибка чтения блоков или проблемы DMA/потоковой загрузки. Неверно определено сжатие Невозможно распаковать ресурс. Строка сохранена в неверной кодировке Кракозябры, пустые символы, сбои parser-а. Не учтена нуль-терминация Следующая строка «склеивается» с текущей. Таблица глифов не соответствует атласу Неправильные буквы, визуальный мусор, вылет. Кириллица добавлена без codepoint table Игра не находит символы. UV выходят за границы Захватываются соседние глифы или пустые области. DDS/текстура пережата в другом формате Неподдерживаемый pixel format, неверные цвета или крах. Не обновлены mipmaps Артефакты или ошибка загрузки текстуры. Субтитры потеряли тайминги Реплики появляются слишком рано, поздно или не появляются. Изменена длина блока, но старые внешние offsets сохранены Ломается загрузка последующих данных. Техническое ТЗ для MVP Цель Разработать CLI-утилиту для анализа, извлечения, проверки и обратной упаковки открытых игровых ресурсных контейнеров, с сохранением структуры, порядка записей, offsets, размеров, выравнивания и контрольных сумм. Функциональные требования Автоматическое или заданное пользователем определение формата. Поддержка big-endian и little-endian. Чтение заголовка и TOC. Извлечение всех ресурсов. Генерация JSON-манифеста. Поддержка known compression codecs, начиная с none и zlib. Проверка CRC32 и известных хешей. Детерминированная перепаковка. Поддержка rebuild и in-place режимов. dry-run, verify, diff-toc. Анализ шрифтов: глифы, codepoints, метрики, UV, пересечения и границы. Отчёты JSON/CSV/text. Набор тестов на синтетических контейнерах. Нефункциональные требования не изменять входные файлы; не требовать доступа к защищённым системным компонентам; не содержать оригинальные игровые ассеты; давать понятные ошибки вместо молчаливой записи повреждённого файла; вести лог операций; обеспечивать воспроизводимость упаковки. Псевдокод парсера function parse_archive(path, format_config): file_size = get_file_size(path) stream = open_binary(path) raw_header = stream.read(MIN_HEADER_SIZE) magic = raw_header[0:4] if magic not in format_config.supported_magic: raise UnsupportedFormatError(magic) endian = detect_endianness(raw_header, format_config) header = read_header(stream, endian, format_config) validate_header(header, file_size) stream.seek(header.toc_offset) entries = [] for index in range(header.file_count): entry = read_toc_entry(stream, endian, format_config) entry.index = index validate_entry_range(entry, file_size) validate_entry_alignment(entry, header.alignment) entries.append(entry) names = read_name_table_if_present(stream, header, format_config) assign_names(entries, names) return Archive( path=path, file_size=file_size, header=header, entries=entries, endian=endian ) Псевдокод распаковщика function extract_archive(archive_path, output_dir): archive = parse_archive(archive_path) create_directory(output_dir) create_directory(output_dir / "files") create_directory(output_dir / "reports") manifest = create_manifest_from_archive(archive) suspicious_entries = [] stream = open_binary(archive_path) for entry in archive.entries: stream.seek(entry.offset) stored_data = stream.read(entry.stored_size) if length(stored_data) != entry.stored_size: suspicious_entries.append(entry, "truncated data") continue if entry.compression is known: unpacked_data = decompress(stored_data, entry.compression) else if entry.compression is none: unpacked_data = stored_data else: save_raw_data(entry, stored_data) suspicious_entries.append(entry, "unknown compression") continue if entry.unpacked_size exists and length(unpacked_data) != entry.unpacked_size: suspicious_entries.append(entry, "unpacked size mismatch") checksum_result = verify_checksum(entry, stored_data, unpacked_data) if checksum_result is invalid: suspicious_entries.append(entry, "checksum mismatch") output_name = create_safe_output_name(entry) write_binary(output_dir / "files" / output_name, unpacked_data) manifest.entries[entry.index].extracted_name = output_name manifest.entries[entry.index].verification = checksum_result write_json(output_dir / "manifest.json", manifest) write_json(output_dir / "reports" / "suspicious_entries.json", suspicious_entries) return manifest Псевдокод упаковщика function pack_archive(extracted_dir, output_path, mode): manifest = read_json(extracted_dir / "manifest.json") validate_manifest(manifest) prepared_entries = [] for entry_meta in manifest.entries in original index order: input_path = extracted_dir / "files" / entry_meta.extracted_name unpacked_data = read_binary(input_path) stored_data = compress( unpacked_data, method=entry_meta.compression, settings=entry_meta.compression_settings ) entry = copy_metadata(entry_meta) entry.unpacked_size = length(unpacked_data) entry.stored_size = length(stored_data) entry.checksum = calculate_checksum( entry_meta.checksum_type, stored_data, unpacked_data, entry_meta.checksum_scope ) prepared_entries.append((entry, stored_data)) if mode == "in-place": assign_original_offsets_with_capacity_checks(prepared_entries, manifest) else if mode == "rebuild": current_offset = manifest.header.data_offset for entry, stored_data in prepared_entries: current_offset = align_up(current_offset, entry.alignment) entry.offset = current_offset current_offset += length(stored_data) archive_size = current_offset else: raise InvalidModeError(mode) validate_no_overlap(prepared_entries) validate_all_alignments(prepared_entries) header = rebuild_header(manifest.header, prepared_entries, archive_size) toc = serialize_toc(prepared_entries, manifest.endianness) output = open_binary_for_write(output_path) write_header(output, header) write_toc(output, toc) write_name_table_if_needed(output, manifest) for entry, stored_data in prepared_entries: seek_or_pad_to(output, entry.offset) output.write(stored_data) write_padding_to_alignment(output, entry.alignment) close(output) result = parse_archive(output_path) verify_repacked_structure(result, prepared_entries) return result Поля, которые нужно исследовать в неизвестном формате Минимальный список: Magic/signature. Версия. Endianness. Размер заголовка. Число записей. Смещение TOC. Размер одной TOC-записи. Смещение таблицы имён. Смещение области данных. Offset каждой записи. Packed size. Unpacked size. Compression flags. Encryption flags — только для идентификации; не для обхода. CRC/hash и область, по которой они считаются. ID/хеш имени. Alignment. Padding pattern. Поле общего размера архива. Внешние ссылки на архив, индекс или ресурс. Внутренние offsets конкретных форматов — шрифт, атлас, локализация, субтитры. Версия текстурного формата, ширина, высота, mip levels, pixel format. Таблица Unicode/codepoint → glyph index. Метрики glyph table. Таблицы языков и string IDs. Формат subtitle cue и единицы таймингов. Вопросы для формата, который пока неизвестен Для точного анализа полезно получить не весь игровой архив, а безопасные технические сведения и небольшие обезличенные фрагменты: Первые 0x100—0x400 байт заголовка в hex-формате. Размер файла в байтах и hex. Hex-дамп предполагаемой TOC: 5—10 записей. Предполагаемый размер записи TOC: 16, 20, 24, 32 или 48 байт. Несколько известных offsets и соответствующие им размеры. Название/расширение контейнера: .psarc, .pak, .dat, .bin, .arc и т. п. Начало одного извлечённого ресурса: первые 0x40—0x100 байт. Сравнение оригинального и изменённого файла, если существует образец, созданный известным инструментом. Какие данные точно известны: имя ресурса, размер текстуры, число символов шрифта, ожидаемая строка. Скриншот или экспорт структуры из ImHex/010 Editor. Для шрифта: размер атласа, несколько известных символов, их предположительные координаты. Для субтитров: пример одной реплики, её таймкод в игре и соответствующий фрагмент файла. PS3 или Vita-версия, регион и версия игры: структуры ресурсов могут отличаться. Не нужно передавать защищённые исполняемые файлы, ключи, лицензионные данные или полный коммерческий архив. Безопасный план работ в 5 шагов Шаг 1. Инвентаризация Создать копии исходных файлов. Зафиксировать размеры и SHA-256 локально. Определить контейнеры, текстуры, шрифты, локализации и субтитры. Найти открытые ресурсные архивы, пригодные для анализа. Шаг 2. Read-only анализ Реализовать inspect, list, verify. Определить magic, endian, header, TOC, offsets, sizes и alignment. Создать отчёт о структуре без записи файлов. Шаг 3. Распаковка и воспроизводимая сборка без изменений Реализовать extract. Сохранить manifest. Реализовать pack. Достичь побайтового совпадения original == repacked для тестового контейнера без изменений. Шаг 4. Контролируемые изменения ресурсов Изменить один текстовый ресурс. Затем протестировать шрифт и один небольшой атлас. Проверить size, CRC, offsets, padding и загрузку на собственной тестовой среде. Использовать in-place режим, если внешние ссылки не изучены. Шаг 5. Специализация под перевод Реализовать анализ таблиц строк. Добавить font-report, проверку кириллицы и atlas-границ. Реализовать subtitle-report. Подготовить распространение в виде патча, манифеста или инструкций, а не полного набора оригинальных ресурсов. Итоговая рекомендация Практически лучший путь — начать не с «универсального перепаковщика PS3-игр», а с узкого исследовательского инструмента: inspect -> list -> extract -> manifest -> rebuild unchanged -> verify -> edit one resource Критическая контрольная точка: инструмент должен сначала уметь распаковать и собрать неизменённый архив так, чтобы результат был побайтово идентичен оригиналу либо, если формат намеренно недетерминирован, структурно и checksum-совместим. Только после этого разумно переходить к текстам, шрифтам, атласам, кириллице и субтитрам. Предлагаю написать универсальный комбайн-софт, для распаковки-запаковки PS3 игр. С заменой латиницы на кириллицу, с подтверждением , если длина разная, автоматическим подбора похожего шрифта игры. Но нужны ответы на вопросы. Какой функционал обязательно должен быть. GUI или CLI оболочка и. т. д. Скорее всего получится переводчик именно под все игры Ratchet and Clank. -
-
-
Автор: DjGiza · Опубликовано:
Это была отсылка) Могу в стиме отзыв сделан сам на себя и написать русским игрокам повезло что получили лучший перевод -
Автор: adm-244 · Опубликовано:
Старые версии AGS довольно чувствительны к файлу конфигурации, в acsetup.cfg обязательно должны присутствовать обе секции “[sound]” и “[misc]” (хотя бы пустые). Шрифты должны быть в кодировке KOI7-N1, ваши же просто заменяют латиницу в алфавитном порядке. Поправил порядок в одном из шрифтов чтобы было понятно как он должен выглядеть. Также в TRS файле текст закодирован в основном в верхнем регистре, что соответствует заглавным символам латиницы, а не кириллицы. В остальном всё вроде бы в норме. По ссылке файл корректный файл конфига и исправленный шрифт: https://tempfile.org/okRFVZjte6x/ -
Автор: NinetyThird · Опубликовано:
Приветствую всех! “Полвека” был читателем — и вот наконец стал «писателем»! Пишу своё первое сообщение на форуме. Надеюсь, вы примете меня в свою компанию. И пусть это будет не последний мой пост — а то вдруг затянет! -
Автор: ХР0М · Опубликовано:
Так вроде во всех браузерах уже давно есть функция перевода. В Google Chrome уже много лет есть такая возможность. -
Автор: Slaif · Опубликовано:
Я уже писал у себя в телеге, продублирую тут, для всех недовольствующих
Почему русик платный? Ответ будет банален — это работа. Я для перевода этой игры пожертвовал своей основной работой+платный инструментарий и нервы, чтобы это чудо вышло на свет. Да и стоит он смешных денег
Ну, и я первый кто её русифицировал до конца с момента релиза с 2020 года
Всем, кто помогал в тестах большое спасибо, они получили русик бесплатно
-
-
Изменения статусов
-
Perfect End Strange » SerGEAnt
Привет, озвучку для Silent Hill 4: The Room выпустил энтузиаст под ником Perfect End Strange, а вы написали совсем другую студию, пожалуйста, исправьте эту оплошность· 0 ответов
-
я его уже открыл в свободный доступ, чтобы не потерялось среди новинок· 0 ответов
-
-
Доброго времени! Недавно столкнулся с проблемой автоперевода XUnity AutoTranslator BeplnEx iL2cc. Пару последних лет часто пользовался, теперь консольные команды виснут на стадии загрузки библиотек, хотя они есть там изначально. На GitHub есть подобные вопросы, но ни одного рабочего ответа я не нашел. А Вы что можете посоветовать?· 0 ответов
-
Доброго времени. По локализации игры Wicked Seed. Шрифт размазан и в полях, другие можно попробовать? Например arialuni_sdf_2022? Я профан в этом, но интересно.· 0 ответов
-
-
Лучшие авторы
-
1
-
2
-
3
-
4
-
5
-
