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

Implement built-in mod resource pack sorting #3913

Closed

Conversation

Apollounknowndev
Copy link
Contributor

Overriding data/resource pack files from other mods is currently quite difficult as mod loading order isn't consistent. This can be especially annoying for compatibility mods that exist to override data/resource files from other mods.

This PR addresses the issue by implementing a system for mods to define in their fabric.mod.json what their priority is in the internal Fabric Mods data/resource pack. There are five phases, with each occuring in a deterministic order (intra-phase sorting isn't guaranteed). These phases are currently bottom, lower, default, upper, and top but can be changed if there is a better naming convention.

Mods that wish to change their priority in the load order can add this to their fabric.mod.json file:

"custom": {
    "fabric:resource_load_order": {
        "data": "fabric:lower",
        "assets": "fabric:default"
    }
}

@OroArmor
Copy link

OroArmor commented Jul 6, 2024

This should be on the pack.mcmeta file. There is no reason to restrict this to the whole mod container.

@Apollounknowndev
Copy link
Contributor Author

Apollounknowndev commented Jul 6, 2024

This should be on the pack.mcmeta file. There is no reason to restrict this to the whole mod container.

Why, exactly? This is just for ordering inside of the Fabric Mods data/resource pack. Other packs cannot be put somewhere inside the ordering of the Fabric Mods data/resource pack.

@modmuss50
Copy link
Member

This is a great start, but I think we need to come up with a concreate plan for what we want. I see a few problems with the current approach of only allowing entire mods to be lower or higher. I think this is going to cause issues where mods just put them selves higher for the sake of it, just moving the problem elsewhere. Being able to specify their relation with specific mod ids might be a better solution? e.g higher than modx.

I agree it does seem strange to have this in the fmj, although im not going to outright dismiss it. If it was in the packmc.meta could it allow sorting builtin packs diffrently? The meta file already contains the conditions, it seems like a logicial place to put this. The split between the assets and data feels a little strange to me as well.

modmuss50 and others added 14 commits August 7, 2024 16:54
* Add an API to add additional supported blocks to block entity types. (FabricMC#4009)

(cherry picked from commit 40875a9)

* Bump version

* Add chorus fruit to 1c:foods/fruit` tag

---------

Co-authored-by: modmuss <modmuss50@gmail.com>
* Crafter support for the transfer api.
Closes FabricMC#4004

* Review feedback
* Add #c:nuggets/iron and #c:nuggets/gold

Closes FabricMC#4005.

* Add crop item tags

Everything but c:crops/cocoa_bean is already in NeoForge.

* Add more crop tags and documentation for #c:crops
* New translations en_us.json (Chinese Simplified)

* New translations en_us.json (German)

* New translations en_us.json (Italian)
This reverts commit 1ad5d52, reversing
changes made to 1c2cd59.
@Apollounknowndev
Copy link
Contributor Author

Screwed up some Github thing, creating fresh PR to fix it.

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

Successfully merging this pull request may close these issues.

None yet

6 participants