[testserver] y_bows: arrows get stuck in the air #5972

New Issue

Open

opened 2024-01-14 01:13:52 +00:00 by whosit · 26 comments

whosit commented 2024-01-14 01:13:52 +00:00

Member

Copy Link

Sometimes a single shot arrow gets stuck in the air soon after shooting.

I don't hear a ding like when I hit myself.
It happens when I don't rapid-fire, so does seem like arrows collide with other arrows.

Kinda looks like it gets stuck after a single timestep or maybe even on the first one?

Could this be related to "critical shot" mechanic?

Sometimes a single shot arrow gets stuck in the air soon after shooting. I don't hear a ding like when I hit myself. It happens when I don't rapid-fire, so does seem like arrows collide with other arrows. Kinda looks like it gets stuck after a single timestep or maybe even on the first one? Could this be related to "critical shot" mechanic?

whosit added the

1. kind/bug

label 2024-01-14 01:13:52 +00:00

flux was assigned by whosit 2024-01-14 01:13:52 +00:00

flux commented 2024-01-14 16:58:21 +00:00

Member

Copy Link

It happens when I don't rapid-fire, so does seem like arrows collide with other arrows.

unfortunately there's no way to make arrows collide with objects and not have them collide with other arrows. what's supposed to happen in that case, is that both arrows drop as items. i'll have to see what's up with them "getting stuck"

> It happens when I don't rapid-fire, so does seem like arrows collide with other arrows. unfortunately there's no way to make arrows collide with objects and not have them collide with other arrows. what's *supposed* to happen in that case, is that both arrows drop as items. i'll have to see what's up with them "getting stuck"

flux added the

3. source/mod upstream

4. step/at work

labels 2024-01-14 16:58:36 +00:00

flux added this to the flux's TODO list project 2024-01-14 16:58:39 +00:00

whosit commented 2024-01-14 17:07:33 +00:00

Author

Member

Copy Link

Sorry, I meant "does not seem like they collide with each other" - it sometimes happens when I shoot a single arrow.

That first one that you saw was literally the first one I shot after joining the server.
All the rest were my attempts to shoot arrow in the same direction (maybe there was a service acc there or something else invisible I thought? - but no, I was alone on the test and block is just air).

I can't actually make them hit each other by rapid firing. Random stuck arrows happen randomly on single shots. And it's not too rare even (had it happen 2 more times at least)

Sorry, I meant "does _not_ seem like they collide with each other" - it sometimes happens when I shoot a single arrow. That first one that you saw was literally the first one I shot after joining the server. All the rest were my attempts to shoot arrow in the same direction (maybe there was a service acc there or something else invisible I thought? - but no, I was alone on the test and block is just air). I _can't_ actually make them hit each other by rapid firing. Random stuck arrows happen randomly on single shots. And it's not too rare even (had it happen 2 more times at least)

flux commented 2024-01-14 17:55:44 +00:00

Member

Copy Link

i can't replicate this locally. the test server seems to be up-to-date, and i can replicate it there though...

ok, this is very weird - according to the server, the arrow doesn't exist! it seems to be a client-side artifact?!

i can't replicate this locally. the test server seems to be up-to-date, and i can replicate it there though...  ok, this is *very* weird - according to the server, the arrow doesn't exist! it seems to be a client-side artifact?!

image.png

168 KiB

flux commented 2024-01-14 19:13:36 +00:00

Member

Copy Link

or possibly they exist, but the server seems to think their position is something very different from where they are?! and these "broken" arrows don't seem to get unloaded. and the inspection tool doesn't register them when you punch them, and you can't pick them up by punching them... and they don't unload when there's no-one at the area?

or possibly they exist, but the server seems to think their position is something very different from where they are?! and these "broken" arrows don't seem to get unloaded. and the inspection tool doesn't register them when you punch them, and you can't pick them up by punching them... and they don't unload when there's no-one at the area?

flux commented 2024-01-14 19:17:18 +00:00

Member

Copy Link

the test server is also doing very weird things with the y_bows HUD too, it's showing up sometimes when i'm not even wielding a bow. and other things sometimes feel laggy, even though the server reports there's no issue. maybe a network issue somehow?

the test server is also doing very weird things with the y_bows HUD too, it's showing up sometimes when i'm not even wielding a bow. and other things sometimes feel laggy, even though the server reports there's no issue. maybe a network issue somehow?

