cubicmetre

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.

The crash takes a while because of the extreme lag slowing down the charging process, it should normally take 90s but ran at around 4 TPS for me so it took about 8 minutes. This is a relatively small cannon btw, normally these types of cannon use a lot more TnT.

2no2name and I looked into this behaviour and it is caused by the weighted pressure plate only checking for changes in power level every 10gt after initial activation. So the random response time is actually a consequence of a random input only being interpreted by the pressure plate on a regular, albeit long, interval. So upon placing the first entity the pressure plate will have a 2gt delay in which it will then output the power level corresponding to how many entities are on it, then it will schedule itself to check again 10gt later. This might be intended behaviour for the component, to minimise the amount of checks that it does woould technically reduce the lagginess of the component. But the weighted pressure plate is very underutilised in redstone at the moment, likely because it is so limited by this long interval between checks. Sometimes if you make a components too dumb to save on the games resources that component becomes pretty useless.

Ok I've just done some additional testing, this bug seems to be a rendering issue in singleplayer. I loaded up a singleplayer world with an update suppressor on my modded client which has fabric loader, carpet and some other client mods. When I tested the suppressor it behaved as it does in previous versions, where a player interaction update does nothing and any other type of update causes the game to crash. I then loaded up the same world in singleplayer on a fully vanilla client and suddenly I was getting the world closing with player interaction updates. However this was not the game crashing as it would simply close the world and bring me to the main menu. Normally with an update suppressor the game would fully crash and I would have to re-launch.

I started adding mods one by one. I added the fabric loader, still closes, I added carpet, still closes. It wasn't until I finally added optifine that the game would work perfectly fine running the update suppressor with player interaction updates. Using any other type of update resulted in the usual game crash. I then moved my test setup to a server, albeit a non-vanilla server as it also had fabric. But given that I did not observe a change in behaviour until I added optifine to my client, this issue appears to be client related. Testing the update suppressor on the server and my client would not crash even if I did not have optifine installed. This issue appears to be a rendering issue that only happens in singleplayer. As optifine is a client optimisation mod for the way the game renders and resulted in an immediate change in behaviour when it was installed.

This bug is related to the way in which hoppers are assigned to the tile entity list when a chunk is loaded. If you place hoppers in the world in a specific order they are added to the list in that order and as such will execute their tasks of pulling and pushing items in the order governed by that list. When the chunk is unloaded the hoppers are not saved in a list which maintains their order, instead the game uses a hash set which obsfucates the order of the hoppers upon loading the chunk from memory. This hash set is slightly more efficient in terms of memory usage than an ordered set, however causes all kinds of ambiguous behaviours which vary depedent on a hoppers position in the world.

This hash set obsfucating the order of hoppers therefore results in contraptions which rely on the order in which hoppers pull and push items locational and break in ways which would be very confusing to the player. I know of a particular mechanism for detecting when a shulker box is full and replacing it with a new, empty box. This mechanism works perfectly fine in most locations and so when designing an entire storage system based upon it I simply built a single setup and stress tested it for hours finding no issues. But then when I copied and stacked the mechanism 350 times to make a storage system capable of storing items in shulker boxes. A bunch of the box loaders kept breaking and it drove me insane trying to figure out the cause. Eventually I had to do a range of testing, swapping the order of the hoppers to find that the exact reason was the locationality of hopper hashing messing with the order of items being pushed and pulled through the overflow detection of the box loader.

Random mechanics like this that are extremely technical and difficult for the basic player to understand and really depreciate the quality of the game, making the technical aspects of redstone less acessible to the general playerbase as they run into issues they don't understand. Giving the player more control over how game mechanics interact instead of introduces randomness that causes stress should be an important consideration for the development of this game.