I don't know the exact version of flans where this bug got into the system but its somewhere between
flansmod 5.5.2 and 5.6.0 beta when using the MW content pack

The bug can also be found in the latest version of flansmod.

In short:
when using a gun addon pack such as MW; bullets wont do damage to a moving player even though the bullet seems to directly hit the player.

Linked below is a video from "Zervult" showing the problem.

https://www.youtube.com/watch?v=IGUInQj-_oE

in the video, the person recording was aiming directly at the diamond player from 5 blocks away when he shot and the hit did not properly register. meaning that the player being shot did not take any damage.

The content pack he was using is was 'Machetemen' but the exact same problem occurs with the MW content pack.

In this image, the shooter is about to shoot the moving diamond player directly in the chest, the shot is aimed up perfectly.
When he shoots, the bullet does not register and the diamond player does not take any damage at all.

Im having the exact same problem cant wait for it to be fixed.

My brief investigations of this bug on 1.7.10 FM+USE (Almost identical hitreg system) suggest that the ping correction on the server is inaccurate, and whenever shots are missed, the snapshot one above or below the chosen (ping corrected) snapshot would yield a proper hit.

I've only diagnosed that as the problem, there isn't any easy solution from what I can see.

To be more specific about what I mean, a minecraft server runs in ticks, 20 per second. Everything that changes in the game happens in these ticks (players moving, plants growing, bullets moving e.t.c). Everything you see that is smoother than 20 updates per second is guessed by your client, all the server sees is these 20 updates per second. 20 is fine for minecraft, you don't need to be very precise about when things happen. But competitive games tend to use much higher tick rates, such as 60 or even 120. This makes it much smoother, but their packets have to be a LOT more optimised so that it's not a strain on the network. There's no way to get around this set 20 ticks per second, apart from guessing what happens between.

Anyway, the next layer of confusion: Ping. The server tries to run the hit detection as though it was from the shooter's perspective. What it does, is it stores the position of all players every tick (20 times per second), then looks at the ping of the shooter, and divides it by 50 millisecond (1000 milliseconds in a second / 20 = 50ms) to get how far back in time it should look. That's to make the hits look correct from the SHOOTERS perspective, because that will be different to everyone else's due to the ping. So if the shooter has a ping of 120ms, the bullet actually appearing and moving on the server will be 120//50=2+abit ticks in the past, relative to the server. So the server looks at the positions of the players 2 ticks in the past, and not the present. That works okay as long as the player's ping is constant. When it varies, it can cause issues.

Another layer of confusion: Hitreg is done client side to show the player if they've hit something, otherwise the hit marker would arrive much later if the server had sent it - which would be confusing.

Using our previous example, if the player's ping goes up to 150ms for a short time, maybe the ping reported to the server is inaccurate. But this is not 3 ticks, not 2. So if the bullet is shot 100ms behind, it'll now be looking for hits 150ms behind instead - when the original delay is 100ms. This manifests in the shooter registering the hit client side (the hitmarker pops up) but the server doesn't recognise it as a hit, because it WOULD have been a hit if it was only 2 ticks behind. Then the player gets confused because they saw a hit on their client, but no damage was done to whoever was shot, because the server didn't recognise it.

The problem here is that we've got three different sources of truth, and all of them are right. Who should decide? The person being shot? The shooter? The server? Player side hit registration is dodgy, because it can be easily exploited. It also means hits can taken a long time to get to the other people affected. A server is between the shooter, and person hit, so reduces the time. Currently the server decides whether a hit has happened or not, but tries to work it out from the perspective of the shooter.

Even to fix this issue, you need to investigate and decided if these hits should be counted or not, which I have not done yet - I have only shown there's a difference between the client and the server.

A more complete system would factor in the ping of whoever is being shot at, but this would get complicated very quickly - and there's still the issue of the clients running their own hit detection for visual purposes.

I have reached out to Flan already to try and discuss how it works, but he doesn't remember a lot about it. If someone out there is experienced with hit registration, factoring in ping, and even interpolated intersection times - I'd love to chat.
I'd personally love to go down this rabbit hole, but other things are higher priority right now.

Thanks for spending your time explaining the situation in detail, its rather quite interesting xD

I understand this Is a real deep rabbit hole, for now I shall stick to the versions that negate my problem.

Thanks for this.

Sorry, misread the first post - this bug was first reported on 1.7.10 FM+USE by Zervult/Secret Agnet, but you reproduced it on later versions iirc? I think it's been present on all versions with the same hit reg system.

I see, so how can we fix the ping correction with versions above flansmod 5.6.0 beta?

" I think it's been present on all versions with the same hit reg system."

Yeah, I think it has.