HELP! Give us your opinion on the balance of beacon compactness?

I stated earlier, the current system is: count of plot-columns against count of empty plot-columns within 2 plots of your beacon (matching the way reservations work). more specifically sqrt(plot-columns) against count of empty plot-columns (with some scaling to make squares 1.0, and extra power-scaling for nicety - but that doesnt effect the thresholding, only what specific value the thresholding is set at)

also looked at how it would behave with only counting “plots adjacent” - but this has weird behaviour where funky shapes end up with the same compactness as a square; and also counting the “true” perimeter which doesnt have any weird behaviour, but felt the 2-plot counting was both more consistent with reservation rules, and made “sense” that a tightly packed S curve is more compact than a loosely packed S curve.

any rule here has to be efficient on the server; eg with just “counting” it can be done via deltaing on each plot/add so that there is never a point in time where you have to “iterate the entire beacon” etc, so is super cheap.

2 Likes