| Time |
Nick |
Message |
| 00:33 |
|
Seirdy joined #minetest-dev |
| 02:12 |
|
h_p__ joined #minetest-dev |
| 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 |
| 04:42 |
|
ShadowBot joined #minetest-dev |
| 04:47 |
|
BakerPrime joined #minetest-dev |
| 05:04 |
|
fluxflux joined #minetest-dev |
| 05:24 |
|
ShadowBot joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:19 |
|
Zoe_S17 joined #minetest-dev |
| 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 |
<Genshin> rubenwardy, hope this helps https://notabug.org/Genshin/cheat_detection/src/master/init.lua |
| 08:44 |
|
cheapie joined #minetest-dev |
| 08:44 |
pgimeno |
rubenwardy: Sorry, my bad. At the Lua API level they are in extrinsic ZXY order. |
| 08:47 |
|
skyliner_369 joined #minetest-dev |
| 09:33 |
|
calcul0n joined #minetest-dev |
| 11:04 |
|
Fixer joined #minetest-dev |
| 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 |
<srinivas> no, it doesnt |
| 11:23 |
MTDiscord |
<srinivas> you are not allowed to use singleplayer iirc |
| 11:23 |
MTDiscord |
<srinivas> oh, it does |
| 11:24 |
MTDiscord |
<srinivas> interesting, im on a 5.4 dev client |
| 11:25 |
MTDiscord |
<srinivas> wait, it changes |
| 11:25 |
zughy[m] |
I just did |
| 11:25 |
MTDiscord |
<srinivas> on some servers i was able to connect, on others, i wasnt |
| 11:26 |
zughy[m] |
5.3 here |
| 11:26 |
MTDiscord |
<srinivas> 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 |
<srinivas> 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:27 |
|
proller joined #minetest-dev |
| 11:28 |
rubenwardy |
The Prejoin callback allows you to deny a username access without ever creating an account |
| 11:28 |
MTDiscord |
<srinivas> oh? |
| 11:29 |
MTDiscord |
<srinivas> ah got it... thanks |
| 11:50 |
|
calcul0n_ joined #minetest-dev |
| 12:08 |
|
T4im joined #minetest-dev |
| 12:23 |
|
T4im joined #minetest-dev |
| 13:15 |
|
Wuzzy joined #minetest-dev |
| 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:06 |
|
NetherEran joined #minetest-dev |
| 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:09 |
|
fluxflux joined #minetest-dev |
| 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 |
|
benrob0329 joined #minetest-dev |
| 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 |
<Jordach> Not anyone’s problem here but the fork |
| 19:06 |
|
Taoki joined #minetest-dev |
| 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:53 |
|
lhofhansl joined #minetest-dev |
| 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. |
