Memttm

Having done some testing of this, I have found that there are some blocks which don’t cause observer inconsistency, namely bells, pistons, moving blocks, and mob heads (ender dragon and piglin). Based on this, the bug seems to be an issue with updates created by scheduled ticks not progressing across chunk borders consistently, as all of the blocks that aren’t inconsistent are block entities that are constantly ticked for powered/active state (droppers, dispensers, and hoppers are block entities, but they don’t update their powered state in the block entity stage, thus not being consistent). Also, the inconsistency notably matches for any components crossing the same chunk border, thus likely being an issue with update propagation.

(Note, in the video linked in the report involving pistons, the behavior shown is actually piston inconsistency (the two pistons in the flying machine like unit activate/deactivate on the same tick, and their order isn’t fixed, so the behavior is inconsistent, but not part of this bug report).

Portal cooldown does exist, but doesn’t take that long to end, maybe as the sulfur cube’s AI is frozen, it may freeze the countdown.

After some thinking, I think this is a duplicate of MCPE-147882, just a much more extreme case. The scenario I had involved 100-200 mobs trying to reach NPCs below the floor (angered by /damage), recalculating paths every half second (commands would replace the NPC every half second), plus other commands running on it.

I can report the same issues. When I tried to do multiplayer on a longtime world of mine (minigame world) the game would experience extreme lag spikes and would freeze for so long it kicked the other player. It also created an extremely strange visual glitch, distorted triangles:

Unless this is an issue with lighting updates (something that may have been causing the lag and is in the changelog as fixed for 26.10) multiplayer when I am the host (it wasn’t a problem when I was on a realm) is unplayable. Overall, stability and performance needs to be improved, as in my base on the realm I mentioned, while I don’t get minute long freezes, framerate will constantly vary between 5 and 50 frames randomly, with decently common several second freezes. (this base has lots of villagers and farms in it, and I use a 5 year old iPad, so not the most optimal conditions for play)

Update: I tried to replicate the crash in a different world, but was unable to get the game to crash, suggesting either the process is specific, requires multiplayer (I will try this later), or it inconsistent and random.

As of 1.21.132, I am experiencing occasional crashes, seemingly without any reason. The game would crash while I was standing still, and on a couple occasions crashed when attempting to exit the world (this is a bit strange). I would guess this is RAM related, but I have no way of checking. The world this is occurring on isn’t quite normal, being a mini game world with 348 hours of playtime in total, a decent number of active command blocks, on a 5-6 year old iPad with 15 chunk fancy render distance (5 more than the normal max, done with editing options.txt). Some crashes have occurred after using especially laggy mini games (20,000 command blocks in a pile is liable to cause issues, or large quantities of block updates or entities), however the incidents I am mentioning occur when there is no major lag and seemingly no reason for RAM usage to rise (my guess as to what is occurring). If possible, the game needs to be able to detect when RAM is running low and shift away from using RAM if possible, and preferably use less RAM in the first place.

I disagree that this is a feature request, as a spear is meant to have a charge and jab attack, using it as a standard melee weapon isn’t intended. An issue appearing on bedrock and java doesn't always mean it is an issue, it just means that the developers hadn’t thought about this when coding it. There are many bug reports I have seen which occurred on both bedrock and java, and so have separate bug reports for both versions. If this behavior is intended, it should be reported as intended by official Mojang documentation.

Also, the behavior between both versions isn’t entirely consistent, as the different attack max and min range applies to java but not bedrock, tracked in the seperate report MCPE-233932. Overall, I don’t think this should be classed as invalid for being mostly conststent between versions, and if it is works as intended then that should be decided by the Mojang devs. This issue looks to me like an area that the devs just forgot about. Also, this issue could affect weapons with custom attack behavior, whether they are using the charge or jab attack properties, or other properties existing now or later.

Having them as separate, labeled values for different solid/non-solid related properties, labeled accordingly, would probably be best, as there are also other properties controlled by solidity, like mob suffocation and whether minecarts bounce off of them, that could be separated into separate modifiable properties, maybe under a “solidity” grouping, as the multiple separate values for solidity in different areas seem to also cause issues for the Mojang devs, as the new shelf block has the same issue mentioned in your bug report, namely cutting redstone while not conducting signals or visually cutting it.

Also the issue where redstone can be visually cut/not cut while behaving differently needs to be fixed.

“This behaviour should be impossible and is not seen in any vanilla redstone components.”

Well… This exact issue is seen in about 20 - 30 ish vanilla blocks, which either visually cut redstone while not conducing it, or visually not cutting redstone lines while conducting power and actually cutting the visually uncut line. Also, comparator readings through conductive blocks are based on the redstone_conductor property, so they can also diverge from the actual conductivity of the block.

An incomplete list, based on memory:

Conducts, doesn’t cut visually, blocks comparator readings:

Target block, Bell, dripleaf.

Doesn’t conduct, cuts visually, allows comparator readings:

Piston, Sticky Piston, chain (both copper and iron), sniffer egg, path block, farmland, chorus plant, chorus flower, copper grate, also the shelf I think.

Special: Doesn’t conduct, cuts actually not visually, denies compartor readings:

Mob heads

Skulk shrieker

Copper bulb (also cuts visually as well as properly)

While this is strange, several mechanics here are used in actual vanilla redstone builds, and fixing this bug would annoy/anger many in the Bedrock Redstone community (that includes me, as I have used the piston/sticky piston and copper bulb properties in some of my redstone builds.)

Notably there is an earlier bug report related to this about comparators reading through chains (MCPE-138549), where many comments noted it uses in shuklerbox loaders (not sure how it is used though, I haven't tried to build one)

As a result, I don't really want nor expect Mojang to change this, and if so I would prefer them to make it either have some kind of consistency or some visual indication in game.

However, 4 blocks which used to have strange properties were fixed relatively recently, namely tnt, sea lantern, mangrove roots, and beacons, so some of the more obscure strange blocks may be fixed in the future.

Playing on an iPad 8, the issue is far worse than in the videos above, freezing for 5 to 30 seconds or more, but rarely (both on realm and not on realm) However, this may be affected by my render distance being set to 15 chunks (5 more than normal max) (done by editing the options file). However, I would expect that lag from higher render distances would be consistent, instead of occurring briefly in massive freezes. (This may be related to chunk saving/loading, as I remember spotting a similar ish older bug report about lag spikes when auto saving on Xbox.)

This setup can actually detect if you are just standing near any redstone inputs anywhere in the world. Very strange.

Based on my own testing of the issue, it seems that the moving block is controlled by the piston that moved it. (Discovered by cloning the moving block somewhere else while being moved. It doesn't revert to a regular block when movement finishes, and extending/retracting the piston that created it causes it to move, no matter how far away it is. Destroying the piston causes it to revert to a regular block where it should have reverted to earlier.)

Based on that, I think that what is actually occurring here is that the reverting of the moving block is done during the step of updating the piston that moved it, so the issue is the same as MCPE-16371. The solution here is to have pistons finishing movement always updated before pistons starting movement. There is already a feedback suggestion on that fix.

Interestingly, I have actually managed to implement this fix using commands, by destroying and then replacing the piston midway through movement, which makes the moving blocks revert faster than they are supposed to. This also provides more evidence that the moving blocks are controlled by the piston that created them.

         I noticed some similar posts about blocks having strange mixed solid/non-solid properties, so I decided to test some of the solid/non-solid properties of most blocks in the game, and I found many more that have strange solid/non-solid properties, a total of 25, but there may be some I missed. Some of these properties are useful, namely the cutting of redstone lines by copper bulbs and comparators reading signals through pistons, and I think those should be kept. I think the posts should be set up to be one post per strange solid/non-solid behavior, ie "visuals of redstone line being cut/not cut don't match behavior" should be one post, "comparators reading/not reading signals through blocks they shouldn't/should" should be another post, and "minecarts not bouncing off of blocks they should" should be another post. Each post would list the bocks affected.