115 réponses à ce sujet

[Heldarion]

Element 0 wrote...

RTK2Lional wrote...

Dunvi wrote...

once you start the twitch reaction, you body/mind knows the time it'll take you to arrive at that location

How do you know this in the context of the game?

Standard reaction time test, average is about 200 ms. Test yourself:

www.humanbenchmark.com/tests/reactiontime/

Last but not least, IMO if you want to twitch shot with the crusader you are doing it wrong (i.e. twitch reaction times are mostly irrelevant). You have to be patient.

 

Mine was 225 

My average was 307.92

lol

I should go

[Heldarion]

Element 0 wrote...

Heldarion wrote...

Element 0 wrote...

RTK2Lional wrote...

Dunvi wrote...

once you start the twitch reaction, you body/mind knows the time it'll take you to arrive at that location

How do you know this in the context of the game?

Standard reaction time test, average is about 200 ms. Test yourself:

www.humanbenchmark.com/tests/reactiontime/

Last but not least, IMO if you want to twitch shot with the crusader you are doing it wrong (i.e. twitch reaction times are mostly irrelevant). You have to be patient.

 

Mine was 225 

My average was 307.92

lol

I should go

 

 how do you use the GI then? Crusader is obviously too advanced for ya :happy:

lolwallhax

[Tybo]

Heldarion wrote...

Element 0 wrote...

RTK2Lional wrote...

Dunvi wrote...

once you start the twitch reaction, you body/mind knows the time it'll take you to arrive at that location

How do you know this in the context of the game?

Standard reaction time test, average is about 200 ms. Test yourself:

www.humanbenchmark.com/tests/reactiontime/

Last but not least, IMO if you want to twitch shot with the crusader you are doing it wrong (i.e. twitch reaction times are mostly irrelevant). You have to be patient.

 

Mine was 225 

My average was 307.92

lol

I should go

I had 240.

But reaction time research in sports has shown that it has little correlation with actually being good.  Prediction is much more important:  professional athletes show pretty much typical reaction times.  They're just really good at predicting what is going to happen from subtle cues and memory, avoiding the need to react.

I imagine the same generally applies to video games

[Caratinoid]

Heldarion wrote...

Element 0 wrote...

RTK2Lional wrote...

Dunvi wrote...

once you start the twitch reaction, you body/mind knows the time it'll take you to arrive at that location

How do you know this in the context of the game?

Standard reaction time test, average is about 200 ms. Test yourself:

www.humanbenchmark.com/tests/reactiontime/

Last but not least, IMO if you want to twitch shot with the crusader you are doing it wrong (i.e. twitch reaction times are mostly irrelevant). You have to be patient.

 

Mine was 225 

My average was 307.92

lol

I should go

It's just a bad mouse, mouse click takes time too.

[d_nought]

tyhw wrote...
They're just really good at predicting what is going to happen from subtle cues and memory, avoiding the need to react.

this

248ms

[Titus Thongger]

didn't someone test that higher latency affects this weapon's ability to time travel

[Dunvi]

Titus Thongger wrote...

didn't someone test that higher latency affects this weapon's ability to time travel

I know, and I looked up that old thread. It's here: The Crusader: Much worse at higher frame rates.

There are a number of problems with all of the conclusions drawn in this thread.
(1) I'm not convinced ammo counters are precise or guaranteed to be accurate within one frame.
(2) MaxShine is at half-precision due to only capturing 30 fps even though playing at 60 fps (he should have captured all frames, or lowered game speed, for a valid analysis).
(3) Incorrect assumptions - because we were (for some crazy reason) thinking that the gun fired according to a location before the one you fired at, we were looking at the pictures incorrectly. The way the gun actually works is that it takes your aiming data at the precise moment you fire, but then calculates impacts from that firing vector a whole 0.1 seconds later.

Knowing this now, we can reanalyze both sets of pictures.

Ty and Sirian's 60 fps tests are unfortunately unavailable. That said, they get at least the value that I anticipate, and frankly I'm only going to get an even larger delay if anything.

Ty and Sirian's 30 fps tests incorrectly assume the trigger pull was in "Frame 2" instead of "Frame 1" based on ammo counter. If we reanalyze with the trigger pull at frame 1, we get at 4 frames at 30fps, which comes out to 0.133 seconds.

MaxShine makes the same mistake. The trigger was pulled no later than frame 2 of his test, but possibly as early as frame 1. Hit detection was in frame 6. That means we have at least 4 frames of delay, which again is at least 0.133 seconds.

tl;dr looking for the wrong thing gave red herrings, watching for the wrong markers (ammo counter) and also relying on video data is inherently unreliable, and loss of precision means that a single value off gives two very different answers.

Ty, Sirian, MaxShine, forgive me for trashing your analyses

Modifié par Dunvi, 14 août 2013 - 07:12 .

[Tybo]

I always welcome trashing if my analysis is incorrect.

If I understand correctly, that means that the Crusader can actually be considered to function like a projectile weapon - pull the trigger, and the pellet will impact where the trigger was pulled, .1 seconds later. That actually makes it more palatable, though the lack of feedback (sound like the Javelin, or the actual projectile like the Graal) makes it much more difficult to calibrate.

Do you think this is affected at all by on/off host? Is the delay going to be consistent in your opinion?

