วิธีแปลเกม Unreal Engine

เกม Unreal Engine ดูเหมือนสิ่งที่แปลยากที่สุดในไดรฟ์ของคุณ ไม่มีโฟลเดอร์ data ไม่มีไฟล์สคริปต์ ไม่มี .json ให้เปิด — มีแค่ไฟล์ปฏิบัติการ ไดเรกทอรี Content/Paks ที่เก็บไฟล์ .pak ขนาดมหึมาหนึ่งหรือสองไฟล์ และอาจมีคอนเทนเนอร์ .utoc/.ucas อีกคู่หนึ่ง ข่าวดีคือข้อความที่คุณต้องการจริง ๆ มักไม่ได้ถูกซ่อนอยู่ในไฟล์พวกนั้นโดยตั้งใจ Unreal มีระบบแปลภาษาชั้นหนึ่ง และเกมที่วางจำหน่ายส่วนใหญ่ใช้มัน งานของคุณคือหาตารางให้เจอ แทนที่สตริง แล้วยื่นไฟล์เล็ก ๆ ที่มีลำดับความสำคัญเหนือของเดิมให้เอนจิน

ส่วนสุดท้ายนั่นแหละที่ทำให้ Unreal น่าทำงานด้วยเมื่อคุณเข้าใจมันแล้ว คุณไม่ต้องสร้างเกมขนาด 60 GB ขึ้นใหม่ คุณผลิตอาร์ไคฟ์ทับที่วัดขนาดกันเป็นกิโลไบต์ แล้ววางไว้ข้างของเดิม

อีกเรื่องก่อนเข้าขั้นตอน: การรองรับ Unreal ใน RuneTranslate เป็นแบบ พยายามอย่างเต็มที่ และใหม่กว่าเอนจินอย่าง RPG Maker หรือ Ren’Py มันได้รับการยืนยันแล้วว่าเล่นได้จริงบนเกม UE4 ของจริง แต่พื้นผิวของรูปแบบไฟล์นั้นกว้างมหาศาลและแต่ละสตูดิโอแพ็กไม่เหมือนกัน ตรวจสอบบิลด์ที่ส่งออกในเกมก่อนลงมือรันการแปลยาว ๆ

เกม Unreal ส่งอะไรมาบ้างจริง ๆ

Unreal เก็บข้อความที่ผู้เล่นเห็นไว้ในไฟล์ `.locres` — รูปแบบที่คอมไพล์แล้วของ FTextLocalizationResource มีหนึ่งไฟล์ต่อหนึ่งวัฒนธรรม วางอยู่บนพาธประมาณ <Game>/Content/Localization/Game/ja/Game.locres โดยมีพี่น้องสำหรับ en, zh-Hans และอะไรก็ตามที่สตูดิโอส่งมา เกมที่ไม่มีคำแปลเลยก็ยังมักมีอยู่หนึ่งไฟล์ สำหรับวัฒนธรรมที่เขียนต้นฉบับไว้

.locres ไม่ใช่ไฟล์ข้อความ และไม่ใช่รายการคีย์/ค่าแบบง่าย ๆ มันคือตารางไบนารีที่จัดเป็น เนมสเปซ แต่ละเนมสเปซถือ คีย์ และแต่ละคีย์ชี้ไปที่สตริงหนึ่ง ในเวอร์ชันใหม่ ๆ เนมสเปซและคีย์ถูกเก็บเป็น แฮช (CRC32 ในเวอร์ชัน 2, CityHash64 บน UTF-16 ในเวอร์ชัน 3) แทนที่จะเป็นชื่อที่อ่านออก และตัวสตริงเองอยู่ในตารางค้นหาที่ใช้ร่วมกันและตัดตัวซ้ำออกแล้ว พร้อมตัวนับการอ้างอิง รันไทม์ไม่เคยค้นหาสตริงจากข้อความภาษาอังกฤษของมัน — มันค้นหาจากคู่เนมสเปซ/คีย์นั้น ซึ่งถูกคอมไพล์เข้าไปใน Blueprint และ C++ ของเกมตอนบิลด์

