quat1024 / packages

Worse Barrels 2: Electric Boogaloo. Now for Fabric. Now also for not Fabric?

Packages

Worse Barrels successor for Fabric Fabric and also Forge 1.15.2 1.16.4 1.17.0 1.17.1 1.18 1.18.2 1.19.2 1.19.4 1.20.1.

Package Crafter model by Kat.

Quick note about model handling

The xplat set contains packages:block/package and packages:block/package_maker. These models use the "special" textures packages:package_special/frame and packages:package_special/inner to mark which quads should be retextured, and as such these models are not expected to be displayed as-is to players. The xplat set also points the Package and Package Crafter's blockstates at the models packages:special/package and packages:special/package_maker (with special instead of block) respectively. Implemetations of the special model load the corresponding block model and perform the retexturing at runtime.

On Fabric, there is a ModelLoadingRegistry API. Resource providers hook requests for specific files, and variant providers hook requests for specific ModelResourceLocations. Requests for special/package and item/package#inventory are diverted to the appropriate dynamic model.

On Forge, there is a RegisterGeometryLoaders API. I register a geometry loader for the package/packagemaker models and ship model JSONs with the loader field set, which causes Forge to load the appropriate dynamic model.

License

LGPL-3.0-or-later

packages's Issues

Texture issues in 1.16.3

So, TECHNICALLY this isn't out for 1.16.3, but it does run; and when it does...packages render weird.
It's not consistent, but they seem to use utterly random textures, including flower textures of all things.

"Locking" Packages?

I love Packages, they look really nice compared to similar mods and the restrictions in play make them much more interesting to use in my opinion-- I really like using them in tandem with Create, because they make great buffers for items.

Would you consider some sort of "locking" mechanism? The idea is that packages could keep 0 of a specific item in them, and reject any other items attempted to be inserted. This could let packages act as basic filters.

As a basic visual indicator, the "0" on the front of a package could turn red, like when one is full. Or you could physically slap a little lock onto it, idk.

[1.17] fixme: cache package blockmodels again

(got lost in the model rework)

[1.18.2 Forge] packages won't accept modded methods of interacting with items

It seems that most mods can't insert/extract/read the contents of a package with the exception of botania's corpora which can extract from packages but can't insert for some reason (pictured).

(Feature Request) Use of ink sacs to change how items display on packages.

This is partly inspired by the create contraption issue from earlier, normal ink sacks could be used on packages to make items render as a pure black silhouette, and in addition glow ink sacks could be used to render the items like on glow item frames.
I'm not entirely sure on what would be the best implementation of this, as just using the sacks on the sides of packages would be odd, and using the sacks in the dye slot of package creation would make this feature not compatible with dyes.

Crash on opening an inventory containing packages

Crash report: https://mclo.gs/rVZA7vY
Info should be included in the link

[1.17] package maker doesn't seem to trigger chunk rebuilds at all

No idea why this happens

Package Rendering gets real weird when you introduce Canvas

minecraft 1.16.4, fabric api 0.25.1, Canvas 1.0.989, Packages 1.1
I'll let the screenshots speak for themselves, was reproduced in a lightweight instance with only the relevant mods

In 1.18.2, Placing Blocks in Packages results in a block placed in world

As described, without shift clicking, any attempt to insert a placeable block inserts a single block into the package and then places another block in the world.

Clean up Package info (hide Package block composition)

When I am using a package in my inventory, the first and foremost thing I want to know is what's in the package, not what it's made of. Yet, this information takes up 3/4 of the entire tooltip, which in my opinion is really unbalanced looking! The package's block composition in the tooltip is pretty visually distracting-- There are different colors and font styles that naturally draw the eye more than the essential information.

You can already visually see what the package is made out of; If the user needs to know the exact blocks the package is comprised of in some scenario, I think that information should be relegated to expanding the tooltip (like holding shift while hovering) or enabling debug tooltips.

¹

Footnotes

1. Tiny nitpick: I'd like to see the colors more unified in the tooltip as well. It would be nice if parentheses were the same color as the "layer" of package described (lightest grey text encased in lightest grey parentheses, etc). I think it would make more sense if the "Ultimately contains" line was also the same color as the innermost layer instead of always the darkest grey. Maybe it would be a cute touch if the number's color was the same as the package's front color? ↩

Mixin Incompatibility with Create Fabric

May not be this mod's fault, but it's the only one mentioned in the mixin crash

full log

[14:15:33] [main/ERROR]: Critical injection failure: LVT in net/minecraft/class_310::method_1536()Z has incompatible changes at opcode 208 in callback packages.fabric.mixins.json:MixinMinecraft from mod packages->@Inject::packages$startAttack$beforeStartDestroyingBlock(Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfoReturnable;ZLnet/minecraft/class_3965;Lnet/minecraft/class_2338;)V.
 Expected: [Z, Lnet/minecraft/class_3965;, Lnet/minecraft/class_2338;]
    Found: [Lnet/minecraft/class_1799;, Z, Lnet/minecraft/class_3965;]
