search

EnderTurret / PatchedMod

A Minecraft mod that adds the ability for data/resource packs and mods to patch JSON files, allowing them to avoid the incompatibility of replacing files wholesale.
GNU Lesser General Public License v2.1
2 stars 0 forks source link

[Fabric] `list patches` doesn't work on built-in packs #9

Closed Estecka closed 1 year ago

Estecka commented 1 year ago

Hi,

I wanted to move my loot tables into a built-in datapack, so the user could disable them using the /datapack command. I.e, my datas are no longer inside Fabric's global datapack, but are registered using ResourceManagerHelper::registerBuiltinResourcePack.

Using /patched list packs shows that Patched properly acknowledges the pack, but /patched list patches says it contains no patches. If I copy the datapack into the world's directory, with no other changes, the patches in the copy are properly listed.

This only affects the output of the commands. Patches appear to be properly applied despite being not listed.

Here's the setup I used to test this https://github.com/Estecka/mc-invariable-paintings/commit/962f2d86673b5bdb021d2354cfa12086f8bbc508

Versions:

EnderTurret commented 1 year ago

I'm currently still in the process of figuring out exactly what's going on, but my working theory is that Fabric is placing a ModNioResourcePack after your mod's existing one. Patched currently assigns all ModNioResourcePacks the name mod/<mod id>, where mod id is the id of the owning mod. Since both of the packs are owned by your mod, both of them get the same name. This means that Patched can pick up on your second one when looking at all of them, but chooses the first one when asked to find one by name. Then it complains that your mod's main pack doesn't have patching enabled. (I expect that if you enabled it on your mod's main pack it'd instead say "there are 0 patches in mod/Invariable Paintings".)

EDIT: This is indeed the problem.

If this is the case, I'll need to find a way to give the packs unique names (which means more adventures into Fabric internals, I expect), and I'll also add some debug stuff in case this sort of thing happens again. (I'm not especially excited for the Quilt side of things, where mod resource packs aren't even considered public API.)

EnderTurret commented 1 year ago

I've fixed this issue in the latest build (in this commit) which I've just uploaded to Modrinth and CurseForge. It should be available within the next 30 minutes.

Estecka commented 1 year ago

(I expect that if you enabled it on your mod's main pack it'd instead say "there are 0 patches in mod/Invariable Paintings".)

It already says that, whether I leave the main pack.mcmeta or not. Patched never actually complained about disabled patching, at least not in those words.

Patched 3.2.1 does indeed lists the main pack and all built-in packs as "mod/Invariable Paintings", and will list the patches of the main pack if it contains some.

That being said I still had version 1.0.2 of the mod installed when I first noticed the issue. In this version, Patched lists the packs using the correct name. (The main pack is then listed as "Fabric Mods" as expected). This version will correctly list the patches for the main pack, but still lists 0 patches for the secondary packs, even if the main one contains some.

Edit: Ah, didn't see you just fixed it.