-
Notifications
You must be signed in to change notification settings - Fork 421
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
Refactor resource loader internals #3473
Refactor resource loader internals #3473
Conversation
...der-v0/src/client/java/net/fabricmc/fabric/mixin/resource/loader/client/PackScreenMixin.java
Outdated
Show resolved
Hide resolved
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.
Not an in-depth review yet, but I've noticed that the misleading ResourcePack#getName()
Yarn name still hasn't been fixed (partly my fault, I forgot to create an issue).
I'd rename the corresponding fields and translation keys accordingly to avoid confusion later down the line. Also pinging @PepperCode1 to check if Continuity has any special requirements regarding the format
...ce-loader-v0/src/main/java/net/fabricmc/fabric/impl/resource/loader/ModResourcePackUtil.java
Show resolved
Hide resolved
Marked ready for review. Will need some testing. |
Test successful, but will need more checks on mod compatibility, ResourceManagerHelper pack interactions, etc. |
TODO:
|
|
||
@SuppressWarnings("unchecked") | ||
@ModifyArg(method = "visitObject", at = @At(value = "INVOKE", target = "Ljava/util/function/Function;apply(Ljava/lang/Object;)Ljava/lang/Object;")) | ||
private <T> T skipHiddenPacks(T value, @Local String key) { |
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.
Injecting here is much easier than maintaining the ordinals among the visitObject
calls in accept
.
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.
Looks good, nothing major is standing out to me. The main thing with this is going to be testing, to A) make sure it works as expected, and B) make sure its not slower anywhere.
Ensuing that the test mod fully utilises the features, and documents how to test it works correctly would go a long way. Im very happy to help with this if needed.
...der-v0/src/main/java/net/fabricmc/fabric/mixin/resource/loader/ResourcePackManagerMixin.java
Outdated
Show resolved
Hide resolved
...oader-v0/src/main/java/net/fabricmc/fabric/impl/resource/loader/PlaceholderResourcePack.java
Outdated
Show resolved
Hide resolved
...ce-loader-v0/src/main/java/net/fabricmc/fabric/impl/resource/loader/ModResourcePackUtil.java
Outdated
Show resolved
Hide resolved
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.
Looks good, what kind of testing has been done on this? There is quite a bit of room for things to go wrong so want to be 100% sure that we are confident with it.
Im happy to move it to last call.
...der-v0/src/main/java/net/fabricmc/fabric/impl/resource/loader/FabricResourcePackProfile.java
Outdated
Show resolved
Hide resolved
...ce-loader-v0/src/main/java/net/fabricmc/fabric/impl/resource/loader/ModResourcePackUtil.java
Outdated
Show resolved
Hide resolved
allProfiles.putAll(modAProfiles); | ||
allProfiles.putAll(modBProfiles); | ||
|
||
testRefreshAutoEnabledPacks( |
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.
Nit: You would usually have a test method for each of these, not the end of the world but would make it more clear if just one of these tests broke.
Happy to leave this be.
* First step toward fixing resource pack grouping * Placeholder pack and pack dependency * Various fixes * Fix wrong variable in serialization code * Hide packs in PackScreen and DatapackCommand * Apparently Japanese people aren't alone in having their currency signs used as special chars... * Inject directly to Pack * Add temporary logging, fix bug * Add proper sorting * Improve logging * Fix duplicate name registration * Fix client pack handling * Fix FMJ * Stop using interface injection for internal interface * Delete unused GroupResourcePack * Move refreshAutoEnabledPacks to util * Improve logging * Make a few things private * Use vanilla metadata serialization logic * Improve javadoc * Add junit test * Some final refactors * Update ja_jp.json --------- Co-authored-by: modmuss <[email protected]> (cherry picked from commit 707e4d1)
Thank you so much for working on this! I am excited to test it out, and be able to easily create updates for Fabric again. |
This has caused breakages in Sodium, because the high contrast/programmer art packs for mods are given the same resource pack name, which it expects to not be possible. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@jellysquid3 Uhh, my test environment did have Sodium 0.5.5, and I did not encounter any errors while booting up or using High Contrast. It could be due to changes in 0.5.6+, I am honestly unsure.
Each
The change should have removed any "internal" packs from |
We made a change very shortly before Fabric API 0.95.3 was published (a few days ago) that put the resource scan results into a hash table, which doesn't tolerate duplicate keys. It was just really bad luck, and we have since fixed the code to be more tolerant of that case.
This may have since been fixed. Another user reported it to us with Fabric API 0.95.3, but will see if I can reproduce it myself. |
This happens when "Resource Pack Overrides" is present. |
Resolves #3302
Supersedes #3312
Likely the biggest refactor to Resource Loader since its inception??? Work ongoing.
Note, if you've been using FAPI resource pack internals, this might break it (as expected).