[Bugs?/Enhancements]

[BioTechproject27]

Hey, so first off I wanted to say that this is a really great mod!

Anyway, as to the bugs I experienced [using Fabric 0.15.6, Fabric API 0.92.0+1.20.1, CAC 0.9-fabric+1.20, Unruled API 0.2-fabric+1.20, no other mods]:

• The chest flinging seems to be working perfectly in the X axis (east-west) but is reversed in the Z (north-south). E.g. a south facing chest will fling items south (when chests.lidFling is true, otherwise default gamerules).

• [Maybe bug, if not, feature request]: Downward facing barrels opened by players drop all items, but not if opened by a dispenser (when chests.barrelFall is true, otherwise default gamerules).

Other feature requests:

• It would be good if the items falling out of barrels would spread a little. Right now they are perfectly aligned in the middle of the block, which feels kinda unnatural. Maybe make the falling direction/position of the item depend on the position inside the inventory? [E.g. upper left corner item [Slot 0] would fall slightly to the north west, while the middle item [Slot 13] would fall pretty much straight down, etc.] But it would definitely be better with a very slight randomness value. (I think less if the previous suggestion is feasable, more but not quite as much as a dispenser if not would feel pretty natural?)

Also it would be great to list the Fabric API as a dependency (on modrinth), as, at least the flinging, won't work at all (while it's rare that the fabric api isn't already included by some mods/modpacks, it's still good to list it as I was a bit confused when debugging) without it.

[BioTechproject27]

Also I'd love to see compatability with Valkyrien Skies (e.g. ships leaning too far could lead barrels to spill their items if opened), but they have a lot of bugs to deal with themselves :(

[NerjalNosk]

Hello, thank you for reaching out! Glad you like the mod.

While I understand the fact that the items falling all aligned may seem rather disturbing, it is thus far a choice of design, as to allow for more precise automation of tasks using this feature. For it allows indeed to make sure to get items down in a precise place rather than randomly dispersed on the ground as it would be if you were to transport them via a water stream or drop them down using a dropper. However I suppose it wouldn't cost to add a gamerule allowing some more randomness in the items' locations, but I doubt the fact that they fall straight down will ever change.

As for the fact that the flinging is reversed on the Z axis, that sure is weird, as all playtest seemed to show perfectly normal behaviour. I shall ook into it when I have time.

Las but not least, the fact that the flinging does not work without Fabric API installed is quite an issue, for it is specifically designed to work independently of Fabric API being installed. However I do recall Fabric having issues with properly loading data from mods in 1.20? Or at least I recall it giving me struggle testing my work. So I wouldn't be surprised if that was to be blamed for this issue, as it would prevent the entity type tag that determines what entities can or cannot be flung to be loaded. However this may easily be solved in a future version, as tags and overall data definition would move from being hard set as json to coded builders that mods could easily modify.

Also, as for Valkyrien Skies compatibility, while I understand the idea, it yet has to get out of beta to be considered anyhow stable, end thus for other mods to be able to properly provide compatibility. However, Chests are Chests! could provide an easy way to add compatibility, beyond what it already does, for mods such as Valkyrien, but also possibly Create's contraptions and alike.

[BioTechproject27]

For it allows indeed to make sure to get items down in a precise place rather than randomly dispersed on the ground as it would be if you were to [...] drop them down using a dropper.

You can already do that in vanilla. By dropping items into cobwebs or powdered snow you'll eliminate all their horizontal momentum, dropping straight down when they leave the block. Also you can always yeet items and let them collide with blocks which will kill their momentum in that direction (e.g. corners work well). But if, for some reason, you want them perfectly aligned in the middle, you can even do that. Just push them with water into the sides of boats (unfortunately no block exists to replace the boat, as you'd need one which is 6 pixels from the edge. It may be possible with bamboo, but that's random).

So it's not exactly new, but does require a bit of effort. But I agree, it should be configurable with a gamerule giving some randomness.

As for the fact that the flinging is reversed on the Z axis, that sure is weird, as all playtest seemed to show perfectly normal behaviour. I shall ook into it when I have time.

I can assist with my logs, recordings, etc if you won't have success reproducing it

However I do recall Fabric having issues with properly loading data from mods in 1.20

Ah I see... For now, a small mention somewhere would be great then I think :>

Also, as for Valkyrien Skies compatibility, while I understand the idea, it yet has to get out of beta to be considered anyhow stable, end thus for other mods to be able to properly provide compatibility.

