[testserver] y_bows: players sometimes see other player's reloading HUD #5973

New Issue

whosit · 2024-01-14T01:17:03Z

whosit commented

2024-01-14 01:17:03 +00:00

I happens with a delay, like it gets replayed.
Sometimes after rapid firing by one account, other starts seeing rapid reloads.
Sometimes second account does not see HUD while holding a bow, seems like it's related too.

It was noticed by Chache too, so I think I'm not crazy...

I happens with a delay, like it gets replayed. Sometimes after rapid firing by one account, other starts seeing rapid reloads. Sometimes second account does not see HUD while holding a bow, seems like it's related too. It was noticed by Chache too, so I think I'm not crazy...

whosit added the

1. kind/bug

label 2024-01-14 01:17:03 +00:00

flux was assigned by whosit

2024-01-14 01:17:03 +00:00

flux commented

2024-01-14 19:20:31 +00:00

i think this is a symptom of some network issue as discussed in #5972

flux added the

3. source/unknown

label 2024-01-14 19:20:39 +00:00

flux referenced this issue

2024-01-21 00:16:58 +00:00

rewired_X reports: testserver the blimp's gauges ... #6016

whosit commented

2024-01-24 14:16:39 +00:00

If I spam player with hud updates (sending bunch of them on each globalstep, like I did with my /find_entities), then with time client gets further and further behind.
It's like there's a limit that server will send at the time, and this queue slowly fills up. Makes sense if hud_change() must be a reliable packet and server has some limit it will send at a time. And this affects not only hud, but all other packets start to slowly get behind too?

I wonder if real-time bow updates is what causing this basically? Or something else strange is going on that's specific to the test server?

If I spam player with hud updates (sending bunch of them on each globalstep, like I did with my `/find_entities`), then with time client gets further and further behind. It's like there's a limit that server will send at the time, and this queue slowly fills up. Makes sense if `hud_change()` must be a reliable packet and server has some limit it will send at a time. And this affects not only hud, but all other packets start to slowly get behind too? I wonder if real-time bow updates is what causing this basically? Or something else strange is going on that's specific to the test server?

flux commented

2024-01-24 23:13:54 +00:00

i lowered the HUD update rate (da3c3ddb93). note that 2 of the 3 HUDs are basically constant, so they wouldn't generate updates very often (futil's HUD manager only "changes" the HUD when a value actually changed).

i'm not sure this will fix this issue though, i'm not sure exactly what's causing it. i think it only happens when there's a ton of server traffic in general for unrelated reasons.

i lowered the HUD update rate (https://github.com/fluxionary/minetest-y_bows/commit/da3c3ddb93fd4e27ce5e3cf1f0782362eb20e361). note that 2 of the 3 HUDs are basically constant, so they wouldn't generate updates very often (futil's HUD manager only "changes" the HUD when a value actually changed). i'm not sure this will fix this issue though, i'm not sure exactly what's causing it. i think it only happens when there's a ton of server traffic in general for unrelated reasons.

flux commented

2024-01-24 23:16:26 +00:00

and for the record, i'm certain this has nothing to do with other player's HUDs - it's HUD updates that were meant to be sent to you, but somehow get delayed or played out-of-order - possibly due to packet loss? i got this behavior a few times when playing around by on my own on the test server.

whosit referenced this issue

2024-02-01 21:16:08 +00:00

[testserver] y_bows: HUDCHANGE packet spam #6156

whosit commented

2024-02-01 21:19:14 +00:00

There seems to be a limit of packets that the server will send to client "per step", and if they are reliable packets, then the queue can get behind, so if #6156 was the cause, reliable packet spam may be the explanation for this bug.

AliasAlreadyTaken added this to the 1.1.123 milestone 2024-02-01 22:46:22 +00:00

AliasAlreadyTaken commented

2024-02-16 08:18:27 +00:00

QA

We'll have to see whether it happens on main with so many more people.

Let's hold an archery tournament to see whether there are still issues with shared HUD

QA We'll have to see whether it happens on main with so many more people. Let's hold an archery tournament to see whether there are still issues with shared HUD

AliasAlreadyTaken added the

ugh/QA main

label 2024-02-16 08:18:32 +00:00

whosit commented

2024-02-16 10:07:20 +00:00

does this look correct? 2 players having same hud id?
but we didn't observe any actual issues though...

![image](/attachments/476aa4a7-d1b7-4a18-aae0-26088098da32) does this look correct? 2 players having same hud id? but we didn't observe any actual issues though...

image.png

307 KiB

👀 1

flux commented

2024-02-18 05:39:29 +00:00

does this look correct? 2 players having same hud id?
but we didn't observe any actual issues though...

that's totally normal; the hud_id is per-player. it just means that 13 was the lowest unused HUD ID for both of you.

> does this look correct? 2 players having same hud id? > but we didn't observe any actual issues though... that's totally normal; the hud_id is per-player. it just means that 13 was the lowest unused HUD ID for both of you.

👍 2

flux added the

5. result/fixed

label 2024-03-29 22:03:54 +00:00

flux removed their assignment 2024-03-29 22:03:57 +00:00

flux commented

2024-03-29 22:04:39 +00:00

i think this got fixed by #6156; bow HUDs don't seem to desync anymore, at any rate.

flux closed this issue

2024-03-29 22:04:39 +00:00

Sign in to join this conversation.