Memttm

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.