search

HarbourMasters / Shipwright

3.3k stars 494 forks source link

[Bug] Jabu-Jabu stomach hole textures missing #4411

Closed JordanLongstaff closed 1 month ago

JordanLongstaff commented 1 month ago

2024-10-15

Malkierian commented 1 month ago

Assuming you're completely up to date (the PR fixing this was merged 4 days ago) you probably need to regen your oot.otr.

Malkierian commented 1 month ago

Yeah, just confirmed on latest develop with a fresh OTR, this is obsolete.

JordanLongstaff commented 1 month ago

Is this the command? "C:\Program Files\CMake\bin\cmake.exe" --build .\build\x64 -t ExtractAssets Because I tried that. It didn't fix the textures.

I also tried a full clean and rebuild. They're still missing.

And yes, I'm up to date. I'm using the latest version of VS 2022 on Windows.

Archez commented 1 month ago

Did you also make sure to grab the correct submodules after getting latest develop git submodule update --init (and then remake the otr files after that) The fix relies on a recent change with the OTRExporter submodule.

JordanLongstaff commented 1 month ago

Did you also make sure to grab the correct submodules after getting latest develop git submodule update --init (and then remake the otr files after that) The fix relies on a recent change with the OTRExporter submodule.

Just tried it. Didn't fix it.

I always make sure to update the submodules whenever there's a change, but I don't typically use the --init flag. I don't think it made a difference here, though.

Malkierian commented 1 month ago

Soooo.... GC version is fixed, but this is still broken for 1.1, and possibly 1.0, not sure.

Archez commented 1 month ago

I've re-reviewed this and can conclude that pal 1.1 and pal 1.0 are extracting properly via the built-in extractor. Both do not have issues with the matrix in Jabu Jabu.

What I can confirm is that using the N64 roms with the cmake extraction target ExtractAssets is not supported, which is what is making it seem like the issue is still there.

The OTRExporter python scripts only "officially" support extracting the gamecube pal roms, as it has a hardcoded path for the external file calculation to non-mq retail pal. This causes the data for n64 pal roms to be unaligned when we handle the special matrix for jabu.

I'm going to close this issue as the Jabu related part is definitely working for release builds. A separate issue can be made to track deprecating the ExtractAssets target as the recommended way to generate OTRs.

JordanLongstaff commented 1 month ago

So what do you suggest I do? I have the PAL 1.1 ROM and I'm still having this problem.

Patrick12115 commented 1 month ago

Go to x64/Debug/soh.exe and use the oot.otr from it. I believe that should work, may need to delete the existing oot.otr and rerun the exe

Malkierian commented 1 month ago

Until we get the automatic in-game extraction setup for VS, you'll have to 1) download a nightly build and make an OTR with that to copy over, 2) copy the OTRExporter/Extract/assets folder to build/x64/soh folder, delete the oot.otr and run SoH to build with the in-game process that way, or 3) just deal with it as is

Malkierian commented 1 month ago

Scratch that, I forgot that assets were copied to x64 folders. What Pat said should work, yeah.

JordanLongstaff commented 1 month ago

Phew. Finally found a fix. It ended up being quite arduous for me - I had to delete x64/Debug/oot.otr and regenerate it from the ROM, then delete build/x64/soh/oot.otr and copy it back in.

Glad to know it still works for release builds.

Malkierian commented 1 month ago

Just merged the change that will allow builds run through VS to extract using the built-in process, so you should be able to update to latest develop, remake the VS project, and then follow the regular flow for regenerating oot.otr in the future.