Astrobe wrote: ↑Tue Aug 02, 2022 17:47
Nah... "Nobody needs" 32Km above and 32Km below. There's no option to offer outside of "how many".
The SI "metric system" unit symbol for kilometre is km. You should also leave a space between the unit value and the symbol.
m = metre
K = Kelvin
k = thousands prefix
32,000 metres = 32 kilometres = 32 km
Another example to help you understand SI
Watts / (metres * Kelvin) -> W/m·K - notice the dot, which stands for multiplication but also helps to separate units where confusion may occur due to m being a unit prefix and a unit.
You should not let the fact that k is not uppercase despite being more than the base unit disturb you. Just think, every prefix above k is uppercase. Also the kilogram is the base unit of mass. The SI has strict rules, and following them greatly aids communication in science, trade and international communications. Breaking the rules brings us back to the dark age of a plethora of non-standard units and symbols. These are
the rules, not your rules.
Astrobe wrote: ↑Tue Aug 02, 2022 17:47
I guess most would be alright with only 8Km (16Km total), that's two bits you can reallocate to double the "length" of the two other axis.
...
You have not understood the main crux of the argument: The complexity it takes to store coordinates in Minetest's world database in the first place. The coordinates are packed together into a 64-bit integer. Each coordinate is 16 bits; the 64-bit container limits the total size to about 20 bits for each coordinate.
The fact that all three coordinates are constant size is an important point of simplicity. The functions that unpack this 64-bit structure into 3 16-bit values are:
Code: Select all
def getBlockAsInteger(p):
return int64(p[2]*16777216 + p[1]*4096 + p[0])
def int64(u):
while u >= 2**63:
u -= 2**64
while u <= -2**63:
u += 2**64
return u
def getIntegerAsBlock(i):
x = unsignedToSigned(i % 4096, 2048)
i = int((i - x) / 4096)
y = unsignedToSigned(i % 4096, 2048)
i = int((i - y) / 4096)
z = unsignedToSigned(i % 4096, 2048)
return x,y,z
def unsignedToSigned(i, max_positive):
if i < max_positive:
return i
else:
return i - 2*max_positive
What you are suggesting is that we take those constants 16777216 & 4096 and make them variables. This would entail recording how many bits are assigned to each coordinate for all coordinates in the local database, and keeping that in mind when unpacking the coordinates.
Code: Select all
def getIntegerAsBlock(i):
x = unsignedToSigned(i % 2**(x_bits), 2**(x_bits-1))
i = int((i - x) / 4096)
y = unsignedToSigned(i % 2**(y_bits), 2**(y_bits-1))
i = int((i - y) / 4096)
z = unsignedToSigned(i % 2**(z_bits), 2**(z_bits-1))
return x,y,z
Intuition tells me this is going to have worse performance, even if we use a closure. Furthermore, we have not gained spaced, only rearranged it. We have also broken compatibility with any program outside minetest that reads its mapblock format, requring it to reimplement the more complex algorithm. I therefore put it to you that if we must introduce such a breaking change, we should at least not do it a way that will be compromised: we should increase the world size drastically if we are going to change the mapblock format at all.
Speaking of them, I believe that popular servers with infinite world size would collapse under their own weight - computer resources are never infinite - so that they would eventually disable it in a way or another.
Storage space is not too terribly expensive in the scheme of things, it's just a lot of servers are running in cheap VPS with only a small allocated storage amount in the plan. We already have a setting to disable generating the world beyond a certain area; that is how people do reduce the available area already. However, that doesn't mean that if the world's potential size got larger they'd decide to still limit it to less than 60,912. They might well decide to limit it to 100,000 or 250,000.