| *** bryjen <bryjen!~bryjen@2603-6010-7a04-7681-b68c-9dff-fecf-1169.res6.spectrum.com> has quit IRC (Quit: Leaving) | 00:16 | |
| *** BulletCatcher <BulletCatcher!~bc@user/bulletcatcher> has joined #bzflag | 00:19 | |
| *** tupone <tupone!~tupone@gentoo/developer/tupone> has quit IRC (Ping timeout: 264 seconds) | 00:23 | |
| Agatha | I don't know how it works currently, and I know network synchronization is a thorny problem. Actually, I think my main complaint is that the "jitter" readout doesn't seem closely related to the amount of jitter a person actually has. Sure, 100ms is worse than 10ms, but the timescales involved are much worse than that. | 00:25 |
|---|---|---|
| Agatha | It also goes player by player. When I was in Utah, my jitter was regularly 30ms I think, but people still complained bitterly that it felt more like 2000. That's a *huge* disparity! | 00:25 |
| SpringTank | yeah, it's weird | 01:11 |
| *** Cobra_Fast is now away: offline | 01:17 | |
| *** Cobra_Fast is back | 01:17 | |
| *** Cobra_Fast is now away: offline | 01:53 | |
| *** Cobra_Fast is back | 01:53 | |
| *** FastLizard4 is back | 03:06 | |
| *** FastLizard4 is now away: AWAY from keyboard | 03:14 | |
| blast007 | okay, the reason that being killed by SR makes it so you can't respawn is because the processing of MsgKilled in bzfs.cxx doesn't check for that and instead tries to verify that the shot ID is valid (which it isn't, because there isn't a shot), so it doesn't mark the player as dead on the server | 03:32 |
| blast007 | so that likely breaks it for death physics drivers too | 03:33 |
| Juest | strange | 03:47 |
| blast007 | not really | 03:47 |
| blast007 | just incomplete logic | 03:48 |
| blast007 | confirmed it breaks with death physics driver and water level death | 03:48 |
| blast007 | self-destruct is okay because in that case it skips the shot check, since the killer is yourself | 03:49 |
| Juest | i wonder why it was left incomplete for quite some time... | 03:49 |
| Juest | stupid question | 03:49 |
| blast007 | cuz nobody has been testing 2.5 in actual play | 03:50 |
| blast007 | remember how we found those 4 issues when we played it for like 5 to 10 minutes :) | 03:50 |
| Juest | heh :) | 03:51 |
| Juest | true | 03:51 |
| Juest | maybe we could get LU to play on development versions | 03:51 |
| blast007 | that'd be impossible right now | 03:52 |
| Juest | okay, when its rc quality | 03:54 |
| Juest | it'll be a little while i suppose | 04:00 |
| *** spldart <spldart!~spldart@2601:2c7:4100:2cb0:3210:b3ff:fef0:93af> has quit IRC (Remote host closed the connection) | 04:09 | |
| blast007 | in 2.4, the killer for water level death and death physics driver is the ServerPlayer, so it doesn't even check the shot ID validity. And for SR, the shot ID is sent as -1, which it treats as valid | 04:12 |
| blast007 | hmm, I wonder if the logic is just reversed in 2.5. The comment says "// you can kill yourself with an invalid shot, it may not have been sent up the pipe already", but then the check is check if the killer is NOT you and the shot is not valid. | 04:14 |
| blast007 | so based on that comment, I'd think it should be making sure the killer IS yourself | 04:14 |
| blast007 | but even if that check was reversed, I'm not sure it's a good idea to ignore the player saying they died just because the shot isn't in the manager... | 04:17 |
| blast007 | cuz I'd think that would mean that packet loss of a shot message could result in being unable to spawn if you shoot yourself | 04:18 |
| *** spldart <spldart!~spldart@2601:2c7:4100:2cb0:3210:b3ff:fef0:93af> has joined #bzflag | 04:27 | |
| blast007 | or even just out of order packet reception, since MsgFireShot is UDP and MsgKilled is TCP. | 04:36 |
| blast007 | I think this check is just entirely unnecessary: https://github.com/BZFlag-Dev/bzflag/blob/master/src/bzfs/bzfs.cxx#L5036-L5038 | 05:11 |
| blast007 | first, the check should have been "killer == t && !ShotManager.IsValidShotID(shot)" | 05:12 |
| blast007 | So let's assume the check was done that way. If the MsgFireShot from the client to the server gets lost or hasn't arrived yet, that check would fail and the client would think the player is still alive. | 05:13 |
| blast007 | the server would think the player is still alive, I mean | 05:18 |
| blast007 | also, if MsgFireShot is delayed just a bit, I think could cause the shot to show up on other clients and not be ended, since when they received MsgKilled it wasn't in their shot list yet. though that's probably not a new issue. | 05:22 |
| blast007 | Juest: what operating system are you getting the high jitter on? Here with Debian on a local server (client and server), I'm getting 1ms jitter, and to my public server it's 3ms. | 05:28 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 240 seconds) | 06:15 | |
| *** FastLizard4 is back | 06:16 | |
| *** uncanny <uncanny!~uncanny@66.85.230.227> has joined #bzflag | 06:16 | |
| *** FastLizard4 is now away: IN-GAME - Minecraft | 06:19 | |
| *** uncanny <uncanny!~uncanny@66.85.230.227> has quit IRC (Quit: Client closed) | 06:36 | |
| *** Cobra_Fast is now away: offline | 08:25 | |
| *** Cobra_Fast is back | 08:25 | |
| *** Cobra_Fast is now away: offline | 08:58 | |
| *** Cobra_Fast is back | 08:58 | |
| *** Cobra_Fast is now away: offline | 09:38 | |
| *** Cobra_Fast is back | 09:38 | |
| *** Agatha <Agatha!~agatha@user/agatha> has quit IRC (Server closed connection) | 11:17 | |
| *** Agatha <Agatha!~agatha@50.109.254.246> has joined #bzflag | 11:17 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 11:39 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 11:52 | |
| *** alezakos <alezakos!~kongr45gp@user/alezakos> has quit IRC (Server closed connection) | 12:25 | |
| *** alezakos <alezakos!~kongr45gp@user/alezakos> has joined #bzflag | 12:26 | |
| blast007 | ah, getting 55 to 80 ms jitter on Windows to a server on the same host | 12:34 |
| blast007 | and to local/remote servers on linux. The client on my macos doesn't seem to have issues with the jitter. | 12:38 |
| *** tupone <tupone!~tupone@gentoo/developer/tupone> has joined #bzflag | 13:00 | |
| *** FastLizard4 is back | 14:22 | |
| *** FastLizard4 is now away: AWAY from keyboard | 14:29 | |
| Juest | blast007: both windows and linux | 15:34 |
| Juest | i tested with a local server | 15:34 |
| Juest | hmmmm | 15:34 |
| blast007 | I did narrow it down to a specific commit. | 15:47 |
| blast007 | https://github.com/BZFlag-Dev/bzflag/commit/aa19b4eb0b064bc8e83b47337916d5caedd0bcac "refactor TimeKeeper to use std::chrono" | 15:48 |
| blast007 | when I revert that for just the client, the high jitter goes away even when I'm connecting to a server that still has that change | 15:49 |
| BZNotify | bzflag: blast007 labeled issue #338 "High jitter reported" as bug (2.6 Release - https://github.com/BZFlag-Dev/bzflag/issues/338) | 15:51 |
| BZNotify | bzflag: blast007 milestoned issue #338 (2.6 Release - ) | 15:51 |
| BZNotify | bzflag: blast007 opened issue #338 (2.6 Release - ) | 15:51 |
| Juest | nice | 15:55 |
| *** FastLizard4 is back | 16:26 | |
| *** FastLizard4 is now away: AWAY from keyboard | 16:52 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 17:12 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 18:38 | |
| *** Optic_Delusion_ <Optic_Delusion_!~Optic_Del@2600:4041:19d:2d00:f48a:1682:61a4:491c> has joined #bzflag | 19:43 | |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@2600:4041:19d:2d00:6dd6:5f03:163d:a71> has quit IRC (Ping timeout: 258 seconds) | 19:46 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 19:59 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 20:11 | |
| SpringTank | I wonder if it's effecting the order in which its interpreting packets? I don't see where in the code it would do that though. | 20:21 |
| blast007 | I don't recall how we even calculate jitter | 20:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!