| Time |
Nick |
Message |
| 00:55 |
|
cataraaa joined #minetest |
| 00:55 |
EISHU |
hi |
| 00:56 |
MTDiscord |
<jordan4ibanez> Hey EISHU |
| 01:09 |
|
smk joined #minetest |
| 01:53 |
|
Noisytoot joined #minetest |
| 03:59 |
|
illwieckz joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 06:09 |
|
bodiccea joined #minetest |
| 06:34 |
|
YuGiOhJCJ joined #minetest |
| 06:44 |
|
definitelya joined #minetest |
| 07:31 |
|
calcul0n joined #minetest |
| 07:47 |
|
iamweasel joined #minetest |
| 07:57 |
|
Sobinec joined #minetest |
| 07:59 |
|
jaca122 joined #minetest |
| 07:59 |
|
amfl2 joined #minetest |
| 08:03 |
|
lemonzest joined #minetest |
| 08:27 |
|
dabbill joined #minetest |
| 08:29 |
|
diceLibrarian joined #minetest |
| 08:33 |
|
Talkless joined #minetest |
| 08:35 |
|
dabbill_ joined #minetest |
| 09:08 |
|
xBarkDog joined #minetest |
| 09:17 |
celeron55 |
warr1024: probably the client starts sending player positions or something immediately along with the last initialization packet and those can end up being received in whatever order. from the server's standpoint a position packet from a partially initialized client isn't valid |
| 09:19 |
celeron55 |
that's what you get when using udp to minimize latency |
| 09:19 |
celeron55 |
to me that mostly seems like proof the udp protocol is doing its job |
| 09:29 |
|
s20 joined #minetest |
| 09:49 |
|
TomTom joined #minetest |
| 09:54 |
|
mrkubax10 joined #minetest |
| 09:58 |
|
Baytuch| joined #minetest |
| 10:08 |
MTDiscord |
<jordan4ibanez> can we call globalstep on_tick instead? |
| 10:09 |
MTDiscord |
<jordan4ibanez> Just thought I'd ask because I'm writing the basis for that portion |
| 10:14 |
celeron55 |
well that's what i'd call it nowadays, or on_step or whatever. doesn't seem like a big deal though |
| 10:20 |
Mantar |
I am in favor of things that are both clear and require less typing. |
| 10:29 |
|
Niklp9 joined #minetest |
| 10:42 |
|
definitelya joined #minetest |
| 11:21 |
|
jaca122 joined #minetest |
| 11:53 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Allow running individual benchmarks e5a6048 https://github.com/minetest/minetest/commit/e5a6048eeca3050246911f0ebb40d7546905ab2b (2023-12-16T11:51:42Z) |
| 11:53 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Try to benchmark common MapBlock usage 2c2bc4a https://github.com/minetest/minetest/commit/2c2bc4a4273e91cd6c502e273be9192e42256c9c (2023-12-16T11:51:42Z) |
| 11:53 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Allocate data seperately from MapBlock class again cb6e3ac https://github.com/minetest/minetest/commit/cb6e3ac6e17e04aac1e13b6256305d7dd7946102 (2023-12-16T11:51:42Z) |
| 11:53 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Change MapBlock content cache to a vector c6cf90f https://github.com/minetest/minetest/commit/c6cf90f67b51730cd833462135df197746f09b8c (2023-12-16T11:51:42Z) |
| 11:53 |
MinetestBot |
[git] (5 newer commits not shown) |
| 12:13 |
|
Talkless joined #minetest |
| 12:20 |
|
Baytuch| joined #minetest |
| 12:22 |
|
appguru joined #minetest |
| 12:55 |
|
beanzilla joined #minetest |
| 13:06 |
|
MTDiscord1 joined #minetest |
| 13:06 |
|
peterz joined #minetest |
| 13:08 |
|
Baytuch| joined #minetest |
| 13:18 |
|
Baytuch| joined #minetest |
| 13:29 |
|
Baytuch| joined #minetest |
| 14:11 |
MTDiscord |
<warr1024> celeron55: if it's doing its job then the message probably shouldn't be at "error" severity, or even present then... |
| 14:12 |
MTDiscord |
<warr1024> Actually if those really ARE position updates then it makes me wonder if this is the cause of the "teleport revert" error. |
| 14:12 |
celeron55 |
you can surely do a long discussion in general about how invalid stuff coming from the network should be logged |
| 14:12 |
celeron55 |
you can't locally enforce that whatever comes in would be valid and the client you're talking with could be anything |
| 14:13 |
celeron55 |
and the packets could probably be injected by someone |
| 14:13 |
celeron55 |
and the network can sometimes have crazy timings |
| 14:15 |
celeron55 |
maybe no errors or even warnings should be given about any packets that are send without the reliability layer |
| 14:15 |
celeron55 |
sent* |
| 14:15 |
MTDiscord |
<warr1024> The question is who the audience is for error and warning messages, but the only really possible answer is server operators, since they're the ones who actually see them, and there's no way to route them to engine devs. So if you have a warning or error message, it means either the server owners need to fix something, or they need to report a bug and get it fixed in the engine. |
| 14:16 |
celeron55 |
sometimes in development you need the visibility to stuff like that though |
| 14:16 |
celeron55 |
a very low logging level could achieve that |
| 14:16 |
celeron55 |
or, i mean, low in terms of importance |
| 14:16 |
MTDiscord |
<warr1024> If a packet arriving out of order is expected then it should be info or verbose. Raising it to warning or higher and bringing it to a person's attention implies that some action is needed, whether it being changing the protocol, or just changing the message severity. |
| 14:17 |
celeron55 |
verbose, probably |
| 14:17 |
celeron55 |
if not trace |
| 14:17 |
celeron55 |
but you need to be extra careful not to put packets that are not expected to arrive out of order into that bucket |
| 14:18 |
MTDiscord |
<warr1024> It seems to me like it could indicate an actual bug though, since position updates don't ack updates made by the engine. This could be why player:set_pos fails randomly for high latency players. |
| 14:18 |
MTDiscord |
<warr1024> .s/engine/server/ |
| 14:19 |
celeron55 |
i think it's natural that logging levels live during the lifetime of software. once something has been in use for a long time and the strong and weak parts surface and the responsibilities of people change, you should adjust levels to match |
| 14:21 |
celeron55 |
that does sound like one possibility for a bug. position updates might need an added "teleport counter" that the client gets from the server and echoes to the server along with position info so that the server can ignore positions based on old teleports (or more technically any movement that bases on an old set_pos" |
| 14:21 |
celeron55 |
)* |
| 14:23 |
celeron55 |
it's very similar to this case, possibly. this case is about the fact that the client is sending a position to the server but the server hasn't (in its own opinion) given the client the "first teleport" |
| 14:24 |
celeron55 |
(not sure if it's a position packet though; i'm just assuming) |
| 14:25 |
|
Baytuch| joined #minetest |
| 14:30 |
MTDiscord |
<warr1024> This feels like the extra position packet on join, and the failed teleports, are 2 symptoms of some underlying bug, like a thread synchronization error or race condition or something. |
| 14:31 |
MTDiscord |
<warr1024> I know I've actually built a rather elaborate mod level workaround already for the teleport problem, but teleports can still end up arbitrarily delayed even if the workaround catches them. |
| 14:34 |
MTDiscord |
<warr1024> I need the workaround because I'll have to wait months for a fix no matter what else happens, but I'd really like to have an actual fix. I'd file an issue for it but filing an issue means setting aside a big chunk of time to do a "prior art search" through all the existing issues. I don't want to spend all the time to put together a quality bug report only to have it closed as duplicate. |
| 14:35 |
MTDiscord |
<warr1024> I guess "extra packet error messages" could be its own bug separate from the "teleport fail" one. |
| 14:36 |
celeron55 |
you aren't expected to do hours of research before filing an issue |
| 14:36 |
celeron55 |
that would be silly |
| 14:37 |
celeron55 |
if you find a bug, and when described in your words you can't find a corresponding issue, then you file the issue. if it turns out to be duplicate, it will help people who are searching for the issue with the words you used |
| 14:38 |
celeron55 |
if you don't file an issue, you can be sure the thing won't get fixed |
| 14:39 |
celeron55 |
this entire process is designed for regular humans, you don't need to become a machine or a wizard in order to take part in it |
| 14:40 |
celeron55 |
describing what exactly the workaround does is useful information |
| 14:42 |
celeron55 |
my guess is it's a network race condition like i described. but it's a guess |
| 14:47 |
|
sparky4 joined #minetest |
| 14:53 |
|
Baytuch| joined #minetest |
| 14:58 |
|
Thelie joined #minetest |
| 15:15 |
|
Baytuch| joined #minetest |
| 15:21 |
MTDiscord |
<warr1024> I don't know if my workaround is doing the "correct" thing (given that it's a workaround and not a fix, there's a limit to how correct it can be, but there are still shades of wrongness) but all I do is detect a likely teleport failure and retry it at what I think is a likely reasonable rate. |
| 15:21 |
MTDiscord |
<warr1024> https://gitlab.com/sztest/szutilpack/-/tree/master/szutil_teleportfix |
| 15:27 |
|
Niklp9 joined #minetest |
| 15:30 |
MTDiscord |
<warr1024> In minetest.get_player_information, for the keys where it says "the following keys can be missing if no stats have been collected yet" ... are those "all or nothing" or is it possible for SOME to be present and others absent? |
| 15:37 |
|
Baytuch| joined #minetest |
| 15:45 |
|
Oblomov joined #minetest |
| 16:13 |
|
TomTom joined #minetest |
| 16:16 |
|
mrkubax10 joined #minetest |
| 17:14 |
MTDiscord |
<warr1024> Okay, well, issues filed then. |
| 17:14 |
MTDiscord |
<warr1024> Any idea what I can/should do about "Packet quota used up for peer_id" warning messages? Should I raise the packet quota, or should I just accept that some players are on bad connections and should accept some loss? |
| 17:20 |
Krock |
this log message was added somewhere around version 5.2.0 which was silently ignored before. ignore it unless you're really sending large files to players |
| 17:37 |
|
Thelie joined #minetest |
| 18:10 |
|
appguru joined #minetest |
| 18:13 |
|
appguru joined #minetest |
| 18:35 |
|
Sobinec joined #minetest |
| 20:16 |
|
___nick___ joined #minetest |
| 20:36 |
|
___nick___ joined #minetest |
| 20:39 |
|
___nick___ joined #minetest |
| 21:51 |
|
Noisytoot joined #minetest |
| 22:07 |
|
Baytuch| joined #minetest |
| 22:44 |
|
lhofhansl joined #minetest |
| 22:46 |
|
cataraaa joined #minetest |
| 23:03 |
|
Baytuch| joined #minetest |
| 23:04 |
|
Thelie joined #minetest |
| 23:05 |
MinetestBot |
[git] lhofhansl -> minetest/minetest: Allow cheaper culling checks at a distance (#14073) ca1a723 https://github.com/minetest/minetest/commit/ca1a7238909e12c01653e9fd40dda86d86a2e1f3 (2023-12-16T23:04:21Z) |
| 23:25 |
|
sparky4 joined #minetest |
| 23:25 |
|
Baytuch| joined #minetest |
| 23:33 |
|
panwolfram joined #minetest |
| 23:39 |
|
illwieckz joined #minetest |
