Fix raycasting errors on unloaded chunks

[extremeheat]

Fix raycasting exceptions in async world when a chunk is unloaded, would previously result in undefined.getBlock(). Return undefined on getters where no cc is present.

https://github.com/PrismarineJS/prismarine-world/blob/master/src/world.js#L64

[rom1504]

This doesn't make sense to me.
The async API can never have unloaded chunks because they're generated or read from disk
The sync API can

Mineflayer uses sync, flying squid uses async

Raycast is defined based on the async API

Is raycast used in mineflayer? If yes it should had the sync API, or there should be a separate sync version

[extremeheat]

Yes so when reading chunks off of disk through prismarine-provider-anvil without a chunk generator the raycasting can fail on movement if you move the cursor somewhere where there isn’t a generated chunk. This can happen for example when reading a vanilla world through prismarine-viewer (reproducible through the electron prismarine viewer example)

[rom1504]

this is a breaking API change, currently the async api cannot return null
it should at least be documented

[extremeheat]

To make it not breaking what about returning air or 0? The alternative here is crashing on undefined property which is probably slower to handle. I believe the issue is with the raycast function below which is used in pviewer, it checks for undefined blocks but it doesn't catch the error in the getBlock() call

[rom1504]

something that would make this easier is doing #64
ie having only the sync API and handling null returns properly

if we merge this, we would need to change all calls to getBlock to handle null even with the async API, it doesn't seem like the best path

[rom1504]

returning air/0 might be ok I guess

[rom1504]

just to clarify: today getBlock() async is supposed to never error out and never return null
if this assumption is broken because we don't define generators then we need to change this assumption and this is a big change

[rom1504]

seems too old

[extremeheat]

yeah I don't remember the full context behind this, so if I visit anvil-provider again I'll revisit this