y can make ur own zoomsettings




// ===== ZOOM =====

bind SPACE "+ybl_zoom"

alias +ybl_zoom "+zoom ; bind MWHEELDOWN cg_zoomfov 15 ; cg_zoomscaling 1"
alias -ybl_zoom "-zoom ; bind MWHEELDOWN weapon 6 ; cg_zoomscaling 0 ; cg_zoomfov 40"



add sens and accel as u wish it

I believe the sens cap stays the same and offset has to do with how fast you move your mouse. In other words I believe they are not effected at all.

Thanks for the answer. Well i'm using offset 4, senscap 7,fov 90, zoomfov 70. Could someone please post a method to adjust this?

dont use offset imo

Why? It's good for lg and rg.

Lmao at all these accel question and problems
It's 2014, time to finally get that accel sucks

k1llsen, rapha, cypher, cooller, strenx, evil, avek, dahang, spart1e, kook all use some form of accel. Why do you even bother commenting?

cypher uses 0.01 at 400 dpi 0.018 yaw which is like non-existant
cooller doesnt use accel anymore
strenx and evil use kinzu v2 which i wouldnt qualify as shitty ql accel
spart1e uses no accel as well

strenx and evil kinzu v1, and it's accelled.

Also even though cooller and cypher don't really use accel now, they did for most of their career.

ye typo i meant v1

v1 doesnt really have linear acceleration, it's more like a dpi boost after you pass certain speed. And in general proper hardware linear acceleration would be muuuuuuuuch better than ingame one due to fps independency and superb consistency

especially with 250 fps cap where some might ppl dont get max fps constantly accel behaves oddly
also http://drok-radnik.com/junk/kinzuaccel_wmoref.png

I'd like to know how that graph was made, because it's quite different from the graphs I've got, and I went to great lengths to get the data.

For example here was an old velocity graph for 400 dpi: http://imageshack.com/a/img842/5949/8ik6.png

The kinzu v1 registers much more counts/speed here.

When I looked at it more closely with a more finely tuned program, the data revealed something more like an order 6 polynomial. It's curvy.

I had the graphing program approximate it to an exponential, this is what I got:

cl_MouseAccel "4.40293"
cl_MouseAccelPower "1.080540807053333"

That's at 400 though, and I wanted to test it at 800 to see how it changes things, if it seems like a logical extension to the 400 curves, etc. It took me a month to write the program, then another program to sort the data, then to get a reasonable graphing program for it, and by then it was close to Christmas and I was exhausted so I kind of just abandoned the project :-/

Method: Jammed two mice together and waved them around for about 10 seconds, logged counts with a glovepie script and fed data into excel.

Result: I got your attention and now we get to see your real results of actual testing. Thanks

ye its pvh's work sorry for kinda stealing it and not linking it

Doesn't glovepie use windows cursor though? I didn't want it subject to cursor ballistics (even fixed) so I wrote a windows program that uses wm_input. I mean I want to be sure that it's using counts and not pixels or w/e.

I used the same two mice method, which unfortunately has the drawback that a kind of sharing occurs. Like 2-3 counts will be given from one mouse, and then 2-3 counts from the next. This makes for some pretty messy data.

Glovepie can read directinput and address individual mice, and its also easy enough to work with that I didn't have to learn anything new. I had both mice at 1000Hz and logged counts for each mouse every 1ms. I imagine that if either mouse had a slightly longer polling period than ideal, it may log the same count twice.

Another concern with measuring the kinzu v1 relative to another mouse is the angle snapping skewing results (need to measure only 1 axis at a time).

I also think my method of measuring count-for-count has the problem of lacking context. The sensor apparently captures at 9375fps internally and if the accel is happening at this point, then a count of '15' (for example), may be the result of accel if the mouse was moved quickly recently, or may not be an accelerated count if the mouse was moved steadily at 15 counts per usb polling period.

Glovepie can read directinput and address individual mice, and its also easy enough to work with that I didn't have to learn anything new.

I don't trust dinput either though :-/

I had both mice at 1000Hz and logged counts for each mouse every 1ms. I imagine that if either mouse had a slightly longer polling period than ideal, it may log the same count twice.

I could only get the v1 to run at 500 Hz, so I made both mice run at 500.

It seems to always share the polling, even if it's only one for me one for you.

Another concern with measuring the kinzu v1 relative to another mouse is the angle snapping skewing results (need to measure only 1 axis at a time).