Available: [Lnet/minecraft/class_1799;, Z, Lnet/minecraft/class_3965;, Lnet/minecraft/class_2338;]
[14:15:33] [main/ERROR]: Minecraft has crashed!
net.fabricmc.loader.impl.FormattedException: java.lang.RuntimeException: Mixin transformation of net.minecraft.class_310 failed
	at net.fabricmc.loader.impl.FormattedException.ofLocalized(FormattedException.java:63) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:472) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) ~[fabric-loader-0.15.6.jar:?]
Caused by: java.lang.RuntimeException: Mixin transformation of net.minecraft.class_310 failed
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.getPostMixinClassByteArray(KnotClassDelegate.java:427) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.tryLoadClass(KnotClassDelegate.java:323) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:218) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:119) ~[fabric-loader-0.15.6.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]
	at vazkii.patchouli.client.handler.BookCrashHandler.appendToCrashReport(BookCrashHandler.java:23) ~[Patchouli-1.20.1-84-FABRIC.jar:?]
	at net.minecraft.class_6396.handler$fel000$patchouli$addContext(class_6396.java:1016) ~[client-intermediary.jar:?]
	at net.minecraft.class_6396.<init>(class_6396.java:58) ~[client-intermediary.jar:?]
	at net.minecraft.class_128.<init>(class_128.java:34) ~[client-intermediary.jar:?]
	at net.minecraft.class_128.method_24305(class_128.java:274) ~[client-intermediary.jar:?]
	at net.minecraft.client.main.Main.main(Main.java:164) ~[fabric-loader-0.15.6-1.20.1.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470) ~[fabric-loader-0.15.6.jar:?]
	... 2 more
Caused by: org.spongepowered.asm.mixin.transformer.throwables.MixinTransformerError: An unexpected critical error was encountered
	at org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:392) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClass(MixinTransformer.java:234) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClassBytes(MixinTransformer.java:202) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.getPostMixinClassByteArray(KnotClassDelegate.java:422) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.tryLoadClass(KnotClassDelegate.java:323) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:218) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:119) ~[fabric-loader-0.15.6.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]
	at vazkii.patchouli.client.handler.BookCrashHandler.appendToCrashReport(BookCrashHandler.java:23) ~[Patchouli-1.20.1-84-FABRIC.jar:?]
	at net.minecraft.class_6396.handler$fel000$patchouli$addContext(class_6396.java:1016) ~[client-intermediary.jar:?]
	at net.minecraft.class_6396.<init>(class_6396.java:58) ~[client-intermediary.jar:?]
	at net.minecraft.class_128.<init>(class_128.java:34) ~[client-intermediary.jar:?]
	at net.minecraft.class_128.method_24305(class_128.java:274) ~[client-intermediary.jar:?]
	at net.minecraft.client.main.Main.main(Main.java:164) ~[fabric-loader-0.15.6-1.20.1.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470) ~[fabric-loader-0.15.6.jar:?]
	... 2 more
Caused by: org.spongepowered.asm.mixin.injection.throwables.InjectionError: LVT in net/minecraft/class_310::method_1536()Z has incompatible changes at opcode 208 in callback packages.fabric.mixins.json:MixinMinecraft from mod packages->@Inject::packages$startAttack$beforeStartDestroyingBlock(Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfoReturnable;ZLnet/minecraft/class_3965;Lnet/minecraft/class_2338;)V.
 Expected: [Z, Lnet/minecraft/class_3965;, Lnet/minecraft/class_2338;]
    Found: [Lnet/minecraft/class_1799;, Z, Lnet/minecraft/class_3965;]
Available: [Lnet/minecraft/class_1799;, Z, Lnet/minecraft/class_3965;, Lnet/minecraft/class_2338;]
	at org.spongepowered.asm.mixin.injection.callback.CallbackInjector.inject(CallbackInjector.java:547) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.injection.callback.CallbackInjector.inject(CallbackInjector.java:497) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.injection.code.Injector.inject(Injector.java:276) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.inject(InjectionInfo.java:445) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinTargetContext.applyInjections(MixinTargetContext.java:1377) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.applyInjections(MixinApplicatorStandard.java:1062) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.applyMixin(MixinApplicatorStandard.java:402) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.apply(MixinApplicatorStandard.java:327) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.TargetClassContext.apply(TargetClassContext.java:421) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.TargetClassContext.applyMixins(TargetClassContext.java:403) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:363) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClass(MixinTransformer.java:234) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClassBytes(MixinTransformer.java:202) ~[sponge-mixin-0.12.5+mixin.0.8.5.jar:0.12.5+mixin.0.8.5]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.getPostMixinClassByteArray(KnotClassDelegate.java:422) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.tryLoadClass(KnotClassDelegate.java:323) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:218) ~[fabric-loader-0.15.6.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:119) ~[fabric-loader-0.15.6.jar:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]
	at vazkii.patchouli.client.handler.BookCrashHandler.appendToCrashReport(BookCrashHandler.java:23) ~[Patchouli-1.20.1-84-FABRIC.jar:?]
	at net.minecraft.class_6396.handler$fel000$patchouli$addContext(class_6396.java:1016) ~[client-intermediary.jar:?]
	at net.minecraft.class_6396.<init>(class_6396.java:58) ~[client-intermediary.jar:?]
	at net.minecraft.class_128.<init>(class_128.java:34) ~[client-intermediary.jar:?]
	at net.minecraft.class_128.method_24305(class_128.java:274) ~[client-intermediary.jar:?]
	at net.minecraft.client.main.Main.main(Main.java:164) ~[fabric-loader-0.15.6-1.20.1.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470) ~[fabric-loader-0.15.6.jar:?]
	... 2 more

