[testserver] y_bows: HUDCHANGE packet spam #6156

New Issue

whosit · 2024-01-31T19:43:38Z

whosit commented

2024-01-31 19:43:38 +00:00

When I'm not holding a bow and as soon as I join the test server starts sending these packets every server step (red line is 0x4b is HUDCHANGE, green is total):

Here's our attempt to narrow this down:

Idk what it is doing exactly, maybe removing hud? Because the packets do not contain any texture info:

When I'm not holding a bow and as soon as I join the test server starts sending these packets every server step (red line is `0x4b` is `HUDCHANGE`, green is total): ![Screenshot 2024-01-31 220057](/attachments/39dec614-c1b8-436b-b9ca-9fc503373eb6) Here's our attempt to narrow this down: ![2Screenshot 2024-01-31 221052](/attachments/9342fe21-c413-4185-ba4b-a0ec254c9edc) Idk what it is doing exactly, maybe removing hud? Because the packets do not contain any texture info: ![image](/attachments/cc4d8e19-44ee-45d3-86aa-6698b4011965)

Screenshot 2024-01-31 220057.png

106 KiB

2Screenshot 2024-01-31 221052.png

64 KiB

image.png

154 KiB

whosit added the

1. kind/bug

label 2024-01-31 19:46:42 +00:00

flux was assigned by whosit

2024-01-31 19:46:48 +00:00

~~whosit referenced this issue 2024-02-01 06:59:40 +00:00~~

Redshirt reports: entered the zeppelin docked at ... #5680

flux added this to the flux's TODO list project 2024-02-01 19:18:06 +00:00

flux added the

4. step/question

label 2024-02-01 19:33:09 +00:00

flux removed the

4. step/question

label 2024-02-01 19:56:26 +00:00

flux commented

2024-02-01 19:57:06 +00:00

i see, i'm able to replicate this locally now. hm. i've got no idea what's going on here, but it does seem to be y_bow's fault.

flux commented

2024-02-01 20:05:35 +00:00

oh, i figured one part of it out - apparently when checking whether a HUD parameter's value had changed, i've been using == to compare tables. that fixes most of it.

however, i've got to do something to figure out loss of floating point precision:

2024-02-01 12:03:49: ACTION[Server]: [futil] [DEBUG] flux y_bows:background(17) position {
	x = 0.5,
	y = 0.34999999403954
}->{
	x = 0.5,
	y = 0.35
}

oh, i figured one part of it out - apparently when checking whether a HUD parameter's value had changed, i've been using `==` to compare tables. that fixes most of it. however, i've got to do something to figure out loss of floating point precision: ``` 2024-02-01 12:03:49: ACTION[Server]: [futil] [DEBUG] flux y_bows:background(17) position { x = 0.5, y = 0.34999999403954 }->{ x = 0.5, y = 0.35 } ```

AliasAlreadyTaken commented

2024-02-01 20:21:57 +00:00

Means, the loss would amount to 5.96045996e-9 ? Given that MT uses single blocky collision boxes for entities, there's no need to tell apart whether we shot the left or the right nostril?

flux commented

2024-02-01 20:47:46 +00:00

this should fix it: 9858421c84

this should fix it: https://github.com/fluxionary/minetest-futil/commit/9858421c844aca53628f0a782a29c237db73f092

flux commented

2024-02-01 20:55:58 +00:00

Means, the loss would amount to 5.96045996e-9 ? Given that MT uses single blocky collision boxes for entities, there's no need to tell apart whether we shot the left or the right nostril?

no, this is just in the HUD update manager. what's happening is that certain values that define the HUD (e.g. scale and position) are stored using 32 bit floats, whereas the values supplied by the lua code are 64 bit floats. if i try to compare the old HUD values to the new values, i need to account for the lost precision.

> Means, the loss would amount to 5.96045996e-9 ? Given that MT uses single blocky collision boxes for entities, there's no need to tell apart whether we shot the left or the right nostril? no, this is just in the HUD update manager. what's happening is that certain values that define the HUD (e.g. scale and position) are stored using 32 bit floats, whereas the values supplied by the lua code are 64 bit floats. if i try to compare the old HUD values to the new values, i need to account for the lost precision.

flux added the

4. step/ready to QA test

label 2024-02-01 21:01:23 +00:00

flux referenced this issue

2024-02-01 21:10:27 +00:00

Redshirt reports: entered the zeppelin docked at ... #5680

whosit commented

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

Since it's just hud, would it not make more sense to just subtract them and compare with some small enough "epsilon" value? Instead of using strings and pattern matching?

whosit commented

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

I think this may be related:
#5973
just not sure if I tried running wireshark at that time or not...

(seems like this spam may have been that cause of that bug...)

I think this may be related: https://gitea.your-land.de/your-land/bugtracker/issues/5973 just not sure if I tried running wireshark at that time or not... (seems like this spam may have been that cause of that bug...)

flux commented

2024-02-01 21:59:33 +00:00

yeah, i think it's probably also responsible for the arrows stuck in the air too. too many spurious packets and the client gets confused.

flux referenced this issue

2024-02-01 22:00:32 +00:00

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

whosit commented

2024-02-17 15:46:17 +00:00

HUDCHANGE while spamming arrows on the test server (with a pause in the middle))

![image](/attachments/9d8cc745-4ab7-480d-9f50-87ba9b2f5f1e) `HUDCHANGE` while spamming arrows on the test server (with a pause in the middle))

image.png

76 KiB