Opened 11 months ago

Closed 8 months ago

#14482 closed defect (fixed)

TLJ: Texture mods with unusual names not loading

Reported by: gordonfreeman01 Owned by: gordonfreeman01
Priority: normal Component: Engine: Stark
Version: Keywords:
Cc: Game: The Longest Journey

Description (last modified by gordonfreeman01)

The HD Characters mod (https://www.moddb.com/mods/hd-characters) - not to be confused with the HD mod - has a non-functional texture replacement for Emma which seems to be because it has a Cyrillic name. The name is emma.tm.zip\puppær.dds (see the paragraph with an asterisk on top of the linked mod for how to load the file) and in-game the texture does not load. Looks like a texture loading problem as others work fine.

Attachments (4)

tlj-win-006.tlj (72.8 KB ) - added by gordonfreeman01 11 months ago.
C_scummvm-tlj-win-00001.jpg (263.1 KB ) - added by gordonfreeman01 11 months ago.
BugLine.jpg (1.0 MB ) - added by gordonfreeman01 9 months ago.
image-20230809-023002.png (650.3 KB ) - added by gordonfreeman01 9 months ago.

Download all attachments as: .zip

Change History (11)

by gordonfreeman01, 11 months ago

Attachment: tlj-win-006.tlj added

by gordonfreeman01, 11 months ago

Attachment: C_scummvm-tlj-win-00001.jpg added

comment:1 by gordonfreeman01, 11 months ago

Description: modified (diff)

comment:2 by gordonfreeman01, 9 months ago

Based on my analysis so far, it looks like when the common ScummVM unzip code is being called to extract a texture with special characters (in this case "puppær.dds"), the special character is being incorrectly set in the texture's name variable, leading to issues for debugging (Visual Studio shows "invalid characters in path" instead of the value) and the game itself (the texture renders as blank). When attempting to force the correct character via debugger during load within the stark engine, it renders correctly though so this seems like a bug with the unzip function specifically as the variable can store the value correctly. Here's how the filename shows up in the debug log when attempting to write its loaded name (special character at the 5th position in the name does not show up correctly when rendered in browser):
Attempting to load texture pupp‘r.dds

I've narrowed it down to to what seems like the exact line causing the bug, it is definitely in the common unzip function, here the correct value cannot be stored but once it is returned to the engine it can so seems like there is a restriction on the ZipHash. If anyone has experience with the unzip function and knows more about how this works it would be helpful to find a fix.


Last edited 9 months ago by gordonfreeman01 (previous) (diff)

by gordonfreeman01, 9 months ago

Attachment: BugLine.jpg added

by gordonfreeman01, 9 months ago

Attachment: image-20230809-023002.png added

comment:3 by gordonfreeman01, 9 months ago

Turns out I was wrong earlier, the code reading the bytes for the filename from the zip file (line 656 below) is returning the wrong value for the special character and figuring out why (should be a standard function) is proving a challenge given my limited understanding of how ScummVM uses stream reader functions:

comment:4 by gordonfreeman01, 9 months ago

Owner: set to gordonfreeman01
Resolution: assigned
Status: newpending

comment:5 by gordonfreeman01, 9 months ago

Resolution: assignedfixed

comment:6 by gordonfreeman01, 9 months ago

Resolution: fixedassigned

comment:7 by bluegr, 8 months ago

Resolution: assignedfixed
Status: pendingclosed

The PR for this has been merged. Thanks for your work!

Note: See TracTickets for help on using tickets.