โครงสร้างนั้นกำหนดว่าวิธีแก้ไขที่ปลอดภัยมีอยู่ทางเดียว RuneTranslate รักษาแฮชเนมสเปซ แฮชคีย์ และแฮชสตริงต้นฉบับทุกตัวไว้ ตรงทุกไบต์ แล้วเปลี่ยนเฉพาะค่า จากนั้นสร้างตารางสตริงที่ตัดตัวซ้ำและตัวนับการอ้างอิงของมันขึ้นใหม่ ไม่มีอะไรคำนวณแฮชใหม่ จึงไม่มีอะไรสร้างคีย์ที่เกมหาไม่เจอได้ คำแปลจะยาวหรือสั้นกว่าต้นฉบับก็ได้อย่างอิสระ

ไฟล์ .locres เหล่านี้ถูกแพ็กเข้าไปในอาร์ไคฟ์ .pak — ระบุได้จากค่ามหัศจรรย์ 0x5A6F12E1 ในส่วนท้ายสุดของไฟล์ — หรือบนเกม UE5 ยุคใหม่ ถูกแพ็กเข้าคอนเทนเนอร์ IoStore .utoc/.ucas

เช็คขอบเขตก่อนเสียเวลาหนึ่งชั่วโมง

.locres ครอบคลุม UI เมนู ข้อความระบบ ข้อความสอนเล่น ชื่อไอเทมและสกิล และซับไตเติล — ประมาณคร่าว ๆ ราว 90% ของข้อความที่มองเห็นในเกมทั่วไป นั่นคือส่วนที่ RuneTranslate อ่านและเขียน

สิ่งที่มันไม่ครอบคลุม: ข้อความที่คอมไพล์อยู่ใน DataTable หรืออบไว้ในแพ็กเกจ `.uasset` ที่ผ่านการ cook แล้ว บางสตูดิโอ — โดยเฉพาะโปรเจกต์เล็กหรือโปรเจกต์ที่ขับเคลื่อนด้วย Blueprint หนัก ๆ — เก็บบทสนทนาไว้ตรงนั้นแทนที่จะเก็บในระบบแปลภาษา สตริงเหล่านั้นถูกระบุตำแหน่งด้วยแฮชอยู่ในแพ็กเกจที่ cook แล้ว โดยไม่มีดัชนีไดเรกทอรีที่อ่านออก และการอ่านมันอย่างถูกต้องต้องใช้ไฟล์แมป .usmap ที่เกมซึ่งวางจำหน่ายไม่ได้ใส่มาด้วย หากเกมของคุณเก็บสคริปต์ไว้ตรงนั้น การดึงข้อความจะได้เมนูกับปุ่มกลับมาและไม่มีบทสนทนาเลย และ RuneTranslate รายงานว่านั่นคือผลลัพธ์ที่อยู่นอกขอบเขตอย่างชัดเจน แทนที่จะทำเป็นว่าสำเร็จ

ควรรู้ไว้แต่เนิ่น ๆ: วิธีเช็คที่เร็วที่สุดคือรันขั้นตอนสร้างโปรเจกต์แล้วดูว่าได้อะไรออกมา สตริงสั้นไม่กี่ร้อยตัวที่หน้าตาเป็น Continue, Options, Are you sure? ทั้งหมด แปลว่า UI ถูกแปลภาษาไว้แต่สคริปต์ไม่ได้ถูกแปล ส่วนสตริงหลายพันตัวที่มีประโยคเต็ม ๆ อยู่ด้วย แปลว่าคุณอยู่ในสถานะที่ดี

คีย์ AES และทำไมมันไม่ใช่กำแพง

pak ที่วางจำหน่ายจำนวนมากถูก เข้ารหัส AES-256 — เจาะจงคือโหมด ECB ที่ไม่มี IV ใช้กับดัชนีของอาร์ไคฟ์และบ่อยครั้งกับแต่ละรายการข้างในด้วย หากไม่มีคีย์ อาร์ไคฟ์ก็ทึบตัน: คุณแม้แต่จะแสดงรายการสิ่งที่อยู่ข้างในก็ยังทำไม่ได้

