Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thanm fails on th143 bestshot.anm #44

Closed
drakeirving opened this issue Jul 16, 2018 · 3 comments
Closed

thanm fails on th143 bestshot.anm #44

drakeirving opened this issue Jul 16, 2018 · 3 comments
Labels

Comments

@drakeirving
Copy link

I was notified by someone that thanm crashes when trying to extract images from bestshot.anm. Listing the archive spec also fails the same way. After a bit of digging looks like this was known from 9811c4f but I guess I'll throw it out here anyways.

Leaves me wondering what a "best shot" even means here considering th125 doesn't have a file like this and the screenshot images are almost definitely stored in the savedata files. The anm file is also quite small so it couldn't contain much.

@nmlgc
Copy link
Contributor

nmlgc commented Sep 26, 2018

The issue there is that this one ANM breaks the heuristic used to distinguish between pre-TH11 and post-TH11 formats. Due to having a width of 0, all bytes at structure offsets 8-12 (the zero1 and w fields) are zero in this file, leading to it being mistakenly treated as a pre-TH11 file, where rt_textureslot is always zero.

I thought about this for a while, but due to the way the structure fields are laid out, I couldn't come up with anything better that wouldn't break under other circumstances either.

Meanwhile, here's the spec of bestshot.anm. Creating a new ANM from that should work fine, as well as using thcrap's upcoming ANM header patching feature.

@DankRank DankRank added the bug label Mar 22, 2022
@32th-System
Copy link
Member

@muter3000 you have implemented a version selection parameter for th185 (#101), could you extend that feature to fix this?

@DankRank
Copy link
Member

btw that version select thing needs to be reimplemented because I haven't ported it to the new codebase when I merged #86 (which has a workaround for th18 btw 3adc7a9). I'll do that soon™

I'm thinking of actually requiring a version to be specified to avoid problems like this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants