aboutsummaryrefslogtreecommitdiff
path: root/builtin/client
diff options
context:
space:
mode:
authorsofar <sofar@foo-projects.org>2019-04-27 16:42:13 -0700
committerParamat <paramat@users.noreply.github.com>2019-04-28 00:42:13 +0100
commitb839a6dd5425c334e6528ae230f05ca5b15cc3a1 (patch)
tree271ad95e162a62a1270ffb952a33c10387b70287 /builtin/client
parentd71e1e09497a72f90c60ea6e651de629eb3a438b (diff)
downloadminetest-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 'builtin/client')
0 files changed, 0 insertions, 0 deletions