mirror of
https://github.com/open-goal/jak-project
synced 2026-05-24 07:11:15 -04:00
Matt Dallmeyer
56d495bc9f
I discovered that `yakow`s are kinda broken if you try to use them in custom levels in jak 2/3. It's due to the missing `yakow-lod0` texture and associated fix, replacing it with `yak-medfur-end`. This solution works fine for the decompiler on vanilla levels. But for building custom levels, the requested art-groups were being handled before the textures were, and so it was impossible to have `yak-medfur-end` on hand to do the replacement. You'd hit an exception here because `idx_in_level_texture` would still be `INT32_MAX`: https://github.com/open-goal/jak-project/blob/c08118509b84feba002bd9e208f49162b4218556/decompiler/level_extractor/extract_merc.cpp#L806 My fix was just to swap the order when building custom levels, and handle the textures first. I only made the changes for jak2/3, because I see @Hat-Kid has a slightly different implementation for jak1. There's one other small change relating to the `combo_id` / `pc_combo_tex_id` short-circtuiting - I think `pc_combo_tex_id` is always 0 for vanilla textures? So initially `yakow-lod0` actually ended up matching the `combo_id` of the checkerboard texture from the test-zone GLB. I just added another sanity check here that the texture names match too. (I also added yakows in the test-zone.jsonc files 🐄)