Las coordenadas negativas rompen el cálculo de chunks en dos sitios, no en uno
La división truncada coloca el bloque −1 en el chunk 0 en lugar del −1, y un % normal da un desplazamiento dentro del chunk de −1 en vez de 15. Ambos fallan, y ambos parecen correctos hasta que te alejas al oeste del spawn.
Todo cálculo de chunks es trivial en el cuadrante positivo y erróneo en los otros tres. Hay exactamente dos puntos donde falla, son independientes entre sí, y ambos producen respuestas que parecen plausibles.
Las dos operaciones
chunk = floor(block / 16) not trunc(block / 16)
offset = ((block % 16) + 16) % 16 not block % 16Las coordenadas de región son el mismo par, un nivel por encima, con 32 en lugar de 16:
region = floor(chunk / 32) -> r.<x>.<z>.mca
regionOff = ((chunk % 32) + 32) % 32Así que una región son 32 × 32 chunks, es decir, 512 × 512 bloques.
Dónde muerde cada una
La división. La mayoría de lenguajes truncan hacia cero, y floor redondea hacia menos infinito. Coinciden en los positivos y discrepan en todo negativo que no sea múltiplo exacto:
- bloque
−1→floor(−1/16) = −1✓, perotrunc(−1/16) = 0✗
El bloque −1 está un bloque al oeste del origen y pertenece al chunk −1. El truncamiento lo coloca en el chunk 0, junto al bloque +1. Todo índice de chunk negativo sale uno de más.
El resto. En JavaScript, Java, C y la mayoría de los demás, % conserva el signo del operando izquierdo:
- bloque
−1→ desplazamiento correcto15, pero−1 % 16 = −1✗
Un desplazamiento de −1 no es una posición dentro de un chunk de 16 de ancho. Indexar un array de bloques con él o bien lanza una excepción o bien lee en silencio la celda equivocada.
Un ejemplo desarrollado
Bloque −1290 en un eje:
| paso | correcto | ingenuo |
|---|---|---|
| chunk | floor(−1290/16) = −81 | trunc = −80 ✗ |
| desplazamiento en el chunk | 6 | −1290 % 16 = −10 ✗ |
| región | floor(−81/32) = −3 | trunc = −2 ✗ |
| desplazamiento en la región | 15 | −81 % 32 = −17 ✗ |
Cuatro valores, cuatro respuestas erróneas, ninguna lo bastante fuera de rango como para parecer obviamente rota. La región −3 abarca los chunks −96 a −65, y el chunk −81 queda 15 posiciones desde su inicio, que es exactamente lo que devuelve el resto corregido.
La conversión al Nether pierde información en una dirección
Del Overworld al Nether se divide entre 8, y también se aplica suelo:
netherX = floor(overworldX / 8)Al volver se multiplica tu posición exacta por 8, así que todo el bloque 125 del Nether se mapea de vuelta a algún punto entre 1000 y 1007, según dónde te sitúes dentro de ese bloque. Eso no es un viaje de ida y vuelta para coordenadas de bloque. floor descarta el resto:
- Overworld
1000→ Nether125→ de vuelta a1000✓ - Overworld
1007→ Nether125→ la coordenada de bloque dice1000✗ — siete bloques menos
El error es de 0 a 7 bloques por eje, así que hasta 7 en X y 7 en Z a la vez. Esa es toda la razón por la que un enlace preciso de portales exige anotar la coordenada del Nether en lugar de recalcularla: una vez has dividido, la posición del Overworld de la que provenía ya no es recuperable.
Para un hub del Nether esto rara vez importa — 7 bloques está dentro del propio radio de captura de un portal. Para enlazar dos portales que no deben robarse el tráfico entre sí, importa y mucho.
Las coordenadas negativas del Overworld lo empeoran de la forma habitual: el Overworld −1 da Nether floor(−1/8) = −1, mientras que el truncamiento da 0 y te envía al lado equivocado del eje.