Time  Nick       Message
02:39 rubenwardy are object rotations documented anywhere?
02:43 rubenwardy are they XYZ or ZYX order?
02:44 rubenwardy Will Irrlicht rotations work with them?
03:04 rubenwardy #10547
03:04 ShadowBot  https://github.com/minetest/minetest/issues/10547 -- Check interact direction to prevent some cheats by rubenwardy
08:39 pgimeno    <rubenwardy> are they XYZ or ZYX order?  <--  It depends at what level. At the Lua API level they are in extrinsic XYZ order. At the network level probably too, but I can't remember for sure.
08:39 pgimeno    <rubenwardy> Will Irrlicht rotations work with them?  <--  No.
08:39 MTDiscord  <G​enshin> rubenwardy, hope this helps https://notabug.org/Genshin/cheat_detection/src/master/init.lua
08:44 pgimeno    rubenwardy: Sorry, my bad. At the Lua API level they are in extrinsic ZXY order.
11:08 zughy[m]   is it normal I can call myself "singleplayer" in a server?
11:08 zughy[m]   Like, being the default nick, shouldn't it be prohibited?
11:12 sfan5      aside from perhaps confusing other people there's nothing that can happen
11:13 sfan5      if a mod does comparisons like player:get_player_name() == "singleplayer" instead of using the intended APIs that's their fault
11:21 rubenwardy I have a feeling Minetest doesn't allow you to join with that
11:22 MTDiscord  <s​rinivas> no, it doesnt
11:23 MTDiscord  <s​rinivas> you are not allowed to use singleplayer iirc
11:23 MTDiscord  <s​rinivas> oh, it does
11:24 MTDiscord  <s​rinivas> interesting, im on a 5.4 dev client
11:25 MTDiscord  <s​rinivas> wait, it changes
11:25 zughy[m]   I just did
11:25 MTDiscord  <s​rinivas> on some servers i was able to connect, on others, i wasnt
11:26 zughy[m]   5.3 here
11:26 MTDiscord  <s​rinivas> so far, minecity fun server and aurelium have disallowed it
11:26 sfan5      it's likely that popular name restriction-like mods disallow it
11:27 MTDiscord  <s​rinivas> err, dont they normally use minetest.kick_player then?
11:27 rubenwardy Ahh, I use those mods
11:27 rubenwardy They should use prejoin
11:28 rubenwardy The Prejoin callback allows you to deny a username access without ever creating an account
11:28 MTDiscord  <s​rinivas> oh?
11:29 MTDiscord  <s​rinivas> ah got it... thanks
15:24 pgimeno    so is this check failing? https://github.com/minetest/minetest/blob/master/src/network/serverpackethandler.cpp#L181
15:25 pgimeno    it works in 0.4.16
15:47 rubenwardy #10174
15:47 ShadowBot  https://github.com/minetest/minetest/issues/10174 -- Fix segfault in deprecation logging due tail call, log by default by rubenwardy
15:51 Wuzzy      #10431
15:51 ShadowBot  https://github.com/minetest/minetest/issues/10431 -- Fix long infotext letter cutoff, add ellipsis by Wuzzy2
15:52 rubenwardy hmm
15:53 rubenwardy I've been meaning to implement a statictext node that does this culling automatically, it's cleaner and reusable
15:53 rubenwardy ie: for the ContentDB GUI, I want the descriptions to wrap and then truncate with ellipsis
16:13 rubenwardy updated #10085 with a unit test
16:13 ShadowBot  https://github.com/minetest/minetest/issues/10085 -- Use JSON for favorites, move server list code to Lua by rubenwardy
16:32 Krock      10174. even if it generates plenty new functions and results in one layer of a function call overhead, it looks quite simple and avoids a hash table lookup. cool.
16:33 rubenwardy the cost of a function call will be less than a hash table look up
16:33 Krock      an earlier approach I've seen was about calling a macro in each deprecated functions to register a new function there. the lambda expression gets rid of this clobber
16:33 Krock      exactly
16:34 rubenwardy I saw that too, I didn't like it
16:34 Krock      though wouldn't "[](lua_State *L) -> int"  be more correct?
16:36 rubenwardy it implicitly does ->int, I can add it anyway
16:36 sfan5      is using lambdas this way even supported by c++?
16:37 Krock      yes, it's statically initialized
16:37 sfan5      I guess it is because those end up in a static global variable
16:37 rubenwardy I do this in other projects as an alternative to std::bind
16:37 rubenwardy hmm, although that would be using std::function
16:37 rubenwardy which copies
16:38 sfan5      copies what?
16:38 Krock      ikr that ->int is implicitly done but I'd prefer to make it clear that there's an integer return value. also funny errors would arise if someone changed the l_deprecated_function return value type by accident :3
16:39 rubenwardy ok, done
16:39 Krock      thanks. testing.
16:39 Krock      I've had this on my ToDo-but-never-actually-do-it-list for too long
16:40 rubenwardy :D
16:42 Krock      okay. the error is fixed but the unique line detection doesn't work for tail-call optimized situations
16:42 Krock      example. revert https://github.com/minetest-mods/mg/commit/a093b785a
16:43 Krock      the log points to the parent function of the deprecated function, hence pointing at a wrong position. I don't think there's much we could do about this, though.
16:45 Krock      rubenwardy: where do you call func(L)?
16:46 Krock      s/.*//
16:47 rubenwardy At the bottom of that function
16:47 Krock      yes. I saw that too just after asking. I though the function returned where the red part started
17:13 pgimeno    the singleplayer check is working for me in current master, I wonder how some servers bypass it
17:31 pgimeno    tried server separate from client, same result. The client gives an error window: "Access denied. Reason: Player name not allowed." The server reports: 2020-10-24 19:28:58: ACTION[Server]: Server: Player with the name "singleplayer" tried to connect from 10.0.0.4
17:32 pgimeno    so I'm puzzled at how some servers can bypass that. Is there something a server can do to work around that check?
17:35 Krock      are there reports where singleplayer was possible?
17:40 pgimeno    yes, just a few hours ago
17:41 pgimeno    http://irc.minetest.net/minetest-dev/2020-10-24#i_5745782
17:47 Krock      hard to believe
17:50 pgimeno    I'm trying to check if a prejoin or join callback could bypass that
17:51 pgimeno    if I did the test correctly, no it doesn't bypass it
17:54 pgimeno    and well, two people confirmed it
18:00 pgimeno    is it possible that this check is failing on some servers? bool isSinglePlayer() const { return address.empty() && !local_server; }
18:11 pgimeno    shouldn't the local_server check be the other way around?
18:12 pgimeno    it's a single player game when the server is a local server and the address isn't set, right?
18:41 zughy[m]   the server is multicraft, flat world. You can log with "singleplayer" and no password
18:42 zughy[m]   but yeah, others block me
18:43 MTDiscord  <J​ordach> Not anyone’s problem here but the fork
20:51 Krock      WARNING[Main]: core.env:[...] is deprecated and should be replaced with core.[...] (at <irrelevant>)  -- this currently causes a segfault when using the error deprecation level
20:52 Krock      both, in PR and master. needs fixing somehwne
21:59 lhofhansl  I just noticed that RemoteClient::m_blocks_modified (clientiface.cpp) grows without bounds. The entire logic between m_blocks_sending, m_blocks_sent, and m_blocks_modified is very suspect and fraud with error.
22:06 lhofhansl  Added with #3713
22:06 ShadowBot  https://github.com/minetest/minetest/issues/3713 -- Resend blocks when modified while sending to client by Jeija
22:09 lhofhansl  The original code is wrong. Eventually all blocks will be marked as modified and no blocks are marked as sent and will be sent over and over again. In addition the logic is inverted: Only when a block is modified will it be marked as sent later... It should be the reverse... If the block was not modified since we started to send it it's OK to mark it as sent.
22:12 lhofhansl  (Scratch the last... The logic is not inverted)
22:15 lhofhansl  I think we should only mark a block a block as modified this way when it is currently sending, that is the race we want to guard against.
22:28 jonadab    Shouldn't you mark it as _not_ modified since it was last sent, when you are sending it?
22:30 lhofhansl  This is for the race between (1) the server deciding to send it, (2)  the client receiving it, and (3) the server then marking it as sent. If the block has changed on the server between (1) and (3) again, then it should not be marked as sent.
22:42 jonadab    Ah, right.
22:42 lhofhansl  The naming a weird too. "sent" means the server assumes the client has it, when it is modified the block is removed from the sent list. But if the block was in transition is might be removed from the sent list, then the client gets the old version and the server will happily mark it as sent.
22:42 jonadab    Yeah, any time it changes, it should get marked as modified again.
22:42 lhofhansl  (very confusing logic and naming, IMHO)
22:43 lhofhansl  any it changes *and* it is in transit.