Overview
When a sculk sensor outputs a signal, it is currently either 1, 15, or even. Odd signal strengths apart from 1 and 15 are never produced.
Even though blocks on the diagonals are technically further away from the sensor than those directly on the axes, it will still output the same (even) value for both blocks. This issue makes the sculk sensor slightly inaccurate, especially in regards to triangulation.
This happens because the sculk sensor can only receive 9 different integer inputs for how far away a vibration is, and as the equation to calculate what redstone signal to output is a function, you will never be able to get more than 9 outputs out.
This results in the observed behaviour of no odd outputs being produced apart from 1 and 15.
The following screenshot shows which distance currently outputs which signal strengths, and which signal strengths they would output if the sculk sensor could receive a range of distance values from 0-8 as opposed to a discrete set of 9 values. (Click to zoom:
[media])
Sculk Sensor Output Visualisation (desmos)
Code Analysis
The game calls on the distance value which is an integer
This integer can only have 9 values because the range of the sculk sensor is 8 blocks (0-8), meaning that the function can only output a maximum of 9 values:
public static int getPower({color:#de350b}*int*{color} {color:#57d9a3}distance{color}, int range) {
double d = (double){color:#57d9a3}distance{color} / (double)range;
return Math.max(1, 15 - MathHelper.floor(d * 15.0D));
{{}}}
The distance value seems to come from the SculkSensorListener class which initially comes from DistancePredicate and I am unsure as to how challenging it would be to calculate the distance as a double/float as opposed to an integer from the get-go.
Fix
The initial calculations for the distance value, wherever they are done, needs to be calculated as a double/float.
[media](The setup from this screenshot can be loaded via this structure file if you want to experiment with it yourself:
[media])
Video
This is a video showcasing a touchscreen display using sculk sensors, where this issue occurs in practice (two pixels cannot be distinguished from each other). The problem of the too imprecise outputs is mentioned and elaborated upon at the given timestamp.
Attachments
Comments 12
got an actual working solution solution now, had to stretch out the prior equation to get it to work in-game haha
hey so I did a bit more analysis on this report and it turns out there was rounding/data type changing happening, but it was in a different place to which i originally thought
i've updated the report with all the new info and the fix should be as simple as keeping the distance value as a double instead of converting it to an integer
Confirmed.
I've rewritten your bug report to make it a bit more straightforward and easy to understand – I hope I didn't mangle anything; feel free to fix it if I did.