Quil Evrything
DUST University
Ivy League
240
   |
Posted - 2013.10.18 00:37:00 -
[1] - Quote
(apologies for tooting my own horn a little, but perhaps it will help to have the post paid more attention to:
I've done a bit of UDK development, so I know a little about the complexity of issues involed)
People have been complaining about nova knife hit detection. So far, what I've read from CCP indicates that the planned course is to add an automatic "lunge" feature.
However... I dont think that will fix the hurt properly.
(and perhaps you guys found that out the hard way, which is why no fix in 1.5?)
I would guess the reason for this, is latency issues.
I would like to suggest an alternative fix:
Have the hit detected on a smear of the enemy hitbox, rather than a point-in-time. Because whatever point in time is chosen, it's going to be "wrong" from one perspective or other.
Unfortunately, this might take some engine tweaking :-/ Going from memory, the UDK doesnt naturally support what I'm describing. But maybe you guys can come up with some way to make it work. Or you already have custom extensions, hopefully
Here's more specifics on what I'm suggesting.
(Ugh, I wish there were typographic subscripts in here! :)
-----------------------
We have two objects, aka Pawns: the knife weilding attacker, 'A', and the target player 'T'.
We will have two time indexes:
Time 'start', and time 'end'.
The delta between them is very small: possibly 10ms? basically, whatever you guys have a tick set for.
Then, we consider two positional representations for each pawn:
A_start, A_end, T_start, T_end
Both 'A' and 'T' have their own particular velocities which will be in effect, and get applied to A_start and T_start, to generate A_end and T_end as appropriate
The positional deltas can be so high, and the hit area of knives so small, that if you pick either T_start OR T_end as the position to calculate the hit, it may generate a miss unfairly.
So, it seems to me that the only fair thing to do, would be to calculate the hit on a BoundingBox that encompasses the normal hit box of T, at BOTH T_start, and T_end.
Effectively, you smear T along the path between T_start and T_end,and any intersection of the knives along that smear, counts as a hit.
--------------------------------
Now, the easy way out is obviously "well, just take the mean position of T between T_start and T_end, and use that for calc, instead of this fancy stuff"
But that will end up with very unsatisfactory results for the knife user.
This would not be clear to the average player as it stands.
However, I've played with two PS3s, side by side. When running, the difference between my view of players, and my buddy's view of players is, frankly, shocking.
Specific example:
We're involved in a sprint race to the same place, and we're both scouts.
In my view, I'm ahead.
In his view, HE's ahead!!
What is worse, the distance between us looks to be 2 meters!!
If you average that, that still means things are probably going to be off by 1 meter. Which is going to mean total knife fail for a huge percentage of the time, undeservedly, lunge or no.
You'll probably wonder what my network latency is like.
I'm sitting on FIOS (fiber), in los angeles. So you can presume my latency is "pretty durn good" by most standards.
|
Quil Evrything
DUST University
Ivy League
241
|
Posted - 2013.10.18 05:36:00 -
[3] - Quote
Joel II X wrote:I rather have the sprint charge and the hit detection fixed rather than the lunge attack.
I think you're missing the point. There is no *easy* way to "fix the hit detection", due to the latency issues I brought up.
What i described above, is what I believe to be perhaps the only way to attempt to reasonably fix it, to the knife users' satisfaction.
Just about any other way, will be to the non-knife users' satisfaction, since they wont get knifed as much  |