I only measured the horizontal axis.

I also think my method of measuring count-for-count has the problem of lacking context. The sensor apparently captures at 9375fps internally and if the accel is happening at this point, then a count of '15' (for example), may be the result of accel if the mouse was moved quickly recently, or may not be an accelerated count if the mouse was moved steadily at 15 counts per usb polling period.

It's crazy because it sometimes puts in extra counts and sometimes does not, it's only over some distance that I can get a clean picture. It's a scary thought that optical mice are sending out all kinds of crazy counts that just happen to average out so that we don't notice.

Ideally you'd get counts spread out nicely over the mouse motion. After all your hand isn't changing speeds dramatically, a mouse swipe is pretty much just a languid gesture.

It's not linear, I agree with that having tested it thoroughly.

It's not like a dpi boost past a certain speed though. It's kind of curvy.

Yeah. What do you think is the best cpi-preset in general for Kinzu v1?

No idea at this time, er by what criteria would a given cpi be best for it?

In terms of built-in accel-feedback.

So you would want less accel, or more, or a specific curve?

I'm probably not going to test anything except 400 and 800, if that.

Less accel - or linear, if possible.

What Snow_crash said plus a dozen of other top players(and actually better aimers) who don't use it. Why did you bother argumenting like this?

If cypher's accel has no effect why would he use it in the first place?And why would cooller use a very similar value as cypher if it had no effect (last time he was talking to kook about he used a very similar value). and spart1e uses a xai which has some accel.

spart1e uses zowie EC evo for quite some time now.

cooller : no more accel for him aswell.

zowie EC limited blue edition, which has the old sensor(also with prediction...)

Accel is actually superior.

accel for duel, no accel for tdm/ctf

depends what style you want to play. if you want to play hitscan-only-distance-faggot style then no accel is ok in tdm.

so all of colwn is hitscan-only-distance-faggot style?

yup, there are more entertaining players around

Not in this universe.

ACCEL FTW.

yup only "beginners" think accel is shit :)
Also from my experience( and i have way more than what u can see on my profile ;) ): rockets are far more important than shaft and rail(and i WAS a shaftwhore)
Btw most players without accel are like fucking snails compared to the ones with accel they react like 80 year olds ;) and will never be the best players. Keep playing and I hope for you, you will realise it before the game is rly dead bro *_*

it's all love tho..I thought the same.

cuz h8m3 is obviously such a beginner : D

Senscap and offset aren't scaled by zoom.

Seems odd to scale senscap, but if you really wanted to I guess you could just by multiplying it by the zoom algo.

As for offset, this is tricky, because you'd have to say something like using half your sensitivity results in movement speeds twice as fast and then scale it accordingly. Of course they don't in practice, at least not necessarily. So it's kind of a complicated mess.

Really though, this would seem to not to be an issue based on what you described, since most people don't move the mouse fast while zooming imo. If you wanted to be sure that it wouldn't go over the offset under any circumstance, you could just raise it to some high number while zooming, but like I said you shouldn't need to.

Lorfa to the rescue! About offset couldn't you just scale it by the zoom algo too?

It's a velocity, not a sens so that would be an odd thing to do. Would also be scaling it up as opposed to down for what you're describing.

If you're worried about accel kicking in when you're zooming, why not just increase the offset by some arbitrary amount like 2x (offset 10 while zooming as opposed to offset 5).

If offset is a velocity and i wanted it to release the same speed in my zoomfov as my fov can't i just keep it the same value?

Edit: Unless i haven't been explaining things properly i want offset and senscap scaled to my zoomfov like zoomsens 1.

Also the reason i want this is because i zoom with lg which means i will hit the offset a lot and i need it to be scaled to be consistent.

I don't understand the question. Here's how it would work for example:

400 dpi sens 4, accel 0.1, fov 100, zoomfov 50

k = ~0.5

When zoomed in sens will be ~2 and accel ~0.05

If the offset is 5, mouse has to be moving 0.3175 m/s for accel to kick in.

When not zoomed in, sens would be 4 up until that point.

When zoomed in, sens would be ~2 up until that point.

The only like, relevant argument to be made here that I can see is that perhaps at sens 2 you would be moving the mouse faster on average than at sens 4, and therefore might want a higher offset (a higher speed needed for accel to kick in).

You'd only want to adjust offset if you moved the mouse really fast when zooming for some reason (weird) and you thought that maybe you'd move it fast enough for accel to kick in which I guess is undesired behavior in this case.

