cubicmetre

I was observing a small hiccup in a specific mechanism just because a tripwire somewhere else in the machine was being touched by an entity. But Savva’s demonstration showing it breaking something as simple and universal as a repeater clock indiciates that this is a much more serious issue. This would not just affect technical players but also mess with anyone trying to casually learn and engage with redstone in general.

The patch for this issue has been a disaster for wind charge aiming tech. The raycast penetrating blocks is what enabled mechanisms that could trigger a wind charge through a solid hitbox using a player arrow. This allowed for mechanisms that could recieve the players view angle whilst retaining the arrow. Now it’s impossible to make these wind charge aiming mechanisms that are reliably re-usable.

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.