Yeah I absolutely understand. They will also probably change a lot of mechanics, it is a complex and big project after all. Time will tell.

[BioTechproject27]

Oh btw, what about

[Maybe bug, if not, feature request]: Downward facing barrels opened by players drop all items, but not if opened by a dispenser (when chests.barrelFall is true, otherwise default gamerules).

?

[NerjalNosk]

I forgot to answer to the barrels fall part indeed. This is on me. I see why it is not behaving as one would expect, and it totally makes sense. Initially, the reason why doesn't do it was to avoid abusive block-entity ticking, which in turn could cause lag. But as I improved how inventories get emptied later on -- or not, depending on the items -- it would make sense to get back to a behaviour that would at least allow the items to fall. So it is indeed an issue, but will be fixed soon enough. Thank you for reporting it.

[NerjalNosk]

Ah I see... For now, a small mention somewhere would be great then I think :>

While it would be nice indeed, I am still uncertain about it really is a Fabric issue or me that messed something up. I will have to dig into it anyway.

I can assist with my logs, recordings, etc if you won't have success reproducing it

Thank you for offering, but so far I do not think this is required. The most logical reason would be me messing up a velocity factor, which then would be rather easy to reproduce. If needed, I will get back to you about it, but until then, I do not think there will be any need for recordings or logs honestly.

So it's not exactly new, but does require a bit of effort. But I agree, it should be configurable with a gamerule giving some randomness.

Possible or not in vanilla, the aim of mods is also to provide more tools and options to the players, and that would be one, to allow especially technical players to use it into large scale contraptions, and not have to worry about randomness or having to cancel it, yet without waiting for items to fall through cobwebs or powdered snow.

[BioTechproject27]

Possible or not in vanilla, the aim of mods is also to provide more tools and options to the players, and that would be one, to allow especially technical players to use it into large scale contraptions, and not have to worry about randomness or having to cancel it, yet without waiting for items to fall through cobwebs or powdered snow.

True, I absolutely agree. But I feel like this perfect item aligning doesn't fit here, because that's not how things "spill out" of containers, which is the intent here. As a technical player myself, if item alignment precision in X-Z is required, simply letting item entities collide with blocks or solid hitboxes (like boats; shulkers also work in very, very specific circumstances) works perfectly fine. And items fall through powdered snow pretty fast already tbh. Even so, because the barrel can yeet a full 3x9 stacks at once, it's super fast already. So, there really isn't anything a barrel "solves" in that regard. If anything, it just replaces a downwards facing dropper/dispenser(depending on the item tag #chests_are_chests:special_fall) in most cases, and especially the pow snow combo.

I feel like it has its own little niche: Compact and fast, single "charge", slow refill inventory yeeting. For example equipping stations (especially stackables), where shulker box killing, or minecart yeeting would take up too much space & time (and in the latter case, computing resources).

But anyway, a setting would allow for individual flexibility (e.g. people could have other mods that already do precise item aligning, but still want a "natural" barrel-spilling mechanic). My personal opinion is that it should spread gently (aka far less than an entity exploding, like in cart yeeting, and not as extreme as dispensers. Maybe so little that with powdered snow it's within 1-2 pixels of spreading?), or maybe what I proposed: Have the option to make the spawning (perhaps instead of travelling direction, which was what I chose to elaborate on) depend on the position in the inventory (ofc requiring many mods to add their own support for this setting if they add bigger/smaller barrel-types). Here, a full barrel spilling could form a perfect quare of items on the floor filling every space (with randomness set to 0). An item slab, if you will. I think that would be pretty funny, but also still "natural"

[NerjalNosk]

Sadly there is no way to know the dimensions of an inventory's menu, and that isn't even really set, for any mod can just change that. So it'd have to be hardcoded but with a stupid lot of compatibilities. Not to mention special mods that add configurable menus, more or less wide, etc, so much that in the end you simply cannot guess how to spill the items.

But do not fret, for I have an idea of how to do that. I will just keep how it is, but add a single floating gamerule ranging from 0 to 0.5, which will determine a set of random possible positions for the items to actually fall at (making it a radius around the perfect middle position)

All so that in the end the players (or admins) can configure how random the spill can be, with 0 being default (so like the current behaviour)

[NerjalNosk]

Wrapped up in #0.10

[BioTechproject27]

Hey uuh, sorry to bother again... but 0.10 somehow introduced new bugs....

• if chests.barrelFall is set to true, chests aren't activated by dispensers for some reason (means no opening, so e.g. items can't fall in) [with chests.dispenserOpen set to true. While barrels are activated]
• chests.lidFling doesn't work at all anymore :(
• using chests.barrelFall.spreadRadius set to any value over 0.0, it spawns some items in the neighboring south-east [+Z/+X] spaces, meaning they can sometimes spawn in blocks (sometimes even in the cornering block space)

.

Sadly there is no way to know the dimensions of an inventory's menu

would it not be possible to check for the highest slot(and sure, that wouldn't tell you how many slots there are per row, but maybe a simple square approximation would suffice)? e.g. barrels & chests have 27 slots, from 0b to 26b Anyway, this was just a fancy idea, I know it would be annoying to code. But, a simple spread I think may be good, is them spawning in a max 3px (~0.1875 blocks) Chebyshev distance around the center (height is already perfect imo), with a vertical motion of ~-0.2 (this would create more of the effect of "pouring out", because it would create the illusion of items already picking up momentum inside the barrel (and 0.2 is roughly the momentum an item would get after falling for ~0.4 blocks) [and as a bonus speeds up your contraptions that can't wait for ~7 extra gameticks of powdered snow, as they now take 3 ticks less to fall 7 blocks.]) and horizontal motion of max 0.015. The latter would allow the most extreme items to fall a full 7 blocks while still staying directly under the barrel, not being able to slip into e.g. nearby hoppers.

