MC-261657Sculk sensor range is still spherical, creating different outputs from within a given block
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (this minecraft diagram was made by the developer responsible for the sculk sensors so it's clear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range (not to scale), and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
Also if the location of vibration gets floored to a position that is outside of the current circular range, then the sculk sensor will activate when in reality it shouldn't as once the new, floored position is moved out of the range, the sculk output should be 0.
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Linked Issues
Created Issue:
Sculk sensor range is still circular, creating different outputs from within a given block
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks where made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here's the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk ur able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Attachments3
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks w
here made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block.To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here's the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk ur able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here
'sthe dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk ur able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk
urable to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:variable outputs per block - not intended as of 23w14a.mp4
And this is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block
.To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (the minecraft diagram was made by the developer responsible for the sculk sensors so it's quite clear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (th
eminecraft diagram was made by the developer responsible for the sculk sensors so it'squiteclear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (this minecraft diagram was made by the developer responsible for the sculk sensors so it's clear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range, and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (this minecraft diagram was made by the developer responsible for the sculk sensors so it's clear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range (not to scale), and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
MC-261657 Visulaisation.png
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (this minecraft diagram was made by the developer responsible for the sculk sensors so it's clear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range (not to scale), and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Currently sculk sensors ignore vibrations outside of the sculk sensor range, even when the floored position is within the range, leading to different sculk outputs for a single block.
This behaviour contradicts the recent changes in 23w14a where sculks were made to produce the same outputs for anywhere within one block by flooring the vibration position values within that block:
The coloured blocks in game show where the sculk should be sensing vibrations (this minecraft diagram was made by the developer responsible for the sculk sensors so it's clear that these edge blocks should be included within the red detection range of the sculk sensor) and the red circle shows exactly where the sensor stops detecting vibrations.
To fix this, the vibration position should be floored to a blockpos value before the game checks to see if it was within the range. Or depending on how the code works, the range should be changed from circular to something more blocky like this:
Here the dotted cyan line represents the current implementation of the sculk sensor range (not to scale), and the outer magenta line represents a proposed solution that would remove the variable outputs for all the blocks at the very edge of the sculks range (currently an output of 1 signal strength if the vibration occurs between the orange and cyan line, and an output of 0 in case it occurs between the cyan and magenta line)
Also if the location of vibration gets floored to a position that is outside of the current circular range, then the sculk sensor will activate when in reality it shouldn't as once the new, floored position is moved out of the range, the sculk output should be 0.
The below video gives an example of these variable outputs taken to the extreme. If you create a vibration in the dead centre of a slab 16 blocks above a sculk sensor, you're able to activate it, but if you move just 0.0000001686 blocks in any direction, then you won't be able to trigger that sculk anymore:
variable outputs per block - not intended as of 23w14a.mp4
And this last video is just a visualisation of how small this area is where you're able to activate one sculk sensor, note this is just showing this effect with a vertical distance, but a similar thing can be done by going 16 blocks away from a sculk sensor and jumping on the back of a block vs the front, at the back you don't get an input but at the front of the block you do.
small detection range to activate a sculk from 16 blocks away.mp4
Sculk sensor range is stillcircular, creating different outputs from within a given blockSculk sensor range is still spherical, creating different outputs from within a given block
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
relates to
![[Mojang] Moesh](../../../data/avatars/users/10122.svg){kind=small}
Normal![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
[Mojang] GnembonThis bug is due to the fact that entities have a discrepancy between the original location of the vibration (centred on the bottom of their hitbox) and the floored value that the sculk actually uses for calculations (the centre of the block that the entity is in), unlike blocks which both create a vibration at the centre of the air block they replace, and so flooring that doesn't change anything.
Now within the range of the sculk sensor, the original location position is floored so all vibrations are rounded to the centre of the block they occured in meaning that there is no difference in behaviour between entities and blocks, but if an entity had its original location positioned just outside of the range, e.g. at the bottom of a block 8 blocks away, even though its floored position would've been rounded 'up' into the range of the sculk sensor, this never occurs as the sculk sensor ignores it.
I discuss this in more detail and with diagrams in this updated bug report here: MC-261657