คีย์กู้คืนได้ด้วยเหตุผลที่ตรงไปตรงมา เกมต้องอ่านอาร์ไคฟ์ของตัวเองตอนรันไทม์ บนเครื่องที่ไม่มีเน็ตและไม่มีเซิร์ฟเวอร์ตรวจสอบสิทธิ์ คีย์จึงอยู่ในไบนารีที่วางจำหน่ายในฐานะข้อมูลธรรมดา RuneTranslate สแกนไฟล์ปฏิบัติการและ DLL ของมันหาหน้าต่างขนาด 32 ไบต์ ตัดตัวเลือกทิ้งด้วยเกณฑ์เอนโทรปี (คีย์ AES จริงมีไบต์ที่ต่างกันอย่างน้อย 25 จาก 32) เช็คแบบง่าย ๆ ด้วยการถอดรหัสบล็อกแรกของดัชนีแล้วถามว่าค่านำหน้าอ่านเป็นความยาวสตริงที่เป็นไปได้หรือไม่ แล้วจึง ตรวจสอบ ตัวที่รอดมาอย่างจริงจัง: ถอดรหัสดัชนีทั้งชุดแล้วเทียบ SHA-1 ของมันกับแฮชที่ส่วนท้ายของ pak เองบันทึกไว้ ขั้นตอนสุดท้ายนั้นคือความต่างระหว่างวิธีนี้กับตัวหาคีย์แบบจัดอันดับด้วยเอนโทรปีที่ลอยอยู่ทั่วไป — ตัวเลือกหนึ่ง ๆ ต้องสร้างแฮชที่อาร์ไคฟ์บันทึกไว้เองขึ้นมาใหม่ได้ ไม่อย่างนั้นก็ถูกปฏิเสธ คีย์ที่ผิดถูกยอมรับไม่ได้เลย

บางเกมเก็บคีย์เป็นข้อความแทนที่จะเป็นไบต์ดิบ และบางเกมแยกมันไว้ในคำสั่งคนละที่ในไบนารี ทั้งสองกรณีถูกจัดการให้ หากไม่ได้ผลสักทาง กล่องโต้ตอบ New Project รับคีย์ที่วางเข้ามาเป็นเลขฐานสิบหก (0x… หรือ 64 อักขระฐานสิบหก) หรือ base64 และเมื่อกู้คืนได้แล้ว คีย์จะถูกแคชไว้ต่อโปรเจกต์ คุณจึงไม่ต้องสแกนไฟล์ปฏิบัติการขนาด 85 MB ใหม่ทุกครั้งที่ส่งออก

UE5 IoStore ต่างออกไป และการดึงข้อความถูกเล็งไว้แล้ว

เกม UE5 ส่ง IoStore มาแทน pak ธรรมดามากขึ้นเรื่อย ๆ: ไดเรกทอรี .utoc จับคู่กับก้อนข้อมูล .ucas ใช้การบีบอัด Oodle และการเข้ารหัสของตัวเอง วิธีตรง ๆ ตรงนี้คือแกะมันออกมาทั้งหมด ซึ่งบนเกมขนาด 105 GB ก็ไม่ถือเป็นวิธีเลย

RuneTranslate รวม retoc (สัญญาอนุญาต MIT) มาด้วย และสั่งให้มันแปลงคอนเทนเนอร์เป็น pak แบบดั้งเดิมโดย กรองเฉพาะไฟล์แปลภาษา — เทียบเท่ากับ to-legacy -f locres --no-shaders --no-script-objects เกม IoStore ขนาด 105 GB ถูกกรองลงเหลือ .locres ไม่กี่กิโลไบต์ ในเวลาไม่กี่วินาทีแทนที่จะเป็นหลายชั่วโมง retoc ยังจัดการ AES และ Oodle ของคอนเทนเนอร์เองด้วย ซึ่งเป็นเหตุผลที่เกม IoStore เลี่ยงปัญหา Oodle ที่ pak แบบหลวมอาจเจอได้

ครึ่งที่สำคัญของเรื่องนี้คือ IoStore ทำให้เรื่อง การอ่าน ยุ่งยากขึ้นเท่านั้น ส่วนการเขียนนั้นใช้ได้ทั่วไป และนั่นคือหัวข้อถัดไป

