minetest.register_on_joinplayer weirdness

[Wuzzy]

The minetest.register_on_joinplayer confuses me a lot.
It seems a lot of functions don’t work when called in this callback.

For example, all hud_ calls do not change anything.
However, if I wrap this stuff in a minetest.after(0, …) it, the HUD is manipulated.

set_physics_override also does not work in this callback.
A minetest.after(0, …) does not help here. I need to go up to 1s to make it work. But this is an extremely ugly hack and I am not sure if it is even reliable.

I suspect that other functions also don’t work when called in this callback.

I need a callback where I have a useful player object which I can fully manipulate. This means, the player has just joined and the player object is inside the world and all player functions are now meaningful. Right after that moment, that callback shall fire. Sadly, register_on_respawnplayer does only fire on respawns, but not for spawn right after the join.
register_on_newplayer sounds promising but I don’t know what it means. What is a “new” player? When exactly does this callback fire?

The register_on_joinplayer function does not seem to provide a fully manipulatable player object, given from my experience. This makes the callback very annoying to use to me.

If there are restrictions for register_on_joinplayer, I want to know which restrictions exist. If you know it, please tell me what I can do with the player object in this callback and which functions I cannot call.
What are the alternatives to register_on_joinplayer?

I am using 0.4.9.
If you can answer any of my questions, please help me. Please also tell me if you have experienced similar problems.

[webdesigner97]

In my minetest build (minetest-0.4.9-x64-dev20140618), this works perfectly. I can override physics and change the HUD directly from with on_joinplayer()...

Edit: on_newplayer() gets called, when a player joins the first time.

[Wuzzy]

OK, thank you. I can successfully reproduce this. I am switching to the development branch then.

PS: Regarding the new player callback: How is “new” defined? How does the server know that one player is known and another player is not known? Same IP adresses? Same name? Something else?

[prestidigitator]

I think also that using minetest.after() in older versions should always produce a reliable callback. By the time Lua gets to do anything after the on_joinplayer event, the player should be ready to go. What you could do in a on_joinplayer event callback itself would be to setup anything that needed to be indexed by player name or object reference, in addition to calling minetest.after().

You could actually create your own little callback mechanism like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local playerReadyCallbacks = {};

local isCallable(func)
   if not func then
      return false;
   elseif type(func) == "function" then
      return true;
   else
      local meta = getmetatable(func);
      return isCallable(meta and meta.__call);
   end
end

local function firePlayerReadyCallbacks(player)
   for _, func in ipairs(playerReadyCallbacks) do
      func(player);
   end
end

function addPlayerReadyCallback(func)
   assert(isCallable(func), "playerReady callback must be callable");

   if not next(playerReadyCallbacks) then
      minetest.register_on_joinplayer(
         function(player)
            minetest.after(0, firePlayerReadyCallbacks, player);
         end);
   end

   table.insert(playerReadyCallbacks, func);
end


and use it like:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

addPlayerReadyCallback(function(player) ... end);


(All code in this post is WTFPL.)

[Wuzzy]

I appreciate you enthusiasm, but lol, I don’t see the point of writing a new callback if all I have to is to call minetest.after(0, foo, bar). ;-)

[prestidigitator]

I appreciate you enthusiasm, but lol, I don’t see the point of writing a new callback if all I have to is to call minetest.after(0, foo, bar). ;-)

Well, the point is that if you have to do it once, fine. If you have to do it twice, fine. But after that, make it easier on yourself.

From what you said you wanted a callback with access to all player features. If you don't have one, build it. By the look of it most of the Lua API has been cobbled together on that principle anyway. ;-)

[stu]

The minetest.register_on_joinplayer confuses me a lot.
It seems a lot of functions don’t work when called in this callback.

For example, all hud_ calls do not change anything.
However, if I wrap this stuff in a minetest.after(0, …) it, the HUD is manipulated.

set_physics_override also does not work in this callback.
A minetest.after(0, …) does not help here. I need to go up to 1s to make it work. But this is an extremely ugly hack and I am not sure if it is even reliable.

I suspect that other functions also don’t work when called in this callback.

This problem has been reported before and there is still no 100% reliable solution.
minetest.after works fine in singleplayer mode, however, delays of over 10 seconds
have been reported to be insufficient on busy servers.

viewtopic.php?f=5&t=8073

My workaround in the 3d_armor mod is to repeat the initialization a configurable
number of times with configurable delays, ugly but I have had very few reported
initialization glitches since it was added.