The technique of rail 'sweeping'

[Pr0c3550r]

It may not have been him. It was the craziest thing i've ever seen. Couldn't tell what the guy was looking at as he was shooting or moving around the map for that matter. There were many specing and would agree with me  including nincumpoop (I remember him being there but not the guy doing it. haha).

And processor adds a good point, what would be the difference between this and a flick shot. I'm assuming flick shot you are stopping right on the target where sweeping shot you are moving through the area where you target is...?

Correct, as you flick then the hand eye coordination takes over, so as you flick/sweep that's when ya pull the trigger. The nice thing is it does not matter if your target is moving left or right.

Here I am giving rail tips, lol
But it does work


Peace

MORE: Mr._X and I had the opportunity to play in a LAN a few years ago. We talked about the "FLICK" shot.
He seemed discouraged that he could not do it. He pointed out to me that , That was my edge in railz.
I am sure he can do it now.

Peace again

[|iR|Sk1llSh0t]

Flick shot is one of those things I believe can only be done well (emphasis on well) with a high fps. Until the last month or two, I had only been playing at 60 fps and could not for the life of me hit a flick shot consistently. I never understood how gamers could do it on a regular basis. When I discovered my vid card was capable of 1000 (+/-) fps, I all of a sudden found myself picking people off with the flick on a much more consistent basis. Those extra frames really do come in handy.

[Jay Dolan]

Some of you watched Wanted one too many times.  It doesn't work that way.

 

[VaeVictis]

lol skillshot, flick shots are just something you get from practice no one lands flick shots 100% of the time, but the more you practice the more you will land... its just a muscle memory thing, your head does some quick calculations without you even realizing, and you flick your hand the correct distance

it is made SO much easier if you turn acceleration completely off though... accel screws up aim bad :/

[|iR|Sk1llSh0t]

I realize it is just a practice thing. I'm just speaking from personal experience that the increased fps has raised my ability to hit a flick shot by %75 or more. My acc may still be low compared to other top level players but I'm beating a lot of people now I haven't come close to beating in the past. Something about only getting 60fps made it incredibly difficult to get the timing right. Not to mention 1 of every 3 shots were clicks. After increased fps, no more clicks, and I can actually hit a flick shot. I believe I have always had the muscle memory. Just didn't have the setup to do it properly til now.

[VaeVictis]

I realize it is just a practice thing. I'm just speaking from personal experience that the increased fps has raised my ability to hit a flick shot by %75 or more. My acc may still be low compared to other top level players but I'm beating a lot of people now I haven't come close to beating in the past. Something about only getting 60fps made it incredibly difficult to get the timing right. Not to mention 1 of every 3 shots were clicks. After increased fps, no more clicks, and I can actually hit a flick shot. I believe I have always had the muscle memory. Just didn't have the setup to do it properly til now.

probably all in your head honestly, i assume your 1k fps is just frames rendered...

what kind of settings are you using?

cl_maxfps 60 and r_maxfps 1000 with cl_async 1?

the frames rendered wouldnt effect input at all, just the amount of frames rendered and thrown up on the screen smoothing out your visual a tiny bit.... cl_maxfps is what deals with packets transferring to the server and my accuracy is pretty much the same from 30 to 120

im 99% sure you are using settings like the ones i posted, because a async set to 0 will tie those two values together, and anything over 125 for your cl_maxfps will drop you from the server for flooding

my two favorite cl_maxfps values are 66 (seems a little smoother for jumps) and 120 (allows a few jumps i cant do on 66)

also if you feel like playing around with it, note that a change in cl_async requires a client reset (info from slugs, he might have just been complaining, but hes a pretty good jumper so it might be right)

[|iR|Sk1llSh0t]

You might be right about it being in my head. Pretty huge psychological change though. I'm convinced the frames have contributed some

My cl_async = 1. cl_maxfps = 140. I don't have my r_maxfps set in cfg so it is whatever the default value is i'm guessing. gl_swapinterval = 0 is the setting that boosted my fps from 60 to 1000. until i changed swapinterval, no matter what i did, i was stuck at 60 as my maxfps.

You are right, when i say 1000 fps, i do mean rendered frames on the client. not what is on server side.

I haven't been booted for having 140 on maxfps. maybe i'm being throttled? not sure.

[VaeVictis]

You might be right about it being in my head. Pretty huge psychological change though. I'm convinced the frames have contributed some

My cl_async = 1. cl_maxfps = 140. I don't have my r_maxfps set in cfg so it is whatever the default value is i'm guessing. gl_swapinterval = 0 is the setting that boosted my fps from 60 to 1000. until i changed swapinterval, no matter what i did, i was stuck at 60 as my maxfps.

You are right, when i say 1000 fps, i do mean rendered frames on the client. not what is on server side.

I haven't been booted for having 140 on maxfps. maybe i'm being throttled? not sure.

140 is a tad high... honestly id assume thats a little unstable, drop it down to like a cl_maxfps 90 and see how it feels and might as well set r_maxfps 1000 cause that will render at 1k fps STABLE, if you go up and down at an fps it is less desirable

[Paril]

