-
Notifications
You must be signed in to change notification settings - Fork 73
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
[OoT] Fix latest decomp issues #366
Conversation
(ready to review) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes are not backwards compatible with repos based on decomps before assets moved to extracted/ , right?
As in, if one's mod is based on a decomp revision where assets are in assets/, with these changes fast64 would no longer work in that mod's repo?
well, yes, I thought of that and I figured people should use something up-to-date because of the better documentation and new features in the case of HackerOoT (and actually both since we pull decomp often) I guess it shouldn't be that hard to make it backward compatible as the extracted path comes from a function :peepoShrug: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nits, otherwise looks okay. Also I hope you've tested this well.
subfolder = ( | ||
context.scene.fast64.oot.get_extracted_path() + "assets/scenes/" + settings.subFolder + "/" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change to the f-string approach shown in the next change below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a bit weird to use f-strings with the function as the value returned ends with /
though it's fine for now, I think we should use pathlib more in general anyway so it can be addressed in a general cleanup (though I'll f-string the other parts)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed the slash oddities but I didn't use f-strings eveywhere because of the line length limitation of the formatter
fast64_internal/oot/scene/panels.py
Outdated
context.scene.ootDecompPath | ||
+ context.scene.fast64.oot.get_extracted_path() | ||
+ f"assets/scenes/{removeSettings.subFolder}/{removeSettings.name}/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More adds + f-strings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this one doesn't fit on one line
I tested again with HackerOoT (where I can experiment easier between before and after), everything works for me |
decomp has a PR that lets you use the older asset system for mods, idk if this version change is really necessary now, I need to think about it |
Checklist:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works: 👏
- importing skeletons
- importing Link (child/adult)
- importing scenes (with or without cutscenes)
- exporting scenes
- importing non-link animations
- importing link animations: probably works but this branch lacks the import link anims fix (merge main)
Doesn't work: 📉
- exporting skeletons
- exporting Link (child/adult)
I pushed a workaround for allowing exporting skeletons/Link I call it a workaround and not a fix because I'm not super sure the behavior is ideal, but at least it can work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this PR addresses the numerous problems posed by the evolving assets system in the best way, but at least it works enough to be usable. Better than nothing!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
glanced briefly at the code but did not review it with any scrutiny, however tested this locally and everything i tested seemed to work.
Currently importing mesh doesn't work and I didn't look into it yet