mojira.dev

stacked_dynamite

Assigned

No issues.

Reported

MC-301649 Various mob AI search ranges are now random Works As Intended MC-296057 Sideways non-projectile movements may fail to apply block effects from blocks around start of sideways motion Fixed MC-296055 Slow non-projectile entity movements may fail to apply block effects from origin block Fixed MC-296054 Fast non-projectile entity movements may fail to apply block effects from blocks around the starting position when moving in positive directions Fixed MC-280342 Slimes and magma cubes can spawn inside of entities and fluids Community Consensus MC-279809 Full hopper minecarts cause extracted inventories to send comparator updates Community Consensus

Comments

The resolution of MC-145656: Attribute "follow_range" is not working for hostile mobs before they find the target indicates that Mojang intended follow_range to govern not only pursuit distance but also detection and general search ranges.

Most of the breaking changes in this report are not with hostile mobs. The listed changes in this report are ones which had their search ranges switched to follow range when they were not using it before. Even some hostile mobs listed as breaking do not use all those sensors to for finding and pursuing targets.

Also, the mobs reported in MC-145656 and related reports were already using follow range in their target search range - the issue was likely with commands not updating the internal follow range value not the search logic itself. Most of those mobs do not even use the sensors/logic detailed here.

If the main concern is reduced efficiency in farms due to this change, then the appropriate venue would be the Feedback site, rather than the Bug Tracker, since the issue pertains to design preferences rather than unintended behavior.

This is a change of pre-existing behavior that have been used to make farms in the past. Players updating from 1.21.1 and below have observed that some existing farms have been affected.

Also note: https://github.com/lntricate1/EntityTrackerScript was used for images

Also note: https://github.com/lntricate1/EntityTrackerScript was used for images

[media][media][media]
[media]
[media][media]

Can confirm in 1.21.5 rc1
Note: This bug was introduced in 25w09a

This bug is caused by the updates now in baseRailBlock affectNeighborsAfterRemoval no longer getting called whenever powered/activator rails change state due to changes in how levelChunk setBlockState works

 

The old update order is:
Block updates around 1 block above (if sloped), Block updates around rail, Block updates 1 block below, - from what is now in affectNeighborsAfterRemoval
Block updates around rail [not usually observed], Shape updates around rail - from level setBlock with flag 3
Block updates around 1 block below; Block updates around 1 block above (if sloped) - from poweredRailBlock updateState [both not usually observed]

The 25w02a update order is:
Block updates around rail, Shape updates around rail - from level setBlock with flag 3
Block updates around 1 block below; Block updates around 1 block above (if sloped) - from poweredRailBlock updateState

 

The fix should ideally result in the following order: (Assuming the 2nd set of updates is not useful which I do not recall it is)

Block updates around 1 block above (if sloped), Block updates around rail, Block updates around 1 block below followed by Shape updates

If the 2nd set of updates do matter, then refer to the old update order detailed above.

[For image: Lowest is cmd block 1, Highest cmd block is 3; Expected is 3, 2, 1]

[media]