I want to have the experts possibly explain what type of 'flaw' this tecnique uses, or possibly exploits... I think because it sends alot of info to the server and it gets flooded, then it gets confused, possibly uses lots of cpu and to compensate for being slow just rounds all the waypoints off and then awards the player the kill...

Hi, just a technical note about some of the client->server communication details. . . .

It turns out the client doesn't send more or fewer packets to the server whether you have the mouse button down or not, or whether you are vigorously sweeping the mouse/view angles.(*1)

The client sends a movement/button delta packet to the server each time the client renders a new frame.(*2)  It doesn't matter how frantically one might try to click the mouse buttons, or sweep the mouselook view angles - the client only sends packets to the server at a fixed rate.

So whatever the explanation for the behavior characteristics you're experiencing, it shouldn't be connected with the client sending more data to the server, because clicking the buttons and dragging the mouse doesn't increase the packet rate, and shouldn't appreciably increase the data rate.

So whatever it is, I don't think it will turn out to be an issue of the server getting flooded.

Regards,




(*1)Although, in a given packet, it can omit data that was unchanged since last time.  But the packets are still sent at a constant rate.

(*2)In r1q2 clients, with cl_async 1, the packets per second sent by the client to the server is no longer tied to the video frame rate; but still, button presses and mouse view angle sweeps will have no effect on that packet rate.

The packets are sent at a constant rate but the length of the data varies, not like that matters though.

I think because it sends alot of info to the server and it gets flooded, then it gets confused, possibly uses lots of cpu and to compensate for being slow just rounds all the waypoints off and then awards the player the kill... I've observed many other players do this regularly and it works quite well for them.

Plain wrong.

I can only explain this technique as attempting to do your own prediction in your head - there's no way "sweeping" will make anything easier.

Also, a higher FPS will cause you to call ClientThink more often and be jittered around towards one specific direction (towards the water in q2dm1); look down, move forward and backwards with cl_maxfps 30, then do the same thing with it at 500, you'll see what I mean. 66 is about the magic "max jump height to jitter hit" number; Vae's mention of the special 120 or so is probably because he's being jittered directly at the frame where he touches the lip and gets pushed up onto the object.

swapinterval has to do with double buffering. You may have been locked at 60, but it wouldn't of looked any slower (just like vsync). A higher FPS does not specifically mean that you're running any better; vsync tends to help reduce the amount of wasted cycles rendering frames you don't even see.

-P

[Jay Dolan]

While v-sync / swap interval (they are one in the same, btw) definitely improves visual quality (by eliminating screen tearing), it also incurs some very noticeable latency on input.  You might notice that your mouse "feels laggy" with gl_swapinterval 1.  This is because at 60fps, each client frame is 16ms long, and so there's roughly 8ms of implicit latency on any mouse movement you provide.  That's well within the range that humans can perceive pretty easily.  That's why, generally, folks prefer cl_async 1; cl_maxfps 60; r_maxfps 250 or higher.  Once you get over 250fps, screen tearing isn't often perceivable.

Of course, the best way to go would be v-sync plus one of those brand new 240hz monitors

[Paril]

Ah, fair enough; is swap interval the precursor to the current "vsync"ing or just another term for it?

Personally I've never noticed any input difference on EGL whether I'm at 500 fps or a constant 60; I don't know if this is just because of the way EGL works or not.

-P

[Jay Dolan]

Swap interval (which is what the function is called in OpenGL -- hence the cvar name) governs how the video card driver will swap the frame buffers.  The way things generally work is that you have two frame buffers (front and back).  Your scene is rendered into the back buffer while the front buffer is "visible" to the monitor.  In order to avoid screen tearing, the swap interval control causes OpenGL to block until the monitor is ready for a new frame buffer.  Then, when the monitor is ready, OpenGL "swaps" the front and back buffers, allowing the monitor to see the newly rendered frame.  Make sense?  V-sync == gl_swapinterval 1.  You can also set gl_swapinterval 2, if for some bizarre reason you wanted to run at 30fps but with no screen tearing

Setting gl_swapinterval 0 tells OpenGL to not wait for a vertical refresh when you call glSwapBuffers, and thus you have no implicit framerate cap, but you may see tearing.

[erik]

I realize it is just a practice thing. I'm just speaking from personal experience that the increased fps has raised my ability to hit a flick shot by %75 or more. My acc may still be low compared to other top level players but I'm beating a lot of people now I haven't come close to beating in the past. Something about only getting 60fps made it incredibly difficult to get the timing right. Not to mention 1 of every 3 shots were clicks. After increased fps, no more clicks, and I can actually hit a flick shot. I believe I have always had the muscle memory. Just didn't have the setup to do it properly til now.

I was going to say...the past few times I have played you I have noticed a drastic improvement, and it led me to one of two conclusions - that I got worse or you got better.  I don't play as much anymore, and will definitely not be on much at all in the coming months because I just got an unlimited golf membership at my local golf course. 

But to the point - I don't think I'll be beating you anytime soon. (I am Kapolsky)

Side topic - the high ping player, "wood" - is that alpha in disguise?

[fdrjk]

Side topic - the high ping player, "wood" - is that alpha in disguise?

Yes, suh.

[Sgt. Dick]

So you been playing with "wood"