- The following events have been added:
- PlayerToggleGlideEvent
- PlayerToggleSwimEvent
- The following API methods have been added:
- Entity->getSize()
- Living->isSwimming()
- Living->setSwimming()
- Living->isGliding()
- Living->setSwimming()
- Player->toggleSwim()
- Player->toggleGlide()
- Added the following API methods:
- `Player::hasBlockCollision()`
- `Player::setHasBlockCollision()`
This enables spectator-like noclip behaviour in other gamemodes (could be useful for builders).
if a chunk was requested for generation, count++ and count(activeRequests)++, which means that we would only get to submit half as many generation requests as we're allowed to.
Calculate the limit at the start and remember it instead.
we don't want to allow sending further chunks when we haven't generated near ones, because we won't be able to see them anyway, and we might end up not needing them.
This now fully matches the results of PM3.
this fixes the horrible spotty chunk loading seen in https://twitter.com/dktapps/status/1456397007946461190?s=20.
In practice, this made chunks invisible on teleport for several tens of seconds after teleporting. Having a larger chunks-per-tick with large render distance compounded to worsen the problem.
It wasn't really noticeable on small render distances, but very obvious on large ones with fast chunk sending and slow generation.
This also fixes#4187 (at least to the extent that it works on PM3, anyway).
this can happen especially on large render distances when flying fast and changing direction - we decide we don't want the chunk, then, after changing direction and re-ordering chunks, we decide we do want it again, and end up registering a second callback. In this case, we need to ensure that only one of the callbacks gets executed (it doesn't matter which one).
This reverts commit 866020dfdb.
For some fucking reason this broke resending chunks in some cases (and
sending chunks at all in others). I don't have time to debug this right
now, so it's going to have to remain broken, infuriatingly enough.
back when this was just hardcoded >> 4 everywhere, nobody thought anything of it, but now it uses constants, it's easy to cross-reference and see where the duplicates are.
isChunkGenerated() merely checks if the chunk can be loaded from disk, if it's not in the runtime cache already.
This is pointless in all of these cases, because the check is prefaced by an isChunkLoaded() check, which already limits the possibility anyway. If the chunk is not generated, it'll also be considered not loaded.
this allows entities to exist outside of generated chunks, with one caveat: they won't be saved in such cases.
Obviously, for player entities, this doesn't matter.
fixes#3947