Even if it did reach the offset speed, the sens increase is starting at a lower base sens (2), and would increase more gradually (0.05 as opposed to 0.1).

So if you were paranoid about this, you could just bundle +zoom with and increase in offset to prevent this from happening.

It's very hard to arrive at some exact value to match your overall increase in mouse speed due to the lower sens though. This would require knowledge of how fast you move the mouse on average at a given sens, and then increase the offset accordingly for when zoomed in based on how the sens is scaled.

It's infinitely simpler to just leave offset as is, unless you feel that it is hitting the offset speed and throwing off your aim while zoomed, in which case you could just have it increase with something like:

alias +zm "+zoom ; cl_mouseaccelOffset 7"
alias -zm "-zoom ; cl_mouseaccelOffset 5"
bind [key] "+zm"

Lol i feel bad for asking you all these questions i have no idea about. Well i don't want to bother you any more so this will be my last post. What i mean is regardless of sens will offset kick in at the same mouse speed?

Ok i reread that and im guessing the answer is a yes. I was trying to make senscap and offset scaled like accel and sens in zoom. And i scaled senscap by using the zoom algo but i was trying to figure out how to scale offset and i was looking it as a sens instead of velocity which is why i thought it needed to be scaled. thx a lot.

Happy to answer questions (or try to).

Ok, i got another question. I want the opposite of what i wanted before (offset scaled to main fov, not zoomfov in zoom) I've being thinking about it and realised i don't have to change the offset at all again. I just gotta use the zoomfov algo to modify the sens/accel/senscap and use it when i zoom and the offset will follow. Am i right in my theory?

sens and accel are already automatically scaled.

Since they both get lower, it is unlikely that you would reach the senscap there, and so it is not scaled as this seems unnecessary.

If you wanted to reach the senscap "sooner" while moving in a zoomed state, you could scale it manually. Just add a senscap "k * senscap" to a +zoomalias.

Offset is also not scaled, as with senscap this seems unnecessary. So don't need to do anything special there.

Yes, i know sens and accel is scaled to zoomfov which is why i'm descaling it. By descaling it essentially offset will be scaled to the main fov when in zoom. So to summarize what i'm trying to say

If you want sens/accel/senscap/offset scaled to zoomfov while zooming you only need to scale senscap and everything else is auto-scaled/don't need to change.

If you want sens/accel/senscsap/offset scaled to main fov while zooming you need to descale sens/accel/senscap and keep offset the same.

Basically using the zoomfov algo where you would usually put your "zoomfov" and "fov" you switch them around to descale it. Sorry it's really hard to explain this properly.

Yes, i know sens and accel is scaled to zoomfov which is why i'm descaling it.

That would feel terrible though!

You could just make an alias that changes the fov and these won't be scaled for example:

alias +zm "cg_fov 60"
alias -zm "cg_fov 100"

By descaling it essentially offset will be scaled to the main fov when in zoom. So to summarize what i'm trying to say

Offset won't be changed if you +zoom, or if you +zm like above. Any scaling will have to be added to an alias. This is something that most players aren't concerned with.

If you want sens/accel/senscap/offset scaled to zoomfov while zooming you only need to scale senscap and everything else is auto-scaled/don't need to change.

senscap and offset are not scaled, would have to be done manually if this is something you wanted (and it's an unusual thing to want).

If you want sens/accel/senscsap/offset scaled to main fov while zooming you need to descale sens/accel/senscap and keep offset the same.

You could keep them all the same by doing the above +zm alias. The result will be very uncomfortable.

Basically using the zoomfov algo where you would usually put your "zoomfov" and "fov" you switch them around to descale it. Sorry it's really hard to explain this properly.

Yes you would to descale it if you preferred a mathematical route.

For example:

cg_fov 100, cg_zoomfov 60

sensitivity 4

k = 0.5602

Sens when zooming = 4 * 0.5602 = 2.2408

2.2408 * x = 4
x = 1.78508

So the scaling can be eliminated between this fov and zoomfov with:

cg_zoomSensitivity "1.78508"

Why do it this way when the simple +zm alias above eliminates any scaling though, and why would you want to eliminate the scaling. This makes the sense feel very very high when zooming.

Only difference is that you won't see the zoom animation if you're someone who uses cg_zoomScaling 1 with the +zm alias.

Do what I do and scale m_pitch and m_yaw. It will change all other values.