Would it be possible to use vanilla tweaks' mob head textures? Or is there some rights issue there? Also side note - I may make an actual suggestion post for this, but having note block sounds attached to the mob heads the way the vanilla tweaks pack does it would be extremely cool
idk, I have never heard of vanilla tweaks pack before today. There is really nothing wrong with the process we have been using - I am not really looking to use someone else's work. As we do not really have a process in place to give proper attribution (which is what their terms of service require). https://vanillatweaks.net/terms/ Ultimately, it is not a crazy process. I am just saying it hasn't happened. Someone else is welcome to work with me on it. It doesn't "have" to be Moople. I am glad people are excited for an aspect of it. But this art detail of the update is simply not something I can justify doing myself ... I mean... I did every other part of the update, lol.
The update from 1.21.6 to 1.21.7 was a complete surprise. I started a new download folder for 1.21.7 (just like I did for previous versions) in preparation to copy and paste the new files into a newly created mods folder (after renaming the old folder to mods 1.21.6. This way I have something to go back to incase things go south). With the addition of the Via mods, I don't have to do that yet. Many kudos to you chickeneer.
There are plenty of people who like to make skins and such... So with Ms Moople being busy irl, who wants to throw their hat in the ring for Head design-ing.
Hey Chicken, Not sure if someone already reported this since we were discussing in chat the other day, but there seems to be a change with item entity merging after the last update that has broken some farms. Previously, if you dropped a single item down through a hole, any nearby like items less than a full stack within the merge radius would merge into the falling stack. With the large merge radius on EMC, this gave a unique and low-lag way to collect items from farms like pumpkin and melon farms. After the update, it now appears that the falling item instead merges with the stationary items instead of the other way around. If you happen to know what's going on or have time to look into it, I'd appreciate it. It would be helpful to know if we might be able to revert to the prior behavior or if this is the new normal, in which case I'll need to overhaul my melon farm. Thanks for all your hard work!
This change is from Mojang side and not EMC side. New behavior is that the items will be stacked into the largest stack, not the youngest/oldest. so if a 15 item stack already exist, and you drop 1 item then that 1 item will be added to the existing stack of 15, making it 16 items... if a stack of 15 exist and you drop 20, those 15 will be added to the new stack you just dropped. EMC only change from vanilla behavior is that when the item stacks are exactly the same size, then it will prefer the youngest/newest stack (Mojang's behavior is that it will be random) tldr: this behavior will stay, probably source: tests when reporting + my understanding of what chicken mentioned in my PM edit in July 9th reboot chicken changed stuff. Read below changes
Thanks tuqueque for the details. I've tried scouring the changelogs for both Minecraft and Paper and can't seem to find any relevant mentions. But I've had similar issues in the past with vanilla Minecraft making changes to mechanics that break farms with no apparent mention in the changelogs. My guess is that this was a minor enough change in vanilla that they didn't think it warranted a mention. The effect is greatly magnified on EMC because of the item merge radius. As best I can tell, the prior behavior was whichever item stack checked for merging first would suck in nearby stacks regardless of size. Because falling entities check for merging more frequently (every 2 game ticks instead of every 40 game ticks for stationary item entities), the falling entities would typically suck in the stationary item entities. The new behavior seems to be that regardless of which entity is checking for merge, the stack sizes are now checked to determine which is grown and which gets despawned. At least, this is what I've pieced together from a number of comments found online, but still haven't found any formal documentation on the prior behavior or the change. Regardless, sounds like this is new vanilla behavior so time to redesign some farms!
I'll write a more complete response later... I originally thought it was in Mojang code. But what has changed is a bit more nuanced. In general. It is a topic that is being evaluated still... Despite my message with tuq the other day making it sound more final Edit: It is mojang logic. But Paper removed some logic to align better with Vanilla. A pickle.
I had no idea they did that using the vanilla tweaks!!!! I can't wait to go check this out. heheheeeee Thanks Marvel!!
Last night I sent out some adjustments to item merging. Some comments... At some point a long time ago, Spigot implemented configurable item merge radius to merge together item entities to help with server performance. EMC has used an item merge radius of 5. Vanilla has had item stacking for a very long time. Always merging into items with 0.5 blocks distance into the stack with the larger count. Paper, in this commit - LINK, removed some logic that used to control which item merged into which. Spigot's logic completely ignored the item stack count size. In fairness, this bypass seems arbitrary, so I can't question their removal of this. My best reasoning for why it "seems" like they merged into the newer entity. Is that a new item entity triggers this merging logic first. Otherwise it would be based on ticking iteration order which is not necessarily deterministic. The removed change. So our recent update to 1.21.7 reverted to Vanilla's item stack count size AND kept the 5 radius merge distance with an experience which felt different compared to how it has worked for seemingly forever. Last night's update did the following: 1) I lowered our merge radius to 2. I am hoping this gives a 'feel' closer to vanilla. The 5 radius seems a bit aggressive to just always merge things getting thrown about. 2) I implemented the perceived legacy logic. https://github.com/starlis/empirecr...t/world/entity/item/ItemEntity.java.patch#L24 I mulled over this issue for a lot longer than I probably should have... The major thing I was wrestling with, was the idea of putting us back all the way to the 0.5 radius merge distance. But decided that extreme of a change was not necessary. I think everyone should be satisfied with the current experience.
Thanks chicken for putting so much time into this. It is very helpful to see the details behind the observed behaviors so we can plan farms accordingly. One detail that might explain why EMC falling items always absorbed stationary item stacks is that the falling items get ticked to check for item merge more frequently (every 2 game ticks instead of every 40 game ticks for stationary items - at least in vanilla). The new behavior using age should reasonably replicate the effect since most collection in these types of farms involves dropping new entities of the same type to be collected through drop chutes to absorb all nearby stationary item stacks (typically older) and have them all fall down the collection chute. The change to a smaller item merge radius will significantly reduce the "reach" of these drop chutes however so they will still need to be redesigned and may no longer provide the lag advantage over other collection methods. I appreciate that this is a niche application though and look forward to the more vanilla behavior. Thanks again for your work and detailed explanations!
I am quite uncertain on the lag improvements one way or the other. As theoretically the larger radius requires a larger entity bounding box search to compare possible merges to. The original theory probably would have been that the more things you can get merged. Overall that reduces the total things to iterate over across the board. There has to be some number where that improvement starts eating its own tail by searching over to wide of a range creating even more iterations when you check against all of those possible combinations. An illustration. 4 items spaced 1 block apart in vanilla. Each item ticks once and there is nothing within range to try merging. Numbers: 4 - 0. 4 items spaced 1 block apart with a 5 merge radius. They are close enough to all merge thus you now only have 1 item ticking. Numbers: 1 - 0 . 4 items spaced on top of each other, none stack with each other. So you have 4 items ticking. But each item, conceivably is checking the other 3 nearby items to see if they merge... Numbers: 4 - 12. 4 items on top of each other. 1 full stack of dirt and 1 single dirt. 1 full stack of snad and 1 single snad. So 4 items are ticking and none will merge. The full stacks don't search for nearby items to merge with because they know they are not mergeable. But the single dirt/snad will try. Numbers: 4 - 6. Anyways. So on and so forth from there. Ultimate goal is to either get them merged, or to get them to full stacks from my way oversimplified explanation on iterating. In my mind. There is a point where I expect the benefits to start degrading. But that point may be inconsequential compared to the negative user experience beyond a 5 radius distance. End ramblings.
I will say, it has always been nice to be able to grab an item from just out of reach or through a closed corner by just chucking another item at it. Not that that's necessarily an intended behavior, but it has always been a thing lol. On the other hand, I feel like more often than that convenience is is downside of things incoherently sticking together, in a way that's frustrating until you figure out what's happening. So this is probably a great compromise
