|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Csikszent Mihalyi
DUST University Ivy League
100
|
Posted - 2013.09.05 23:05:00 -
[1] - Quote
Master Jaraiya wrote:Garrett Blacknova wrote: doesn't trace a line and keep that line in place, or shake it around a bit and apply a tiny amount of damage every time. It traces a line that doesn't stay in place, then traces another line for the next bullet, and each time one of those lines touches a valid hitbox, it applies damage to the target. This is a bit more in depth definition of hitscan than any I have been able to find. Basically what you are saying here, is that when you fire your weapon, multiple hitscan lines are produced. (one for each "bullet"?) Does each one of these hitscan lines have a beginning and end? How long are the hitscan lines? Why is it that, when I get shot by an AR at range, the damage does not occure immediately? From everything I have read about hitscan, that is how it works. The damage is simultaneous with the pull of the trigger. Do you see the questions this raises?
Yes that is what he is saying, and he is 100% correct. Each time damage is calculated, the code has to run a trace from the point of attack to the nearest point of impact (or maximum range of the weapon). That's a rather expensive operation, but a lot more efficient than an actual projectile. This is what happens every time a bullet is fired from the AR, and many times in quick succession for "continuous" beams like the laser rifle. Unfortunately, there is no such thing in programming logic as to put a line somewhere and get notified whenever something crosses it. Code doesn't work like real life. :)
While there is no reason why fast traveling bullets could not be implemented as a projectile with accurate ballistics, doing so generally costs a lot in terms of performance, is harder to compensate for lag, and doesn't really gain you much at all in terms of gameplay. It's usually only done in games which go absolutely hardcore on simulating realistic gun physics.
It's practically impossible to figure out whether a bullet is implemented as hitscan or projectile from circumstantial evidence alone. But hitscan would be the more logical choice, and several people have reported that CCP confirmed that those weapons are indeed hitscan so I see no reason to think that they are lying. |
Csikszent Mihalyi
DUST University Ivy League
100
|
Posted - 2013.09.05 23:09:00 -
[2] - Quote
Master Jaraiya wrote:Garrett Blacknova wrote:Master Jaraiya wrote:Everything I have stated, was backed either by my own experiences or by references.
If you cannot think of any other way to discuss this other than the condescending tone you have taken, then leave my thread. As much as you would love to think otherwise you don't know everything. Most of what you have said is completely baseless, unless you want to count other people's posts as your "references" EZMode reference courtesy of Wikipedia: http://en.wikipedia.org/wiki/HitscanIt was posted earlier in the thread, but you should probably go back and actually read it. The page also cites a variety of examples that are described by actual game developers as hitscan. Care to provide a reference that contradicts that (correct) definition? Quote:if an object is detected in the path of the projectile, a hit is registered. Since the effect is immediate, the projectiles effectively travel at infinite speed and have a linear or otherwise simple trajectory GÇö a practical approximation of a bullet's speed and accuracy over short distances (emphasis added) From the Wikipedia page, which I did actually read. So this is saying that hitscan is pretty much simultaneous with trigger pull. Well, damage output in DUST is not simultaneous with trigger pull.
When you shoot, damage output is delayed by latency. When you get shot, it's quite impossible to tell how the tracer animation that is rendered corresponds with the damage you receive. It could be that you are seeing a tracer from a previous bullet for example, before being hit by another bullet. Or it could even be that DUST includes some fancy logic to delay damage output based on distance, to simulate an effect you are describing. Bottom line is, that it's impossible to tell the difference. |
Csikszent Mihalyi
DUST University Ivy League
102
|
Posted - 2013.09.06 13:57:00 -
[3] - Quote
Master Jaraiya wrote:Lurchasaurus wrote:your letting your brain play tricks on you because you keep leaning on what your eyes are seeing via the bullet animations rather than what is actually happening.
bullet animations are purely cosmetic and do not actually represent what your gun is doing aside from telling you if it is being fired or not. Actually, I am basing this off of how I receive damage from long range shots, not the animations.
But how can you do that? When you get shot, how do you know that the tracer you saw was from the bullet that hit you moments later, rather than a previous bullet. This would require some very deliberate testing to be sure.
I think the fact that we generally don't notice bullet delays when shooting at something (other than the network latency) is much stronger evidence that no such delaying exists. Also it doesn't really make sense for a technical reason, which is a bit difficult to explain:
If there is code which delays application of the damage based on distance, the hit detection would still have to be based on the initial scan (because that one tells you the distance to base the delay on). This means that even if the target then moves, it would still be hit with no chance to dodge the bullet. Why would CCP do that? And even if it's in the game for some reason, the actual relevance for gameplay would be close to nil anyway. |
Csikszent Mihalyi
DUST University Ivy League
104
|
Posted - 2013.09.06 15:14:00 -
[4] - Quote
Garrett Blacknova wrote:Master Jaraiya wrote:Good point. It would definitely require some deliberate testing. Two players would have to be on coms, one says when he fires the other says when he gets hit. Even that is subject to variation because of the delay sending information via the battle server.
You are not going to see the bullet tracer before your client is informed about the shot event by the server, so some information could be gathered this way.
All you need to know is whether the other person is going to fire a single bullet at you. Then you can compare the moment you see the tracer to the moment you receive damage. Then try this at various distances to see if there is a noticeable difference.
Chances are, that you will not even see a tracer for a single bullet that hits you. That in itself would be quite telling already though. |
|
|
|