diff options
author | sofar <sofar@foo-projects.org> | 2019-04-27 16:42:13 -0700 |
---|---|---|
committer | Paramat <paramat@users.noreply.github.com> | 2019-04-28 00:42:13 +0100 |
commit | b839a6dd5425c334e6528ae230f05ca5b15cc3a1 (patch) | |
tree | 271ad95e162a62a1270ffb952a33c10387b70287 /build/android | |
parent | d71e1e09497a72f90c60ea6e651de629eb3a438b (diff) | |
download | minetest-b839a6dd5425c334e6528ae230f05ca5b15cc3a1.tar.gz minetest-b839a6dd5425c334e6528ae230f05ca5b15cc3a1.tar.bz2 minetest-b839a6dd5425c334e6528ae230f05ca5b15cc3a1.zip |
Force send a mapblock to a player (#8140)
* Force send a mapblock to a player.
Send a single mapblock to a specific remote player.
This is badly needed for mods and games where players are teleported
into terrain which may be not generated, loaded, or modified
significantly since the last player visit.
In all these cases, the player currently ends up in void, air, or
inside blocks which not only looks bad, but has the effect that the
player might end up falling and then the server needs to correct for
the player position again later, which is a hack.
The best solution is to send at least the single mapblock that the
player will be teleported to. I've tested this with ITB which does this
all the time, and I can see it functioning as expected (it even shows
a half loaded entry hallway, as the further blocks aren't loaded yet).
The parameter is a blockpos (table of x, y, z), not a regular pos.
The function may return false if the call failed. This is most likely
due to the target position not being generated or emerged yet, or
another internal failure, such as the player not being initialized.
* Always send mapblock on teleport or respawn.
This avoids the need for mods to send a mapblock on teleport or
respawn, since any call to `player:set_pos()` will pass this code.
Diffstat (limited to 'build/android')
0 files changed, 0 insertions, 0 deletions