Time Nick Message 00:55 EISHU hi 00:56 MTDiscord Hey EISHU 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 10:08 MTDiscord can we call globalstep on_tick instead? 10:09 MTDiscord 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. 11:53 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Allow running individual benchmarks 13e5a6048 https://github.com/minetest/minetest/commit/e5a6048eeca3050246911f0ebb40d7546905ab2b (152023-12-16T11:51:42Z) 11:53 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Try to benchmark common MapBlock usage 132c2bc4a https://github.com/minetest/minetest/commit/2c2bc4a4273e91cd6c502e273be9192e42256c9c (152023-12-16T11:51:42Z) 11:53 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Allocate data seperately from MapBlock class again 13cb6e3ac https://github.com/minetest/minetest/commit/cb6e3ac6e17e04aac1e13b6256305d7dd7946102 (152023-12-16T11:51:42Z) 11:53 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Change MapBlock content cache to a vector 13c6cf90f https://github.com/minetest/minetest/commit/c6cf90f67b51730cd833462135df197746f09b8c (152023-12-16T11:51:42Z) 11:53 MinetestBot 02[git] (5 newer commits not shown) 14:11 MTDiscord celeron55: if it's doing its job then the message probably shouldn't be at "error" severity, or even present then... 14:12 MTDiscord 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 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 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 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 .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:30 MTDiscord 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 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 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 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 15:21 MTDiscord 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 https://gitlab.com/sztest/szutilpack/-/tree/master/szutil_teleportfix 15:30 MTDiscord 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? 17:14 MTDiscord Okay, well, issues filed then. 17:14 MTDiscord 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 23:05 MinetestBot 02[git] 04lhofhansl -> 03minetest/minetest: Allow cheaper culling checks at a distance (#14073) 13ca1a723 https://github.com/minetest/minetest/commit/ca1a7238909e12c01653e9fd40dda86d86a2e1f3 (152023-12-16T23:04:21Z)