search

DarklightGames / DarkestHour

Darkest Hour: Europe '44-'45
https://store.steampowered.com/app/1280/Darkest_Hour_Europe_4445/
67 stars 20 forks source link

Offset error in bullet's player hit detection #260

Closed cmbasnett closed 8 years ago

cmbasnett commented 9 years ago

Originally reported by: Andrew Theel (Bitbucket: AndrewTheel, GitHub: AndrewTheel)

Today MattUK and I noticed a very large offset of the player hit boxes. I was able to kill him by shooting a good foot to his right, and shots on his left could miss even though they looked like they should hit. Happened with rifleman/garands. I've noticed similar occurrences in the past, but though it was in the projectile code, but this time it felt like a hit-box issue.

MattUK is going to look into the hit boxes for both pawns and driver/commanders/passengers. But I think this is important enough for all of us to resolve and ASAP. We may also be able to use debug commands in MP to debug this issue.

cmbasnett commented 9 years ago

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

Screenshots showing player pawn location hit points, e.g. chest, arm, etc.

Using exec function PlayerCollisionDebug in console.

cmbasnett commented 9 years ago

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

Two attached screenshots showing player pawn location hit points, e.g. chest, arm, etc. Using exec function PlayerCollisionDebug in console.

Collision actually looks pretty tight, at least as far as these locational damage hit points. Overall player hit detection starts with detecting a hit on the 'whip attachment', but that should be bigger and surround the player. When bullet hits the WA, it handles the snap/whiz sound, but also traces the bullet's flight path to see if it actually hit the player pawn. These pics suggest collision should be sound.

I'm really not sure the hit detection error is "huge" though. Seemed about 4 inches when I was shooting just to the side of you Theel (hey, maybe you think 4 inches is huge - but 3.5 billion women disagree !) :)

ps - Vehicle occupants are a totally different issue and separate system. Hit detection on vehicle occupants is very crude in comparison, although easily adjusted and controllable. Vehicle occupant hit detection ignores all the usual player pawn collision and locational damage hit points. It only uses special, extra collision boxes in the vehicle/VehicleWeapon mesh and two hit point spheres in code (small sphere for head, large one for torso).

cmbasnett commented 9 years ago

Original comment by Andrew Theel (Bitbucket: AndrewTheel, GitHub: AndrewTheel):

This is a huge issue because, hit detection is important and game breaking. Also I've never noticed anything like this in 5.1, so it is definably caused by 6.0 changes.

cmbasnett commented 9 years ago

Original comment by Colin Basnett (Bitbucket: cmbasnett, GitHub: cmbasnett):

I'm not convinced that this is actually an issue. Hit detection seems fine. If we get reports of this during testing we can look into it, but I have never encountered this nor can I even conceive of anything that we could have changed to cause such an error.

cmbasnett commented 9 years ago

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

I suspect it could be due to small differences in actor location between server & client. My understanding is (from memory of reading about this ages ago) that when handling location, the server:

So I think we might be seeing the slight location differences tolerated in the 1st bullet point.

cmbasnett commented 9 years ago

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

Believe have found the cause - and a fix - for this. Problem is in bullet's pre-launch trace system.

See https://bitbucket.org/darklightgames/darkesthour/issues/363/bullets-pre-launch-trace-system-is somewhat FUBAR.

cmbasnett commented 9 years ago

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

Fixed in Commit c438a0b.

Caused by use of HitPointTrace (HPT) in bullet's pre-launch trace (PLT) system. HPT is an RO native function that seems to have some significant flaws, although we can't see what's going on. It's useful for tracing hits on a player pawn. Compared to a normal trace, it detects hits on player pawns that have no collision (highly relevant: vehicle occupants), and it returns the body part location of any hit. So it has a place, but we have to understand its limitations & failings and I've spent time investigating this.

This problem appears to be caused because HPT "doesn't like short traces" (commented as such in RO code). Even though PLT is usually 2624 or 1314 UU (44/22m), a HPT of 10k UU still gives inaccurate results. Have to do a very long HPT of 65k UU (same as bullet's ProcessTouch function), then do distance check on any returned actor to see if is actually in PLT range. I've debugged by drawing debug lines representing a HPT path to traced player pawn HitLocation vs a standard trace along the same path.

Over distances of 10k UU and lower the HPT was markedly off to the right, while at 65k UU HPT length the two traces matched. So shorter PLT distance resulted in traced HitLocation being out by maybe 6 inches laterally on a player, meaning mid air hits on right side of body and partly immune left side.

Fixed by using a long 65k HPT and then checking traced HitLocation is within trace distance (actually compared squared distances using VSizeSquared, as is more efficient processing).

cmbasnett commented 9 years ago

Original comment by Andrew Theel (Bitbucket: AndrewTheel, GitHub: AndrewTheel):

Still noticing issues with this

cmbasnett commented 9 years ago

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

Recent problem fixed in commit d8c9f86.

My fault ! By mistake, I recently removed an exclusion that ignored collision with an actor has bBlockHitPointTraces=false. Basically meaning ignore the player pawn itself & just work off collision with its bullet whip attachment. I now remember temporarily removing the bBlockHPTraces check when I was researching how the HitPointTrace function worked (or didn't), but it was only a temp test & I must have stupidly included it with a commit.

Sorry !

dynamittt commented 5 years ago

Hello, I see this "issue" is closed long time ago but I have some questions regarding tracing HPs on Pawns. First of all I don't understand how HPs are represented in the "ingame" world. Of course they are somewhat "part" of the pawn, connected to certain bones and moved in real-time with them, but I dont know what type of "actors" are they considered to be(if they can even be labeled as Actors at all)? What Collision params to they have? How can I trace/interact with them using custom funcs()?

What will happen if I hypothetically set the BWAttachment's radius to be so small, that the pawn will actually "protrude" through it and be "bigger"?

Can't we trace the HP's at all without using BWA? Example: launch a trace and see if we hit a Pawn, and if so, just do the normal HPTrace() to see which HP we hit? What's so special about class ROCollisionAttachment extends Actor native; That is the actual Parent of ROBWAttachment? The only info we have is: // An additional collision cylinder to assist in detecting special traces Thanx.