cubicmetre

Just confirmed the test still fails in 25w37b

This bug report possibly relates to MC-295841 .

This seems pretty much WAI as there isn’t a way to prevent entities from accumulating outside the loaded area without just deleting entities that go outside the loaded area, in which case you basically just don’t save entities to unloaded chunks. It goes without saying that spawning tons of entities in your minecraft world will eventually crash your game and there are many ways to do this with various types of entities and fundamentally it is up to the player to decide if that is what they want to do with the game.

This issue is still unresolved as it descibes to the behaviour of the copper golem sorting items, not their ability to pathfind.

I feel like this should not be fixed, in my experimentation with wind charges there are a lot of specific dynamics about how wind charges work that makes the explosion effect between wind charges cause very undesirable behaviours such as wind charges clipping through blocks and the explosion point for large wind charge batches “drifting” through collision faces. With the behaviour outlined in the report wind charges are unique in contrast with TnT as they can be made to explode at precise locations without those explosions affecting other wind charges.

The described “clipping” into nearby blocks is only relevant for blocks that are actively being moved by a piston. Otherwise the collisions function as intended and in fact this clipping with moving blocks enables a lot of unique ways to move entities with pistons.

We should be able to downvote issues whose resolution would be unanimously deemed deterimental to the game

But the experimental minecart changes are not supported officially and break many other minecart behaviours when enabled. It's not a real fix.

What is with Mojang constantly using hash sets for everything? This is how you get locational redstone with weird rules for what powers first.There should be a rule for devs to not use hash sets.

Ram allocation is completely beside the point as the environment is the same for each test which shows a clear difference in the lag experienced in 1.20.2 and 1.20.3. As a matter of fact I use a mod which optimizes RAM allocation during gameplay which is not present in the tests to preseve the vanilla behaviour.

Why is this even being debated? Minecarts snapping to rails has been established for over a decade now. This issue affects everyone, not just redstone players. Is changing the games mechanics really more important than giving players what they want?

In PvP settings the players nametag showing through blocks is an easy way to be detected and killed, the ability to sneak and reduce the visibility of the name tag was an intended feature which PvP players used to, well, sneak up on people. I am hoping the applied fix does not break this feature.

Can you at least fix the inventory management crisis so we don't have to build a new storage three times the size of the old one by the next update?

This isn't a duplicate, MC-266123 is about Minecarts checking for colliding blocks upon dismount and placing entities at the position of the cart if there are no valid positions found, this behaviour is expected in the context of MC-266123.

The actual issue being presented in this report is the minecart dismounting entities inside the position of the minecart regardless of whether the blocks around are valid locations. The minecart should first check for valid positions in a 3x3 radius around the cart before dismounting at the position of the cart which is not mentioned in MC-266123.

Can confirm that this has been an issue since 1.20.3. Due to experimental features in 1.19.4 many servers have not even bothered updating to 1.20 and so this seems to have gone completely unoticed by most servers. This would break shulker farms, villager trading halls, pretty much any contraption that handles mobs and animals using minecarts because if they are always dismounted on the rails they would not pathfind properly or block the rail causing carts to jam. It is imperative that this behaviour is fixed.

Why do I feel like the answer to this issue is "uh nuh duh" given NBT compression reduces the memory usage geometrically provided the same items are stored together. For example a bundle filled with 64 of the same item in every slot of a shulker box filling every slot of a double chest would consume far less memory than the same situation but with dissimilar items simply due to how NBT compression works. Then higher memory usage results in more processing needed to load/unload chunks or parse player data.

A report specifically about the explosion calculations would be made redundant by MC-238249 which goes into a lot more detail on that.