ผลลัพธ์คือ pak ทับ ไม่ใช่เกมที่สร้างใหม่

นี่คือส่วนที่ไม่มีคู่มือเจ้าไหนอธิบายอย่างถูกต้อง และเป็นเหตุผลที่การแปล Unreal นั้นถูกเมื่อมันทำงานได้แล้ว

Unreal เมานต์ไฟล์ pak ตามลำดับที่กำหนดไว้ และอาร์ไคฟ์ใดที่ชื่อลงท้ายด้วย `_P` จะถูกเมานต์ ท้ายสุด ตัวที่เมานต์ทีหลังชนะ ดังนั้นอาร์ไคฟ์เล็ก ๆ ที่มีแค่ .locres ที่คุณแก้ไข วางอยู่ที่พาธเสมือนเดียวกับที่เกมต้นฉบับใช้ ก็จะบังของเดิมไว้เฉย ๆ — ตัวจัดการการแปลภาษาโหลดของคุณ และไม่เคยเห็นของที่ส่งมากับเกมเลย

• ไม่ต้องเซ็นใหม่ การเซ็น pak เป็นกลไก RSA คนละส่วนโดยสิ้นเชิง และแทบไม่ถูกบังคับใช้ในเกมที่วางจำหน่ายทั่วไป; ตัวทับไม่ไปยุ่งกับมัน
• ไม่ต้องใช้คีย์ AES สำหรับผลลัพธ์ ตัวทับถูกเขียนแบบไม่เข้ารหัสและไม่บีบอัด คีย์เคยจำเป็นแค่ตอน อ่าน ของเดิมเท่านั้น
• ไม่ต้องแพ็กเกมใหม่ อาร์ไคฟ์หลักไม่ถูกแตะ การติดตั้งขนาด 60 GB ก็ยังเป็น 60 GB; คำแปลของคุณคือไฟล์ที่วัดกันเป็นกิโลไบต์
• ใช้ได้กับเกม IoStore ด้วย .locres ถูกอ่านผ่านระบบไฟล์ pak ไม่ใช่ผ่านตัวโหลดแพ็กเกจ Zen ดังนั้น _P.pak แบบหลวมธรรมดาก็ถูกหยิบไปใช้ แม้ในเกม UE5 ที่แอสเซ็ตทั้งหมดอยู่ใน .utoc/.ucas

คุณติดตั้งมันด้วยการคัดลอก _P.pak ที่ได้ไปไว้ใน <Game>/Content/Paks/ — โฟลเดอร์เดียวกับที่ของเดิมอยู่ บางเกมยังเมานต์โฟลเดอร์ย่อย ~mods/ ด้วย ซึ่งก็ใช้ได้ดีเท่ากัน การเอาคำแปลออกคือการลบไฟล์นั้นไฟล์เดียว ทำให้ย้อนกลับได้ง่ายมากและทำให้ทดสอบแต่เนิ่น ๆ ได้อย่างปลอดภัย

ขั้นตอน