flux commented 2024-01-14 19:19:27 +00:00

Member

Copy Link

yeah, definitely some sort of client/server network SNAFU - the arrows appear in the correct spot after i log off and log back in...

yeah, definitely some sort of client/server network SNAFU - the arrows appear in the correct spot after i log off and log back in...

flux added

3. source/unknown

and removed

3. source/mod upstream

4. step/at work

labels 2024-01-14 19:19:39 +00:00

flux referenced this issue 2024-01-14 19:20:31 +00:00

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

whosit commented 2024-01-14 20:13:46 +00:00

Author

Member

Copy Link

I think Sokomine mentioned seeing "many floating arrows", while I saw only one. Sokomine also has trouble with "getting connection overloaded" with too many Voice mobs. This may be a clue.

I think I was able to pick up floating arrow into my inventory. But this is still consistent with client/server position desync.

Also, I saw same stuck arrow on 2 clients, does that mean that server just didn't send any velocity updates for that arrow?

Could it be that arrow "hits" something on the server before clients get the arrow's speed and it just spawned as static?

Maybe it's two similar but different problems (arrows stuck because server didn't send any updates, and arrows stuck because client lost some packets?)

This is only semi-related:
I had massive desync problems when I was trying to move a mob using only set_velocity and set_acceleration - server considered them static, but didn't send the velocity/acceleration update packet to client because the delta was too small. This caused client to continue slowly moving my mob away in one direction. Position was reset on join...

I think Sokomine mentioned seeing "many floating arrows", while I saw only one. Sokomine also has trouble with "getting connection overloaded" with too many Voice mobs. This may be a clue. I think I was able to pick up floating arrow into my inventory. But this is still consistent with client/server position desync. Also, I saw same stuck arrow on 2 clients, does that mean that server just didn't send any velocity updates for that arrow? Could it be that arrow "hits" something on the server before clients get the arrow's speed and it just spawned as static? Maybe it's two similar but different problems (arrows stuck because server didn't send any updates, and arrows stuck because client lost some packets?) This is only semi-related: I had massive desync problems when I was trying to move a mob using only `set_velocity` and `set_acceleration` - server considered them static, but didn't send the velocity/acceleration update packet to client because the delta was too small. This caused client to continue slowly moving my mob away in one direction. Position was reset on join...

flux commented 2024-01-14 21:29:14 +00:00

Member

Copy Link

perhaps not a networking thing.

note how all the dtimes are normal, but only one is being executed every second.... but this might easily lead to queues being overfilled and thus packets being "dropped" before they're created.

 perhaps not a networking thing. ~~note how all the dtimes are normal, but only one is being executed every second.... but this might easily lead to queues being overfilled and thus packets being "dropped" before they're created.~~

image.png

349 KiB

flux commented 2024-01-14 22:09:21 +00:00

Member

Copy Link

disregard the above, dtime reports were being consumed by my chat de-dupe CSM

disregard the above, dtime reports were being consumed by my chat de-dupe CSM

flux commented 2024-01-14 22:10:47 +00:00

Member

Copy Link

but something weird is definitely affecting all entities. right-click on Amanda or a default:chest, sometimes it'll take several seconds for the UI to show

but something weird is definitely affecting all entities. right-click on Amanda or a default:chest, sometimes it'll take several seconds for the UI to show

flux commented 2024-01-15 18:36:02 +00:00

Member

Copy Link

i'm noticing that this happens in the haven plaza, but not at other locations.

i'm noticing that this happens in the haven plaza, but *not* at other locations.

flux commented 2024-01-15 19:17:31 +00:00

Member

Copy Link

finally able to replicate this locally, though it's not as easy to do as on the test server:

it does seem to be highly correlated with the number of other nearby entities (in this case, signs).

finally able to replicate this locally, though it's not as easy to do as on the test server:  it *does* seem to be highly correlated with the number of other nearby entities (in this case, signs).

image.png

290 KiB

flux commented 2024-01-15 19:49:31 +00:00

Member

Copy Link

unfortunately i still can't replicate it reliably even if i add way more entities...

unfortunately i still can't replicate it reliably even if i add way more entities...

flux added the

4. step/at work

label 2024-01-15 19:51:52 +00:00

