Koordinat negatif merusak perhitungan _chunk_ di dua tempat, bukan satu
Pembagian terpotong menempatkan blok -1 di _chunk_ 0, bukan -1, dan tanda % biasa memberikan _offset_ dalam _chunk_ sebesar -1, bukan 15. Keduanya salah, dan keduanya terlihat benar sampai Anda pergi ke barat dari _spawn_.
Setiap perhitungan _chunk_ (_chunk calculation_) menjadi mudah di kuadran positif dan salah di tiga kuadran lainnya. Ada tepat dua tempat di mana perhitungan itu salah, keduanya independen satu sama lain, dan keduanya menghasilkan jawaban yang terlihat masuk akal.
Dua operasi
chunk = floor(block / 16) not trunc(block / 16)
offset = ((block % 16) + 16) % 16 not block % 16
Koordinat _region_ adalah pasangan yang sama, satu tingkat di atas, dengan 32 alih-alih 16:
region = floor(chunk / 32) -> r.<x>.<z>.mca
regionOff = ((chunk % 32) + 32) % 32
Jadi, satu _region_ adalah 32 × 32 _chunk_, yaitu 512 × 512 blok.
Di mana setiap operasi bermasalah
Pembagian. Sebagian besar bahasa memotong ke arah nol, dan floor membulatkan ke arah ketakberhinggaan (negative infinity). Keduanya setuju untuk bilangan positif dan tidak setuju untuk setiap bilangan negatif yang bukan kelipatan persis:
- blok
−1→floor(−1/16) = −1✓, tetapitrunc(−1/16) = 0✗
Blok -1 adalah satu blok di sebelah barat titik asal dan termasuk dalam _chunk_ -1. Pemotongan menempatkannya di _chunk_ 0, bersama blok +1. Setiap indeks _chunk_ negatif keluar satu terlalu tinggi.
Sisa. Dalam JavaScript, Java, C, dan sebagian besar bahasa lainnya, % mempertahankan tanda operan kiri:
- blok
−1→ _offset_ yang benar15, tetapi−1 % 16 = −1✗
_Offset_ -1 sama sekali bukan posisi di dalam _chunk_ selebar 16. Mengindeks larik blok dengannya akan memunculkan kesalahan (_throw_) atau secara diam-diam membaca sel yang salah.
Contoh yang dikerjakan
Blok -1290 pada satu sumbu:
| langkah | benar | naif |
|---|---|---|
| _chunk_ | floor(−1290/16) = -81 | trunc = -80 ✗ |
| _offset_ dalam _chunk_ | 6 | −1290 % 16 = -10 ✗ |
| _region_ | floor(−81/32) = -3 | trunc = -2 ✗ |
| _offset_ dalam _region_ | 15 | −81 % 32 = -17 ✗ |
Empat nilai, empat jawaban salah, tidak ada yang cukup di luar jangkauan untuk terlihat jelas rusak. _Region_ -3 membentang dari _chunk_ -96 hingga -65, dan _chunk_ -81 berada 15 dari awal — yang persis seperti yang dikembalikan oleh sisa yang dikoreksi.
Konversi Nether bersifat _lossy_ dalam satu arah
Dari Overworld ke Nether dibagi 8, dan juga dibulatkan ke bawah (_floor_):
netherX = floor(overworldX / 8)
Kembali dikalikan 8. Itu bukan perjalanan pulang-pergi. floor membuang sisanya, sehingga kembali mendaratkan Anda pada kelipatan 8:
- Overworld
1000→ Nether125→ kembali ke1000✓ - Overworld
1007→ Nether125→ kembali ke1000✗ — tujuh blok kurang
Kesalahannya adalah 0 hingga 7 blok per sumbu, jadi hingga 7 pada X dan 7 pada Z sekaligus. Itulah seluruh alasan mengapa penautan portal yang tepat memerlukan koordinat Nether yang dituliskan daripada diturunkan ulang: setelah Anda membagi, posisi _overworld_ dari mana ia berasal tidak lagi dapat dipulihkan.
Untuk _hub_ Nether, ini jarang menjadi masalah — 7 blok berada di dalam radius tangkap portal itu sendiri. Untuk menautkan dua portal yang tidak boleh saling mencuri lalu lintas, ini sangat penting.
Koordinat _overworld_ negatif memperburuknya dengan cara yang sama: _overworld_ −1 memberikan Nether floor(−1/8) = −1, sementara pemotongan memberikan 0 dan mengirim Anda ke sisi sumbu yang salah.