1. ติดตั้ง RuneTranslate จาก หน้าดาวน์โหลด แล้วลงชื่อเข้าใช้ ต้องลงชื่อเข้าใช้ด้วย Patreon ฟรีในการเปิดครั้งแรก; ระดับฟรีปลดล็อกทุกเอนจินและทุกผู้ให้บริการ — มันจำกัดปริมาณงานต่อเวลาและเก็บได้ครั้งละหนึ่งโปรเจกต์
2. สร้างโปรเจกต์ใหม่แล้วชี้ไปที่ โฟลเดอร์รากของเกม — โฟลเดอร์ที่มีไฟล์ปฏิบัติการและไดเรกทอรี <Game> การตรวจจับมองหา Content/Paks กับค่ามหัศจรรย์ในส่วนท้ายของ pak หรือมองหา .utoc/.ucas
3. หากอาร์ไคฟ์ถูกเข้ารหัส ปล่อยให้การกู้คืนคีย์ทำงาน มันสแกนไบนารีที่วางจำหน่ายและตรวจสอบตัวเลือกแต่ละตัวกับแฮชดัชนีของ pak เอง หากหาไม่เจอ ให้วางคีย์ลงในกล่องโต้ตอบ
4. ปล่อยให้การดึงข้อความทำงานจนจบ คุณจะได้รายการ .locres ของวัฒนธรรมต้นทาง จัดกลุ่มตามเป้าหมายการแปลภาษา พร้อมให้ตรวจทาน
5. เลือกผู้ให้บริการแล้วแปล สตริง UI สั้น ๆ กับบทสนทนายาว ๆ ส่งไปหาผู้ให้บริการคนละรายได้ หากคุณอยากจ่ายเงินเฉพาะตรงที่มันสำคัญ
6. ตรวจทานสิ่งที่กลับมา สตริงเมนูคือจุดที่การแปลด้วยเครื่องอ่อนที่สุด — คำว่า Save หรือ Load โดด ๆ ไม่มีบริบท และปุ่มสองคำที่กลับมาเป็นประโยคจะล้นวิดเจ็ตของมัน
7. ส่งออก RuneTranslate เขียนไฟล์ _P.pak แบบไม่เข้ารหัสไฟล์เดียว ที่มี .locres ที่คุณแก้ไขอยู่ในพาธซึ่งสัมพัทธ์กับเอนจินอย่างถูกต้อง
8. คัดลอกไฟล์นั้นไปไว้ใน <Game>/Content/Paks/ แล้วเปิดเกม

ทดสอบหลังขั้นที่ 8 โดยแปลไว้แค่ไม่กี่สตริงก่อนที่จะส่งทั้งเกมผ่านผู้ให้บริการ หากตัวทับจะถูกเมิน — ผิดโฟลเดอร์ ผิดวัฒนธรรม หรือการเมานต์ผิดปกติ — คุณอยากรู้ภายในห้านาที ไม่ใช่หลังจากจ่ายค่าแปลไปแล้ว 9,000 สตริง

ตัวยึดตำแหน่งและ rich text

การจัดรูปแบบ FText ของ Unreal ใช้ {0}, {1} สำหรับอาร์กิวเมนต์ตามตำแหน่ง และ {PlayerName}, {Count} สำหรับแบบมีชื่อ บวกกับมาร์กอัป <RichText> ที่มีตัวปิด </> สำหรับการจัดสไตล์แบบอินไลน์ หากผู้ให้บริการแปลทำตัวใดตัวหนึ่งหายหรือทำมันเสีย เกมจะไม่ได้แสดงประโยคที่ผิดนิดหน่อย — มันแสดงสตริงรูปแบบที่พัง หรืออาร์กิวเมนต์หายไปจากบรรทัดนั้นเงียบ ๆ

RuneTranslate ปิดบังทุกตัวเป็นตัวยึดตำแหน่งกลาง ๆ ก่อนที่ผู้ให้บริการจะเห็นสตริง แล้วคืนกลับหลังจากนั้น ผู้ให้บริการแปลรอบ ๆ ตัวมาร์กเกอร์แทนที่จะแปลทะลุมันไป อาร์กิวเมนต์จึงถูกลบโดยโมเดลที่ตัดสินว่าปีกกาหน้าตาเหมือนคำพิมพ์ผิดไม่ได้ หากคุณอยากไปไกลกว่านั้นและกันบางสตริงไม่ให้ถูกแปลเลย ตัวกรองยกเว้นด้วย regex ใช้ได้กับทุกเอนจิน และ อภิธานศัพท์ ทำให้คำนามเฉพาะคงที่ทั้งเกม

กับดักอักษรมีเครื่องหมายกำกับ ซึ่งเป็นบั๊กการเข้ารหัส ไม่ใช่เรื่องฟอนต์

เรื่องนี้ควรบันทึกไว้ต่างหาก เพราะอาการชี้ไปผิดทางพอดี Unreal ซีเรียลไลซ์สตริงพร้อมคำนำหน้าความยาว: ความยาวเป็นบวกหมายถึงหนึ่งไบต์ต่อหนึ่งอักขระ ความยาวเป็นลบหมายถึง UTF-16 เอนจินเลือกรูปแบบแคบเฉพาะเมื่อ ทุกอักขระเป็น ASCII 7 บิต — การตรวจสอบของมันปฏิเสธทุกอย่างที่เกิน 0x7F ตัวโหลดของมันก็ถูกสร้างมาแบบเดียวกัน ดังนั้นหากถูกยื่นสตริงแบบแคบที่มีไบต์สูงอยู่ข้างใน มันจะแทนที่แต่ละตัวด้วย ? ตรง ๆ

