-
Notifications
You must be signed in to change notification settings - Fork 26
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
FPackageIndex::get_package for index>0 ? #10
Comments
I was trying to parse a few assets where a positive index almost always referred to either the wrong thing, or just was out of bounds and returned null. I realised my previous parser was making a mistake in this respect. As far as I can tell, positive indices refer to exports (i.e. assets in the same file.) After parsing a few files using this method, particularly with entity location maps, it seemed to confirm that this was the case. It also explains how different exports are related to each other. I've always tried to make sure that the data that the parser outputs is as representative of the underlying asset as possible, so the parser will output an array when it comes across a valid import, with each item in the array referring to the object_name of the import tree (where one import refers to another.) This has ended up meaning that you're able to get the full file path from an FPackageIndex when relevant. |
Very interesting, thank you for the detailed answer. I will run more tests on my side. |
Not only your answer solved an issue I had with the value being strange (=wrong), but I can also know which specific export is the target and create links. Thank you again for your help, you can close this issue. |
JohnWickParse/src/assets.rs
Line 521 in 74dc082
In my experience if index>0 it should still return import_map.get(index - 1)
My own parser works that way and your commit history also shows it was working like that in the past.. Is that an oversight? If not could you explain why the change?
Thanks.
The text was updated successfully, but these errors were encountered: