ru4red

In the Bedrock Edition, what players are asking for is that “individual blocks should have different fundamental properties.” It is perfectly reasonable for different blocks to have different properties. These different fundamental properties do not produce any resources or affect how players play the game; they simply increase the diversity and playability of the game.

Fundamental properties should be independent of one another. Being chargeable, being able to be powered by rails, detecting containers, being waterlogged, being sticky, being pushable, and causing suffocation are all independent properties. For example, ceramic can be pushable without being sticky. These properties are independent, and there is nothing unreasonable about that.

Reducing all blocks to merely solid blocks and non-solid blocks is uninteresting and lacks diversity. Giving up the idea that different blocks can have different properties simply to accommodate the intuition of some players is a shame.

These are Shulker Box Displays. These designs rely on boxes being able to attach to chains, allowing the boxes to face downward while still being opened.

These are Shulker Box Displays. The empty-box recovery mechanisms of these designs rely on the collision boxes of chains.

This is a key structure of the shulker box packer, which relies on the collision box of chains. Chains allow items dropped by the shulker boxes to pass through and be outpu

These are Shulker Box Splitter. Many designs rely on the collision boxes of chains: chains allow items dropped by boxes to pass through and be output.

Blocks with unique properties enrich gameplay, foster creativity, solve complex wiring problems, and improve machine design, even without directly producing items.

Different blocks naturally have their own independent properties. Simplifying them based solely on some players' intuition is unreasonable.

This mechanic is a core part of Bedrock redstone. Bringing these properties to Java would maintain parity, prevent cross-version confusion.

The waterproofing of the sides of the shelf should be similar to that of the stairs, blocking water flow on the intact side while allowing water to flow out on the others.

By the way, unlike the stairs, the bottom of the shelf is not intact, allowing water to escape.

I apologize; my supplementary comments and video above were consecutive, and I should have written them all at once. I sincerely apologize for adding to your workload.

Version 1.21.93 simply reflects the old version; the modified version is 26.20.

​1. Collision results are different from the old version.

2. In a minecart collision, one of the minecarts should not stop.

3. Identical minecarts colliding should not produce different results.

4.Different results in different directions

As you can see, the results of the collision are inconsistent in different directions, and the final position where the minecart stops is different.

This influenced a lot of mine car design, which is very important.

Because the loading range is limited, it's impossible to require entities outside the loading range to move; therefore, this report should be categorized as "as expected".

It is still a problem in 26.3.

This is not a bug; different blocks have different characteristics.

Confirmed in 26.2, not fixed.

Only the first gt in entering the rail does not match the rail position; If the speed is slowed down, the bug will be small enough not to trigger the adjacent sensing rail.

Additionally, trapdoors are 0.1825 thick and hoppers are 0.125 thick. Since a minecart at top speed moves at 0.4 b/gt, it is possible to pass through them at specific positions due to discrete movement.

In Bedrock Edition, when a minecart is on a rail, its block collision box slides parallel to the track one block above it (shown in orange in the image), while the red area represents the minecart's actual hitbox.

Image 1 shows how a minecart can pass

through regular blocks. When entering the inclined rail, the block collision box enters the block's space, allowing it to pass through freely.

Image 2 demonstrates why hoppers, cauldrons, and trapdoors cause minecarts to get stuck. When entering the inclined rail, the minecart's block collision判定 does not enter the block's space, causing it to collide with the block.

This behavior is significantly different from the Java Edition.

I created an animation of the minecart's actual movement. The minecart doesn't perfectly follow the track's trajectory during the first gt after entering the rails, causing this phenomenon.

The original report expects the dismount position to be relative to the rail, but it is actually tied to the minecart. Therefore, this is not a bug.

A more detailed analysis of this report, it is caused by the execution order: the dismount location is determined by the minecart’s position 1gt before it hits the activator rail. This is a consistent mechanical feature and does not require a fix

To clarify what I mean by 'expected behavior': comparing the two tracks in my video, it is clearly visible that the minecart on the top row (which hits the wall) moves slower than the one on the bottom row (which does not hit the wall), excluding the MCPE-225691 bug.

One more addition: this is unrelated to MCPE-225691. Factors like direction or whether there are other minecarts nearby do not matter; the instant stop occurs at random positions regardless.