whosit commented 2024-01-15 23:56:29 +00:00

Author

Member

Copy Link

Now I wonder if it could be related to this: # 5994 (Haven/spawn lag)

Now I wonder if it could be related to this: # 5994 (Haven/spawn lag)

whosit commented 2024-01-20 02:24:09 +00:00

Author

Member

Copy Link

Happens more often if I do for example:
/create_lag 1000000 3 (command from mesecons_debug)
And when lag is constant arrows just end up "somewhere", sometimes stuck in air too.

Happens more often if I do for example: `/create_lag 1000000 3` (command from `mesecons_debug`) And when lag is constant arrows just end up "somewhere", sometimes stuck in air too.

flux commented 2024-01-28 00:47:59 +00:00

Member

Copy Link

i haven't been able to reproduce this more than the once locally, but i've reduced the HUD update rate da3c3ddb93 and arrow pitch update d1d7c5187c, hopefully that'll reduce the number of packets sent to clients

i haven't been able to reproduce this more than the once locally, but i've reduced the HUD update rate https://github.com/fluxionary/minetest-y_bows/commit/da3c3ddb93fd4e27ce5e3cf1f0782362eb20e361 and arrow pitch update https://github.com/fluxionary/minetest-y_bows/commit/d1d7c5187c563a9e1335c881db3ca4b4a2b1601a, hopefully that'll reduce the number of packets sent to clients

flux commented 2024-02-05 03:26:51 +00:00

Member

Copy Link

not sure if the last couple days code is installed on the test server, but arrows still "freeze in mid-air" when fired around the post-office, so i don't think spurious HUD updates are responsible for that. i still haven't replicated this locally except that once.

not sure if the last couple days code is installed on the test server, but arrows still "freeze in mid-air" when fired around the post-office, so i don't think spurious HUD updates are responsible for that. i still haven't replicated this locally except [that once](https://gitea.your-land.de/your-land/bugtracker/issues/5972#issuecomment-71272).

AliasAlreadyTaken commented 2024-02-05 10:01:22 +00:00

Owner

Copy Link

Latest updates are now on the testserver :)

Latest updates are now on the testserver :)

whosit commented 2024-02-05 12:19:29 +00:00

Author

Member

Copy Link

If both clients are near the arrow when it gets stuck, they both see it:

But when I rejoin, for that client arrow is in it's normal position stuck in the ground:

This is a client/server desync issue.

My guess is that it's a race condition of sorts. I even hear the arrow "hitting" something.
Probably you're never setting arrow position explicitly, only setting it's velocity, so it's left to clients to calculate it's position.
And in this case maybe packets that spawn the arrow and set it's velocity to zero arrive on the same timestep for the client, so the arrow just never starts moving client-side.

If both clients are near the arrow when it gets stuck, they both see it:   But when I rejoin, for that client arrow is in it's normal position stuck in the ground:   This is a client/server desync issue. My guess is that it's a race condition of sorts. I even hear the arrow "hitting" something. Probably you're never setting arrow position explicitly, only setting it's velocity, so it's left to clients to calculate it's position. And in this case maybe packets that spawn the arrow and set it's velocity to zero arrive on the same timestep for the client, so the arrow just never starts moving client-side.

screenshot_20240205_150826.png

1.4 MiB

screenshot_20240205_150834.png

1.6 MiB

screenshot_20240205_150956.png

1.5 MiB

screenshot_20240205_151509.png

1.8 MiB

screenshot_20240205_151500.png

1.8 MiB

flux commented 2024-02-05 20:04:28 +00:00

Member

Copy Link

If both clients are near the arrow when it gets stuck, they both see it:

in my tests, this is not the case. sometimes one player will see the arrow "stuck", sometimes the other.

But when I rejoin, for that client arrow is in it's normal position stuck in the ground:

they'll appear in the correct position if you even leave the area and come back again - no need to relog.

Probably you're never setting arrow position explicitly, only setting it's velocity, so it's left to clients to calculate it's position.

position is only set when the arrow is e.g. "stuck in the ground". velocity is only set (actually, i use add_velocity instead of set_velocity) when applying drag. x_bows uses set_velocity. i wonder if that could be part of the problem?

