client: hardcoded pack/property.pck path bypasses m2p loader #2

New Issue

jann · 2026-04-15T13:00:18+02:00

jann commented

2026-04-15 13:00:18 +02:00

The MinGW client build at build-mingw64-lld/bin/Metin2_RelWithDebInfo.exe has the string pack/property.pck embedded directly. When booting against a release tree that ships only property.m2p (and no .pck), the client reaches the character select screen fine — root/etc/item/etc all load through the m2p loader — but once a character is selected and in-game code tries to open the property pack file, it pops a modal:

LOG: Cannot open property pack file (filename pack/property.pck)

This is the only hardcoded .pck reference in the entire new exe:

strings Metin2_RelWithDebInfo.exe | grep -E 'pack/[a-zA-Z0-9_]+\.pck$'
# pack/property.pck

So every other pack group is loaded through a code path that at least tries .m2p first. property alone bypasses that. Almost certainly a direct fopen(...) or equivalent on a literal path constant somewhere in the resource / world / property loading code.

Reproduction

Start from a release tree with property.m2p only, no property.pck.
Boot client through launcher + runtime key (full Setup: InitializeM2PackRuntimeKeyProvider ok path).
Main: PackInitialize ok passes (generic loader is happy with m2p)
Login screen → character select → pick a character
Modal: Cannot open property pack file (filename pack/property.pck)

Workaround used tonight: ship property.pck alongside property.m2p in the release tree. Size penalty: 10 MB. Also necessitates documenting property as a "dual-format required" pack in the migration doc.

Where to fix

Search m2dev-client-src for the literal pack/property.pck. Likely candidates:

src/UserInterface/ property loading code
src/EterLib/ or src/GameLib/ pack manager bootstrap that loads property manually (outside the normal CPackManager::AddPack path that respects .m2p preference)

The fix is to route that load through the same extension-aware loader that the rest of the client uses. Or, simpler, rename the hardcoded path to pack/property and let the loader resolve the extension.

Migration impact

Per m2pack-secure/docs/migration.md Phase 4 ("package only .m2p for release clients"), property cannot make Phase 4 until this is fixed. All other pack groups that I mass-migrated tonight were in Phase 4 candidates; property alone is held back.

Affected today: 2026.04.15-m2pack-v3 ships both property.m2p and property.pck as a workaround.

metin-server/m2pack-secure docs/migration.md
jann/metin-launcher PR docs: add windows native test runbook (#1)

The MinGW client build at `build-mingw64-lld/bin/Metin2_RelWithDebInfo.exe` has the string `pack/property.pck` embedded directly. When booting against a release tree that ships only `property.m2p` (and no `.pck`), the client reaches the character select screen fine — root/etc/item/etc all load through the m2p loader — but once a character is selected and in-game code tries to open the property pack file, it pops a modal: > LOG: Cannot open property pack file (filename pack/property.pck) This is the **only** hardcoded `.pck` reference in the entire new exe: ```bash strings Metin2_RelWithDebInfo.exe | grep -E 'pack/[a-zA-Z0-9_]+\.pck$' # pack/property.pck ``` So every other pack group is loaded through a code path that at least tries `.m2p` first. `property` alone bypasses that. Almost certainly a direct `fopen(...)` or equivalent on a literal path constant somewhere in the resource / world / property loading code. ## Reproduction 1. Start from a release tree with `property.m2p` only, no `property.pck`. 2. Boot client through launcher + runtime key (full `Setup: InitializeM2PackRuntimeKeyProvider ok` path). 3. `Main: PackInitialize ok` passes (generic loader is happy with m2p) 4. Login screen → character select → pick a character 5. Modal: `Cannot open property pack file (filename pack/property.pck)` Workaround used tonight: ship `property.pck` alongside `property.m2p` in the release tree. Size penalty: 10 MB. Also necessitates documenting `property` as a "dual-format required" pack in the migration doc. ## Where to fix Search `m2dev-client-src` for the literal `pack/property.pck`. Likely candidates: - `src/UserInterface/` property loading code - `src/EterLib/` or `src/GameLib/` pack manager bootstrap that loads property manually (outside the normal `CPackManager::AddPack` path that respects `.m2p` preference) The fix is to route that load through the same extension-aware loader that the rest of the client uses. Or, simpler, rename the hardcoded path to `pack/property` and let the loader resolve the extension. ## Migration impact Per `m2pack-secure/docs/migration.md` Phase 4 ("package only `.m2p` for release clients"), `property` cannot make Phase 4 until this is fixed. All other pack groups that I mass-migrated tonight were in Phase 4 candidates; property alone is held back. Affected today: `2026.04.15-m2pack-v3` ships both `property.m2p` and `property.pck` as a workaround. ## Related - `metin-server/m2pack-secure` `docs/migration.md` - `jann/metin-launcher` PR #1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: metin-server/m2dev-client-src#2