[Possible Bug]: When the asset name conflicts, exported `png` and `asset` doesn't match about assetripper

[ds5678]

I am not sure if the linking of stand_0.asset <> stand.png is expected or not.

The fact that your method worked is mostly due to the popularity of png textures. If the developer had decided to use a different image format, the catalog path would have used that extension whereas AssetRipper would have still used png.

If it works, then I'll just close this issue. Does it work for you?

Sounds good. Nothing here sounds like an actual bug.

[github-actions]

Thank you for submitting your first issue here. Please be sure you have uploaded your AssetRipper.log file. It is in the same folder as the exe file. :)

[ds5678]

I had to read it several times, but I think I understand what you're saying:

• You exported the project with AssetRipper.
• You analyzed an addressable catalog with separate tooling and found a hash paired with a path.
• You looked at yaml sprites in the ripped project and noticed that the render data key matched your hash.
• You looked for a texture at the path cooresponding to the hash.
• Apparently, there were two textures with that path, so only one of them had that exact path when exported.
• Finding the wrong texture caused problems for your use case.

[RaenonX]

I had to read it several times, but I think I understand what you're saying:

• You exported the project with AssetRipper.
• You analyzed an addressable catalog with separate tooling and found a hash paired with a path.
• You looked at yaml sprites in the ripped project and noticed that the render data key matched your hash.
• You looked for a texture at the path cooresponding to the hash.
• Apparently, there were two textures with that path, so only one of them had that exact path when exported.
• Finding the wrong texture caused problems for your use case.

Sorry if this seems complicated, I tried my best to simplify it 😆

Changed some texts and annotated them using [] to ensure clarity.

• You looked at yaml sprites in the ripped project and noticed that [there is a] render data key match[ing my] hash.
• You looked for a texture at the path cooresponding to the hash. [The texture I am looking for could be either stand.png or stand_0.png, which, I can only try to locate them using the sprite file name that contains my hash.]

Since my current way of locating the image might be either bugged or just unreliable, the texture I located is the incorrect one.
This is the current logic:

• Hash found in render data key in stand_0.asset
• Find stand_0.png and export it (stand.png is actually the one I am looking for)

[ds5678]

What's the purpose of all this?

[RaenonX]

What's the purpose of all this?

On top of the ultimate goal listed in the first comment, I am grabbing all spine-related files, precisely files of *.atlas *.png *.skel to render the animation of them on my website.

The live example is here https://pks.raenonx.cc/en/pokedex/155. You'll see that when clicking on "Moving" and "Standing," the color of the Pokemon changes while it should not, unless "shiny" changes.

Other actions in the link I attached also have the same issue. If you click on other actions, you'll notice that the color of the Pokemon keeps changing.

[ds5678]

My ultimate goal is given the hash of a13dd613cc0094077b4e9cacc8af5eba, I can locate the following image in any way.

This is not a goal. https://en.wikipedia.org/wiki/XY_problem

[ds5678]

Why didn't you just use the guid?

[RaenonX]

My ultimate goal is given the hash of a13dd613cc0094077b4e9cacc8af5eba, I can locate the following image in any way.

This is not a goal. https://en.wikipedia.org/wiki/XY_problem

If you mean what exactly I am looking for is unclear, because I don't have enough knowledge about how it works under the hood, anyway you think it's feasible to help linking the hash to the image works. The reason why I mark it as "possible bug" is also because that I am not sure if the linking of stand_0.asset <> stand.png is expected or not.

Why didn't you just use the guid?

I actually missed this part. Just checked as you commented. If you mean m_RD.texture.<HASH> to link them, I think it actually does the trick. Thanks for bringing this up!

---

I'll try using guid to locate the image and see if it works. If it works, then I'll just close this issue. Does it work for you? Thanks for bringing it up in advance.

[RaenonX]

Using guid seems to be working, agree that nothing is a bug here. Thanks for pointing out guid usage!

Couldn't believe that I knew #1294 improved GUID behavior and I used that for *.skel and *.atlas without realizing that png could go with the same route.