Empty packages should not drop in creative mode

When breaking packages in creative mode, the block is dropped. I think this should only apply if the package has something inside it. This would be consistent with vanilla shulker box behavior.

Packages have placeholder textures when Sodium is present

Packages's block- and item-model retexturing magic depends on a working implementation of the venerable Fabric Rendering API. At this time, Sodium has a stubbed implementation of FRAPI, which means Packages's models look like this:

You can work around this issue by doing one of the following:

• removing Sodium,
• adding Indium,
• waiting for Sodium to implement FRAPI

Compatibility - Packages v1.0 for MC 1.16.1 and Sodium v0.1.0

When I add Sodium to my installed mods, it breaks Packages pretty thoroughly.
If I relaunch without Sodium, the packages work normally.

Tested in superflat world with just Fabric API, Packages, and Sodium.

Log With Sodium
latest.log

Log Without Sodium
latest.log

Packages With Sodium

didnt correctly steal create's tooltips lol

these days create's tooltips look like this

"also they turn white when the key is held" - autumn

i think the coloration is backward in mine

[Forge] Dispensers don't place packages in world

Packages 3.4 | Forge 1.19.2 - 43.2.6

Tested it with the mod and forge alone.

(Forge 1.18.2/3.1) Quark Myalite Blocks lose coloring as package cores/frames [no BlockColor support]

When used as package cores/frames, Myalite blocks from quark lose all coloring. This affects both package items and blocks.

This might be worth testing on 1.19 as well.

[next update] Things 2 Do

Short term:

• Doublecheck that the new left-click detection code is not terrible (I haven't tested it on servers yet btw)
• kat's request: Tag for things that you're not allowed to put into a Package at all
• Rewrite/clean up inventory code guts, hopefully 🤞 (it's a wreck)
• Implement more actions:
  • insert everything matching in your inventory
  • remove everything from the package, dumping it onto the ground if there's no room
• Fix the Package Crafter not marking chunksections dirty on the client
• Hmm: Try to abstract the package's container into something that isn't directly a blockentity
  • Clean up item code e.g. getting the item to display on the front, or on the tooltip
  • With now-cleaner item code I can feel better about implementing in-inventory actions (the bundle thing)

Long term:

• Implement a client-side config that lets you remap the actions
• Readd compat with DashLoader and FREX if they're still relevant
• Push to 1.19 I guess

(Forge 1.18.2/3.1) Weird Display Item Lighting on Create Contraptions

The display items of packages on create contraptions appear to ignore skylight, but are affected by block light on contraptions.


No fancy render changing mod being used, might be worth testing on other versions/loaders.

Packages break when you click on them in creative, but seemingly only on the dedicated server

At least on fabric. Something mysterious is afoot

[Fabric 1.19.2] Game freezes when trying to create a package

In the latest update, I tried creating a package with stones and planks and the moment I tried putting in the stone as the frame of the package the game freezes..

Picking up a package from the ground with a different package in your inventory duplicates the inventory one and deletes the entity one

That's the only situation I've found with this problem; transferring between inventories is always safe

[Forge 1.18] Dispensers don't place packages in world

Using mod version 1.18.2-3.4, with forge, the dispensers do not place down the packages. Activating a dispenser with a package in it just shoots the item out :(. I see that this was a bug with the 1.19.2 version as well and was fixed, so hopefully this isn't a big deal.

Packages cannot accept hopper input from every face.

While Packages suggest they aim to have a similar interface to shulker boxes, they are not compatible with many shulker box builds because they have a "display" face that cannot accept hopper input. For example, the popular 1-wide tilable shulker box loader that is often deployed cannot use packages because the dispenser places them from below, facing upwards towards the hopper.

While it is possible to modify loader and unloader builds to use packages, it seems like packages already have significant limitations that prevent them from overwhleming the shulker box use cases. And given their rather small default inventory and need for nested loader designs to get the most out of them, incompatibilities with proven loader designs makes them much harder to use.