ผลในทางปฏิบัติ: คำแปลที่มี poción mágica เขียนในรูปแบบแคบจะไปถึงผู้เล่นเป็น poci?n m?gica และช่วงที่ได้รับผลกระทบคือ U+0080–U+00FF ซึ่งพอดีกับอักษรมีเครื่องหมายกำกับของภาษาสเปน ฝรั่งเศส เยอรมัน โปรตุเกส อิตาลี และภาษากลุ่มนอร์ดิก ส่วนโปแลนด์ ตุรกี เช็ก กรีก ซีริลลิก ญี่ปุ่น และจีน ล้วนอยู่เหนือ U+00FF ไปใช้สาขาแบบกว้างโดยอัตโนมัติ และไม่เคยได้รับผลกระทบ

ลายนิ้วมือของอาการจึงเป็น: อักษรมีเครื่องหมายกำกับพังในภาษาสเปน แต่ภาษารัสเซียปกติดี หากคุณเห็นแบบนั้น มันคือบั๊กการเข้ารหัสในอะไรก็ตามที่เขียนไฟล์นั้น ไม่ใช่ตัวอักษรที่หายไปจากฟอนต์ของเกม — ตัวอักษรที่ฟอนต์ไม่มีจะแสดงเป็นสี่เหลี่ยมหรือไม่แสดงอะไรเลย ไม่เคยแสดงเป็นเครื่องหมายคำถาม RuneTranslate เคยมีบั๊กนี้เป๊ะ ๆ และแก้ไปแล้วใน 0.49.4; ตัวเข้ารหัสตอนนี้อยู่ที่เดียวและเขียนรูปแบบกว้างสำหรับทุกอย่างที่อยู่นอก ASCII เรื่องนี้ควรรู้ไว้เพราะเครื่องมืออื่นในวงการนี้ยังทำผิดอยู่

การเลือกผู้ให้บริการ

สามในเก้าผู้ให้บริการไม่ต้องใช้คีย์ API เลย — Google, DeepL ฟรี และโมเดล Classic/Next-gen ของ DeepL — และระดับฟรีให้คุณครบทั้งสาม สำหรับเกมที่เป็น UI เสียส่วนใหญ่ ผู้ให้บริการฟรีก็เพียงพอจริง ๆ สำหรับเกมที่บทสนทนาเยอะ ผู้ให้บริการแบบ LLM จัดการบริบทได้ดีกว่ามาก; OpenAI, Anthropic, DeepSeek, เอนด์พอยต์ใดก็ตามที่เข้ากันได้กับ OpenAI และโมเดลบนเครื่องผ่าน Ollama หรือ LM Studio มีให้ใช้ทั้งหมด การเปรียบเทียบผู้ให้บริการ ไล่ดูว่าแต่ละตัวเก่งและไม่เก่งอะไร พร้อมตัวเลขค่าใช้จ่ายจริง

การแก้ปัญหา

เกมรันได้แต่ไม่มีอะไรถูกแปล

เกือบทุกครั้งเป็นหนึ่งในสามอย่าง ไฟล์ไม่ได้อยู่ใน <Game>/Content/Paks/ — วางไว้ข้างไฟล์ปฏิบัติการนั้นไม่เกิดอะไรขึ้น ชื่อไฟล์เสียส่วนต่อท้าย _P ไป ซึ่งทำให้มันเมานต์ตามลำดับตัวอักษรปกติ และ pak หลักอาจชนะ หรือเกมกำลังรันในวัฒนธรรมที่คุณไม่ได้แปล: มันโหลด .locres ของวัฒนธรรมที่มันตัดสินได้ตอนเริ่มโปรแกรม เกมที่บังคับ en จึงเมินตัวทับที่เขียนไว้สำหรับ ja อย่างเดียว เช็คการตั้งค่าภาษาของเกมก่อน

