Stephan Smith

Can confirm, still an issue. I cant upload the video because the size is too large. The steps are simple: generate a new superflat world, create a large grid of single copper blocks and doors with 4 blocks of space in between (5 meter center to center distance). Make the grid size large enough that you can see trends instead of just individual randomness. Either wait or use the tick rate/randomTickSpeed commands. If your sample size is large enough you'll see plain as day: when most of the individual blocks have oxidized completely the doors will still be in a mixed state, with a large percentage (~20-40% in my testing) still untouched by oxidation.

This is especially problematic since doors must be crafted using ingots, and as such always start out completely unoxidized.

Steps to reproduce: place a bunch of copper blocks in a grid with 4 block spacing between, place a bunch of doors in a similar grid. Wait and watch oxidation rates.

Observed: doors oxidize much slower

Expected: they'd oxidized at similar rates, since they're spaced out the same.

Issue is more nuanced than I originally thought. It seems direct momentum redirection when T-boning is intentional and useful. But the behavior is inconsistent when considering sloped vs unpowered rails. Default direction transfer is to the positive axis in all cases, but an exception is made when the rail slope is factored in. This makes sense, downhill makes more sense than uphill when it has otherwise been traveling perpendicular. However, there is no exception made when the rail is unpowered. It seems for consistent behavior the entire state of the rail should be checked before redirecting the minecart momentum. If sloped, go with slope, if unpowered cancel momentum, else default to positive direction. It would also make sense to perform the adjacent block check to determine ideal momentum direction, even on flat, powered rails. Otherwise in one direction you have to wait for the cart to slam into the block 'bounce' killing the carts momentum, while in the other direction momentum transfers seamlessly.

Tested on unmodfied instance, performs the same

Steps to reproduce: 1. build the described t-boning setups 2. Full send minecarts 3. Use data get command to see minecart momentum if necessary.

Expected: Full state of rail would be considered before resultant momentum of cart is determined in a T-bone interaction

Observed: Default positive direction is implemented before full state is considered resulting in unintuitive behavior.

1. Start a raid
Results
Game crashes when first wave of pillagers spawn

Next
1. Vist ocean monument
2.Defeat guardian(s)
Result
Game crashes when monument is past renderd distance

Temporary fix. Load the game in peaceful. It will end the raid. My game crashes during raids also. I did this and it fixed it but will crash if you start another raid.

could you have possibly burnt in your screen?

how about making it 2x2 would be frustratingly hard to hit. Already not a fan of glass panes and iron bars because of that