> If both clients are near the arrow when it gets stuck, they both see it: in my tests, this is not the case. sometimes one player will see the arrow "stuck", sometimes the other. > But when I rejoin, for that client arrow is in it's normal position stuck in the ground: they'll appear in the correct position if you even leave the area and come back again - no need to relog. > Probably you're never setting arrow position explicitly, only setting it's velocity, so it's left to clients to calculate it's position. position is only set when the arrow is e.g. "stuck in the ground". velocity is only set (actually, i use `add_velocity` instead of `set_velocity`) when applying drag. x_bows uses set_velocity. i wonder if that could be part of the problem?

whosit commented 2024-02-05 21:12:07 +00:00

Author

Member

Copy Link

I feel this happens immediately after arrow is shot - maybe on a step when dtime is high. I release the arrow, hear "node is hit" sound and arrow is stuck. Could this be the clue? Shooting and hitting happening on the same server step?

I feel this happens immediately after arrow is shot - maybe on a step when dtime is high. I release the arrow, hear "node is hit" sound and arrow is stuck. Could this be the clue? Shooting and hitting happening on the same server step?

flux commented 2024-02-06 01:18:22 +00:00

Member

Copy Link

Shooting and hitting happening on the same server step?

that's not it. it's not totally independent of dtime, but it happens regularly enough on the test server which generally has near-zero lag, and i can't get it to happen locally even with very high artificial lag. also, you can hear it moving around and hitting the ground/ceiling on different steps from when you shoot it.

i kinda want to do a full analysis of all incoming packets for one "normal" and one "suck in air" bow shot. i've wished the minetest wireshark plugin parsed the packets more thoroughly. i wonder if i could instead make use of that minetest proxy server. hm.

> Shooting and hitting happening on the same server step? that's not it. it's not totally independent of dtime, but it happens regularly enough on the test server which generally has near-zero lag, and i can't get it to happen locally even with very high artificial lag. also, you can *hear* it moving around and hitting the ground/ceiling on different steps from when you shoot it. i kinda want to do a full analysis of all incoming packets for one "normal" and one "suck in air" bow shot. i've wished the minetest wireshark plugin parsed the packets more thoroughly. i wonder if i could instead make use of that minetest proxy server. hm.

whosit commented 2024-02-06 05:14:32 +00:00

Author

Member

Copy Link

I hacked together a version of minetest.lua that assembles "split message" packets back, but didn't figure out yet how to properly parse active object messages further, but it should be easier...

Here's the version that assembles split packets and puts the result of running the dissector again into the last split packet:

9f502de..c6867aad

For active object messages I also add CMD:

I hacked together a version of minetest.lua that assembles "split message" packets back, but didn't figure out yet how to properly parse active object messages further, but it should be easier... Here's the version that assembles split packets and puts the result of running the dissector again into the last split packet: https://gitea.your-land.de/whosit/minetest_wireshark/compare/9f502de..c6867aad For active object messages I also add CMD: 

image.png

23 KiB

👍 1

whosit commented 2024-03-18 14:35:57 +00:00

Author

Member

Copy Link

I had bad wifi connection or something, and almost each arrow I shot got stuck mid-air:

I had bad wifi connection or something, and almost each arrow I shot got stuck mid-air: 

image.png

50 KiB

whosit commented 2024-03-18 18:51:41 +00:00

Author

Member

Copy Link

Although, this is what tree chopping aftermath looks like:

So, maybe it's not specific to arrows...

Although, this is what tree chopping aftermath looks like:  So, maybe it's not specific to arrows...

image.png

167 KiB

flux commented 2024-03-19 03:19:19 +00:00

Member

Copy Link

So, maybe it's not specific to arrows...

it's not.

anticheat prevents you from interacting with client-side displaced arrows currently. it's mostly an aesthetic problem. we should try to fix it if we can, but i'm not convinced it's a major gameplay issue. it can keep you from picking up your arrows that have landed in the ground, but that's not meant to be a reliable mechanic anyway.

> So, maybe it's not specific to arrows... it's not. anticheat prevents you from interacting with client-side displaced arrows currently. it's mostly an aesthetic problem. we should try to fix it if we can, but i'm not convinced it's a major gameplay issue. it can keep you from picking up your arrows that have landed in the ground, but that's not meant to be a reliable mechanic anyway.

flux removed the

4. step/at work