And why bother adding something like this in the first place? Well, because even such little movement would give them just a little more life. Subtle changes like this are after all what makes games feel so much less static, because nature is chaotic, which is kind of the whole point of this mod, adding "phyiscs" to barrels and chests.

.

Also, on a more general note, the way you type suggests to me that you were very annoyed (e.g. not mentioning what I feel were good points, very "hard" speech[e.g. complete punctuation, indicating no room for further ideas; sarcasm in response to ideas]) and I'd just like to know why that is? Like, I don't want to cause any harm, I want to add to the mod so I and others have more flexibility and maybe something that seems to better fit to the base game..

[NerjalNosk]

Also, on a more general note, the way you type suggests to me that you were very annoyed

Such as not my intention, sorry if it felt that way. I only tend to make choices considering both wins and losses from each option, and tend to avoid costly runtime computing tasks. I myself have experience with laggy server runtime, even when the clients are doing just fine, causing annoying rollbacks and all, and would rather avoid causing that on others as well. While I get that you have plenty of ideas, about how to possibly "improve" the way the mod feels, they come with downsides that make these ideas not so interesting.

E.g. I use a pre-emptive way to make container ticks iterate through the whole inventory to run the same code on each stack over and over again, all so that any time the container tick, only updated stacks get to possibly fall, if some were already marked as "not to fall" (or fly up, get out, whichever, depending on the item and how it is implemented). All so to only make the relevant checks about whether it should fall in the given situation only if it is a newly updated stack. And from there, I only compute a random position (since 0.10) at which to spawn the item entity (provided it is indeed an item to be spawned), create the entity, give it an initial velocity (which is already the case, and is required to prevent the chaotic default vanilla randomness that you get with dispensers or even just on killing an entity or breaking a chest), and place it in the world. All in all, I only have a single iteration over the entire inventory. However, if I was to implement what you suggest, to more "harmonically" disperse the items within the provided radius, I would not only have to iterate through the entire inventory, but also keep trace of what I did with all the iterated items, then iterate through them, split them by "face", then iterate through them again in order to properly split them, which then again would come at an uncertain cost considering it could mean multiple iteration to make recursive adjustments. Thus, for a more technical conclusion, it'd get from a regular O(n) complexity to a whole O(n log n²), which often can get approximated to O(n²) at a lower range (and we don't have thousands of stacks to iterate through per block after all. In the end, while I get your point that it would feel more realistic, it would come at a computation cost which make the whole thing just not interesting enough to really bother try to implement it.

However. I DO appreciate you pointing out bugs, for those are definitely relevant looking into. For instance, I refactored (moved) a bit of the code for the dispenser force-opening, and would suppose I simply forgot to properly hook up the proper parts of it when it comes to opening chests. As for the lid flinging, I will have to look into it. Last but not least, the spread radius issue is something I believe to be caused by the vanilla way of spawning entities at a given location, for all I am doing is randomly picking spots in a disc determined by the configured radius ; hence a too high value can indeed result in the item being half into another block.

All in all, thank you for your feedback, I will look into these issues when I get the time. However, that will not be possible before the weekend, so please don't expect any mod update before then.