Also, I did realize that ammo counters weren't exactly accurate from wraith/talon tests, where sometimes the ammo counter would update on the same frame as the impact, while on others the ammo counter wouldn't update until after the decals showed up. I just couldn't think of a better way to do it. And I never suspected that the decals would also be inaccurate...

[Dunvi]

tyhw wrote...

I always welcome trashing if my analysis is incorrect.

If I understand correctly, that means that the Crusader can actually be considered to function like a projectile weapon - pull the trigger, and the pellet will impact where the trigger was pulled, .1 seconds later. That actually makes it more palatable, though the lack of feedback (sound like the Javelin, or the actual projectile like the Graal) makes it much more difficult to calibrate.

Do you think this is affected at all by on/off host? Is the delay going to be consistent in your opinion?

Also, I did realize that ammo counters weren't exactly accurate from wraith/talon tests, where sometimes the ammo counter would update on the same frame as the impact, while on others the ammo counter wouldn't update until after the decals showed up. I just couldn't think of a better way to do it. And I never suspected that the decals would also be inaccurate...

Correct. The gun functions basically like a projectile weapon with no feedback (tracers, sound) or AoE to help you time it.

Also, some significant differences with the Javelin and the Graal is that the Javelin aims according to the end of your delay, not the start, and the Graal has a spread, thus helping mitigate some of the precision issues.

Basically, the Crusader could have survived the weird-ass fire lag or the slug property, but both combined screws it over.

Also, the Crusader has non-zero min/max aim error values, which means it also suffers from the problem of being a very precise, slow weapon with the accuracy to accompany it, exactly the major problem with, say, the Saber.

It should not be affected by lag exactly like a projectile - off host, projectiles are insanely terrible because they are then handed over to the server to be calculated. With the Crusader, you as client are still managing the hit detection, so when the slug is fired (0.1 seconds later) it should calculate hits based on your local simulations of the enemies. That said, if you or the enemies are rubber banding, good f*cking luck.

ETA: Look, this is incredibly complex code... the problem with this kind of inheritance is that it's only straightforward if you understand the underlying classes. I don't, so I'm not guarenteeing correctness with anything here.

Modifié par Dunvi, 14 août 2013 - 08:12 .

[Titus Thongger]

can't someone mod it so the crusader behaves exactly like the saber?

[Dunvi]

Titus Thongger wrote...

can't someone mod it so the crusader behaves exactly like the saber?

Sigh.

If you had read the thread, you would see that we have 4, relatively easy to implement, potential solutions (assuming, of course, this is actually the bug - no guarantees). Those fixes would be astoundingly easier than altering the gun to use an entirely different weapon class.

Modifié par Dunvi, 14 août 2013 - 08:03 .

[the slynx]

So the Crusader has issues because it's a shotgun that doesn't act like a shotgun. Excuse my ignorance, but would that mean it wouldn't have these problems if the game thought it was, say, an Assault Rifle?

[MaxShine]

Dunvi wrote...

Titus Thongger wrote...

didn't someone test that higher latency affects this weapon's ability to time travel

I know, and I looked up that old thread. It's here: The Crusader: Much worse at higher frame rates.

There are a number of problems with all of the conclusions drawn in this thread.
(1) I'm not convinced ammo counters are precise or guaranteed to be accurate within one frame.
(2) MaxShine is at half-precision due to only capturing 30 fps even though playing at 60 fps (he should have captured all frames, or lowered game speed, for a valid analysis).
(3) Incorrect assumptions - because we were (for some crazy reason) thinking that the gun fired according to a location before the one you fired at, we were looking at the pictures incorrectly. The way the gun actually works is that it takes your aiming data at the precise moment you fire, but then calculates impacts from that firing vector a whole 0.1 seconds later.

Knowing this now, we can reanalyze both sets of pictures.

Ty and Sirian's 60 fps tests are unfortunately unavailable. That said, they get at least the value that I anticipate, and frankly I'm only going to get an even larger delay if anything.

Ty and Sirian's 30 fps tests incorrectly assume the trigger pull was in "Frame 2" instead of "Frame 1" based on ammo counter. If we reanalyze with the trigger pull at frame 1, we get at 4 frames at 30fps, which comes out to 0.133 seconds.

MaxShine makes the same mistake. The trigger was pulled no later than frame 2 of his test, but possibly as early as frame 1. Hit detection was in frame 6. That means we have at least 4 frames of delay, which again is at least 0.133 seconds.

tl;dr looking for the wrong thing gave red herrings, watching for the wrong markers (ammo counter) and also relying on video data is inherently unreliable, and loss of precision means that a single value off gives two very different answers.

Ty, Sirian, MaxShine, forgive me for trashing your analyses

Later I was able to precisely determine the trigger pull frame by binding two actions to the fire butten(screenshot+fire). This showed that the gun shoots at the precise position of the cursor in the trigger pull frame. This also showed that the ammo counter is completely unreliable in determining the trigger pull frame. The ammo counter is updated several frames after the trigger is pulled.

The old pictures/vid actually confirm the time of about 0.1s (approximated as 4 frames @30fps? and I guess as 7 @60fps) the hit detection looks back that you mentioned.

Modifié par MaxShine, 29 octobre 2013 - 07:31 .

[Jaun Shepard]

And I thought time travel was not possible good job OP you just broke physics.