label 2024-04-03 20:51:00 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

Labels

Clear labels   

1. kind/balancing

Depends on balancing

  

1. kind/breaking

something that alters or disables an existing game mechanic

  

1. kind/bug

Something is not working

  

1. kind/construction

A build needs fixing

  

1. kind/documentation

Needs proper documentation

  

1. kind/enhancement

New feature

  

1. kind/griefing

players despoiling builds or nature

  

1. kind/invalid

Not a valid report, e.g. created by mistake with no content.

  

1. kind/meme

issue is mostly a joke

  

1. kind/node limit

something which works for or against the node limit

  

1. kind/other

Something not within the other kinds

  

1. kind/protocol

something concerning how staff should react to player requests, or how players should treat each other

  

2. prio/controversial

not likely to happen w/out a lot of discussion

  

2. prio/critical

Very important

  

2. prio/elevated

something players are eager to have fixed

  

2. prio/good first issue

the resolution to this is could be done by a new minetest contributor, who doesn't yet understand the mod ecosystem

  

2. prio/interesting

one of us has real interest in getting this implemented or fixed. however, more research might be needed.

  

2. prio/low

Not so important

  

3. source/art

art needs to be created or found for this to exist. includes sound, 3d modelling, and in-game building.

  

3. source/client

Issue is with the minetest client, or with player client configuration or the technical details of their setup

  

3. source/engine

Issue is due to a bug or feature of the minetest engine

  

3. source/ingame

Problem and solution exist in-game, e.g. builds or player moderation

  

3. source/integration

Two or more nonbuggy mechanics conflict, or our attempts to rectify conflicting mechanics have created a new bug

  

3. source/lag

A problem which is caused or made worse by lag, due to server processing issues, client processing issues, or network issues

  

3. source/license

A licensing problem is involved

  

3. source/mod upstream

Problem is upstream (not engine/client)

  

3. source/unknown

  

3. source/website

Affects the website

  

4. step/approved

Alias has approved this feature, someone should implement it

  

4. step/at work

Being worked on

  

4. step/blocked

we plan to do this, but other work has to be finished first

  

4. step/discussion

issue is under discussion, a solution has not been dictated or agreed upon

  

4. step/help wanted

Need some help

  

4. step/needs confirmation

  

4. step/partially fixed

this is mitigated or partially solved, but more work needs to be done

  

4. step/question

More information is needed

  

4. step/ready to deploy

has been QA tested by another person. has no outstanding issues. might be installed on prod, but needs final testing

  

4. step/ready to QA test

the code is supposedly fixed, but needs to be tested.

  

4. step/want approval

Someone can quickly implement this if Alias approves the change/feature

  

5. result/cannot reproduce

  

5. result/duplicate

This issue or pull request already exists

  

5. result/fixed

problem is fixed

  

5. result/maybe

not planned currently, but maybe some day

  

5. result/wontfix

the reported issue won't be changed, whether it's intentional or not.

  

ugh/petz

yet another petz bugz.

  

ugh/QA main

That's something we can only wait and see whether it hapens again: On the main server

  

ugh/QA NOK

Fix didn't yield the expected results

  

ugh/QA OK

tested

No Label

1. kind/balancing

1. kind/breaking

1. kind/bug

1. kind/construction

1. kind/documentation

1. kind/enhancement

1. kind/griefing

1. kind/invalid

1. kind/meme

1. kind/node limit

1. kind/other

1. kind/protocol

2. prio/controversial

2. prio/critical

2. prio/elevated

2. prio/good first issue

2. prio/interesting

2. prio/low

3. source/art

3. source/client

3. source/engine

3. source/ingame

3. source/integration

3. source/lag

3. source/license

3. source/mod upstream

3. source/unknown

3. source/website

4. step/approved

4. step/at work

4. step/blocked

4. step/discussion

4. step/help wanted

4. step/needs confirmation

4. step/partially fixed

4. step/question

4. step/ready to deploy

4. step/ready to QA test

4. step/want approval

5. result/cannot reproduce

5. result/duplicate

5. result/fixed

5. result/maybe

5. result/wontfix

ugh/petz

ugh/QA main

ugh/QA NOK

ugh/QA OK

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

flux's TODO list

Assignees

Clear assignees

No Assignees

flux

3 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#5972

No description provided.