การดึงข้อความล้มเหลวบน pak แบบหลวมที่บีบอัดด้วย Oodle

.pak แบบหลวมที่บีบอัดด้วย Oodle ต้องใช้ตัวคลายบีบอัดที่รวมมาด้วยไม่ได้ หากเกมส่งคอนเทนเนอร์ IoStore มาด้วย เส้นทาง retoc จะจัดการ Oodle ให้และคุณก็ไม่มีปัญหา หากมีแต่ pak แบบหลวมอย่างเดียว ตอนนี้ถือเป็นทางตัน และถูกรายงานอย่างชัดเจนแทนที่จะให้ผลลัพธ์ว่างเปล่าแบบเงียบ ๆ

เกมไม่มี .locres อยู่ที่ไหนเลย

แปลว่าข้อความของมันถูกคอมไพล์อยู่ในแอสเซ็ตที่ cook แล้ว และเส้นทางนี้ไปไม่ถึง ตัวอย่างที่ชัดที่สุดคือเกม UE5 แบบ live-service ขนาดใหญ่ที่ดัชนี IoStore ถูกลดเหลือแฮชของเนื้อหาโดยไม่มีชื่อไฟล์เลย — ชิ้นส่วนหลายแสนชิ้นและ .locres ศูนย์ไฟล์ RuneTranslate บอกตรง ๆ แทนที่จะไล่บดคอนเทนเนอร์ทั้งชุด

การตรวจจับไม่ทำงานเลย

ชี้ไปที่โฟลเดอร์ที่มีไฟล์ปฏิบัติการ ไม่ใช่ที่ Content/Paks เอง และไม่ใช่โฟลเดอร์แม่ที่เต็มไปด้วยเกมอื่น หากยังตรวจจับไม่ได้ แสดงว่าการแพ็กนั้นผิดปกติและควรแจ้งเรามา — รูปแบบ pak มีเลย์เอาต์ส่วนท้ายที่ต่างกันตามเวอร์ชัน และภาษาถิ่นที่ยังไม่มีใครเคยเห็นคือสิ่งที่มักถูกเพิ่มเข้ามาพอดี

ข้อจำกัดตามจริง

การรองรับ Unreal เป็นแบบพยายามอย่างเต็มที่ .locres ที่อยู่ใน pak แบบหลวมและแบบเข้ารหัส และที่อยู่ใน UE5 IoStore คือเส้นทางที่พิสูจน์แล้ว ยืนยันแล้วว่าเล่นได้จริงในเกมบนเกม UE4 ภาษาสเปน ข้อความใน DataTable และใน .uasset ที่ cook แล้วไม่ครอบคลุม pak แบบหลวมที่บีบอัดด้วย Oodle โดยไม่มี IoStore คู่กันไม่รองรับ pak ที่บังคับใช้การเซ็นไม่สามารถทับได้ แม้จะพบได้ยากในทางปฏิบัติ และเพราะรูปแบบไฟล์ต่างกันมากระหว่างเวอร์ชันเอนจินและระหว่างสตูดิโอ ให้ถือว่างานส่งออกครั้งแรกเป็นการทดสอบ ไม่ใช่ผลงานที่ส่งมอบ

สิ่งที่คุณได้ในตอนท้ายคือบิลด์ที่แปลแล้วและเล่นได้ ซึ่งคุณเก็บไว้บนเครื่องของตัวเอง: เกมต้นฉบับไม่ถูกแตะต้อง บวกไฟล์เล็ก ๆ หนึ่งไฟล์ที่คุณลบทิ้งเพื่อย้อนทุกอย่างกลับได้ หากคุณกำลังเทียบเอนจินหรือเช็คว่าเกมของคุณถูกครอบคลุมหรือไม่ หน้าเอนจิน Unreal มีรายละเอียดทางเทคนิค และ เอนจินทั้งหมด แสดงรูปแบบที่รองรับทั้งสิบเจ็ด รวมถึง Unity และ RPG Maker หากคุณเพิ่งเริ่มกระบวนการนี้ เริ่มที่ คู่มือทั่วไป แล้วกลับมาที่นี่สำหรับส่วนที่เจาะจง Unreal