I would love to know this!

You might also try asking over at overclock.net, although I haven't had much luck there with mouse questions lately I think it's still worth a shot.

watching thread.

this sounds like a job for the sujoy turntable

while we're at it...any way to unify mousefeeling on and off weed?

kinzu rox. but abyssus is still $$$

so noone knows what's the actual accell?

its between 0.10 and 0.15 but its not easy to portray it in ql numbers
it varies its not exact and the curve is different

That would be different one different DPI too

So I did some quick tests...

kinzu @450dpi on 1.0.7 drivers sense 2.4.

replicated with Zowie FK @450 dpi:

cl_mouseaccel 1
cl_mouseaccelpower 1
cl_mousesensecap 2.75
cl_mouseacceloffset 2.75
sensitivity 1.75

I didnt fine tune or anything so I am pretty sure they can be done better....

It might feel correct but its not for example strenx why doesnt he get to very high sens?
Because its not a constant amount of accel and is either low or depends on sens at the moment
I might be wrong

mouseaccel 1??? lol

sensecap is the key

This is a joke, those numbers would be identical to:

cl_mouseaccel "0" (default)
cl_mouseaccelPower "2" (default)
cl_mouseSenscap "0" (default)
cl_mouseacceloffset "0" (default)

sensitivity "2.75"

power 1 would be just sens + (accel calculations)^0 which would be sens + 1.

You are right. Those are the wrong values, must have mixed them up with some other experiment :P

these are the ones I tried to get similarity with kinzu:

Sens 1.6
accel 1.2
accelpower 1.2
offset 1.5
sensecap 3

How exactly did you go about "trying" to get similarity with the kinzu? Why senscap? Does it stop accelerating after a certain point?

I can believe the offset, but did it really appear not to start accelerating right away?

These values are hard to believe.

Take this graph here:

http://img715.imageshack.us/img715/3347/accelcomparison0.png

The y axis is sensitivity, going from 0 to 11, and the x axis is speed in counts/millisecond ranging from 0 to 11. (For example at 400 cpi, 5 counts/millisecond is 0.3 m/s)

The blue line represents the same base sensitivity of 1.6, but with accel 0.5, offset 0, power 2. This is rather close to rapha's accel.

The red line represents a base sens of 1.6 with accel 0. Imagine the grey line joining with it when x is 1.6.

The grey line represents the values you posted. As you can see the accelpower of 1.2 (it is subtracted by 1 in the code, rendering the exponent 0.2) is actually kind of flat. Nothing along the lines of the kind of positive accel that is typically reported for the kinzu v1.

Well,that graph described my impression on how the kinzu works rather well :P

My "method" consisted of trying to find a similar base sens ie the slow kinzu movement(I have both connected).

Then I added some accel and tried to find a sensecap that would simulate the low m/s limit of the kinzu sensor.

Then I played with the offset to find a point where the accel started that felt similar. After that power and accel values were messed with until I found something that felt good enough. I am by no means saying that its perfect but it felt similar enough for me.

Feel free to post some better values, I am curious :)

Also, the kinzu drivers is really wierd in general. Expecting settings to feel the same after every save is expecting too much. I use (400/800, 800/1600,1600/3200), other values may also differ in feeling.

I think a better test would be as follows:

Set 800 cpi, since it is arguably the most common value people use for the Kinzu, next would be 400, followed by the other values.

In Quake Live make sure in_mouse is 2, and do devmap <somemap>

Make sure cl_mouseaccel is 0. Type in viewpos to see what your orientation is in degrees. It is the last number shown.

Place two heavy objects ideally with a straight edge on your mouse pad at a precise distance, say 15 cm apart.

Set a sensitivity of say 15 cm/360, at 800 cpi this is sens 3.46364 with of course m_yaw 0.022

Leave m_pitch as it is, so you can see what error ratio exists by the mouse not going perfectly straight between the two objects. Also a 360 turn is preferred since you can also compare the starting image with the ending image.

Mind the mouse cord so that it doesn't make any big influence. I tend to pull the cord straight when moving the mouse and use both hands.

Use a stopwatch with a readout that you can see clearly and take note of the starting time and ending time of your motion so that the speed can be calculated later.

Make the motions between the two objects at different speeds, taking note of the starting and ending times, and how close or far it got from the 360. Type in viewpos to see the difference in beginning and ending angles. Do your absolute best to make sure the mouse moves at a steady speed.

The more measurements you do the more accurate the picture. If you could do at least 5 it would give a rough idea. We can plot the info on a graph and then connect the dots to create a curve, and then look for the appropriate values that fit that curve.

I believe there is a utility on overclock.net somewhere that can automate this process and do a much better job. I will look for it.

I am currently swamped, will try this when I have the time.

"kinzu @450dpi" ^ ^ rly?

buy a kinzu

The kinzu v1 won't be around forever you know.

The v1 that evil and sk forest use are no longer available.

f0rest uses the kinzu v2 pro since cs:go i'm pretty sure

but you're not sure ? :D

unless he ninja'd his mouse selection around

kinzu v2 pro 400 dpi/4 sensitivity

ok :)

good to know

ive got my kinzu and i can say, it looks almost impossible to replicate it, because its curve is really different my normal settings are
WMO, sens 2, accel 0.04

when i put kinzu with sens 1 accel 0 and 800dpi, it feels similar but still i cannot get the same feeling, because its curve is so much different, alsi sometimes looks like kinzu has negative accel too :S

What version do you have? The v2 is no good.

v1, I have found it on ebay for 25dollars I guess, it was a good deal i think, but now it feels reallly awkward after WMO

Wasn't there consistency issues with the v1? I remember Strenx having to use the same Kinzu v1 mouse because when he tried others they felt different. When that broke he went back to the logitech mx series and his lg hasn't been the same since.

Evil now using Strenx's old setup is the lg king right now.

consistency issues? like what?
and i knew that v1 has some good quality accel mechanics, thats why i bought it, but i need to use it a bit longer(came like 5hours ago :)

I heard strenx went back to kinzu v1 after using the mx518 for a bit.

I heard that Evil doesn't use the same settings as strenx, only the same mouse and mousepad.

maybe the other kinzu had drivers installed at one point, and therefore the firmware was updated resulting in a rediculous amount of prediction afterwards:

http://i.imgur.com/Qoak7.jpg

Also posted here:

http://www.overclock.net/t/1369400/steelserie...celeration

bump?

I already found something better than the kinzu accel. What makes the kinzu accel great is the dpi boost after hitting a certain mouse speed.

o.o?

http://www.esreality.com/post/2560986/use-dif...se-speeds/

fatal1ty was using cl_mouseaccelpower 1 sensitivity 4.7 cl_mouseaccel 2.5 cl_mouseacceloffset 5. But I think he recently got one of those zowie mice and has changed it to 3.7 or so because of the 450dpi instead of 400dpi like the microsoft mice.

kinzu v1 400 dpi = 550. accel in the quake : cl_mouseAccelPower 1.7; cl_mouseAccel 0.002 or 0.004 approximate

yea, that's true with the DPI, and also shines a new light on the assumption that strenx always played with a for quake rediculous low sens of 50cm/360°, which in reality is just 40cm/360° + hardwareaccel.

uses 800cpi though.

idd 1 sens at 800 dpi=51.9cm/360
2 sens at 400 dpi=51.9cm/3600

it's hard to measure the cm/360°, because the accel kicks in at very low speeds already.
with a "normal" speed i reach 360° indeed in ~40cm sens1@800dpi, but if i move really slow, it's more like ~70cm with the same settings. :S

this sensor is so lol...

strenx uses senscap 1 so the accel is irrelevant.

hardware accel, how the mousesensor itself produces accel.

I cannot understand how can someone get used to it since it doesnt feel natural or consistent, maybe its only me I dont know

People got used to the weird WEIRD mouse input in unreal.

Also the accel should be consistant, but as far as naturalness is concerned it's really up in the air.

oddly enough that sounds like my experience with the first g100, except the accel didn't go that far was a small but noticeable jump.

ok guys time to try this again!
Big questions:
1) does it have senscap?
2) how big is it compared to teh original sensitivity
3) does it scale to the senscap or just jumpson from the basic sensitivity to the other one?
4) if it scales, how fast does it do it compared to quake's accel?

Ok i lied in my initial post. I actually never had tried the kinzu, i just wanted to know the answer to my question. I did try the kinzu v1 for real the other week and it felt amazing. It didn't feel as good for lg as these settings - http://www.esreality.com/post/2560986/use-dif...se-speeds/ but i'm talking very tiny percentages here to the point where the effects are negligible. What i find amazing about the kinzu is that compared to the settings i use, it uses some sort of logarithmic curve for the accel which gives it a more powerful acceleration which is awesome because i can aim close range better or lower the sensitivity and have an even better long range tracking than my old settings without affecting my rl aim.

bump

I did some rigorous testing and found a setting that feels very similar to the kinzu!

These are my settings @ 400dpi copying evil's settings -
sensitivity 6.4
cl_mousesenscap 6.9
cl_mouseaccel .048
cl_mouseacceloffset 8
cl_mouseaccelpower 2.5

Evil uses 800dpi which is really 1100 dpi when i measured it in mousetester.

Right now these settings feel exactly like the kinzu except when i move my mouse very fast close range it feels like there is still some accel whereas the kinzu doesn't feel like it has any. This is because the kinzu has a logarithmic deceleration at the end. Perhaps this could be achieved through the registry like this - http://www.esreality.com/post/2321616/natural-logarithm/ but beyond this is just too much for me.

sens 6.4 @ 400dpi = 16.2cm/360°

are you sure evil is playing with such a high sens ?

Well i just based this sens by doing lots of 630s at first while trying to keep the kinzu accel feeling and then i recalculated evil's sens (4.8) to 1100dpi and it was off by like 0.1 (which i kept cos the tracking felt good) so pretty accurate i think. There is a chance that the sens might be a bit lower and the kinzu accel is actually stronger than what i got now which might seem absurd since it's already very high but remember the kinzu accel is very efficient and is only activated when it is needed. This is how the kinzu accel works -

Kinzu hardware accel is not activated until the mouse reaches a certain speed
Logarithmic acceleration allows for low accel at medium speeds
Logarithmic acceleration allows for high accel at high speeds
Logarithmic deceleration allows for low accel at very high speeds and then no accel beyond that

You literally cannot get more efficient than that when using accel. Unfortunately ql doesn't let you use both logarithmic acceleration at the start and and logarithmic deceleration at the end at the same time.

Also i played many hours of aerowalk and powerstation where those maps force weird vertical and horizontal angles a lot so it wasn't just based on my 630s. I'm sure some settings could be fine tuned to match kinzu's settings closer but that requires getting used to each mouse 100% which would take months which i may do in the future.

Also if you used a wmo before the sens is more like 5.9 because of it's forward sensor position.

Also i don't know if the sens might be lower but there is a good chance the accel, senscap and the offset are slightly wrong. This is because my 720s weren't consistent with the kinzu and i would do 630s sometimes whereas my kinzu copycat settings were always consistent 720s but i changed it so it would do 630s so my kinzu copycat settings tracking wouldn't be screwed by the lack of logarithmic deceleration. This is most likely because of accel

Ok i just did some long range testing on powerstation and the feeling is wildly off. It feels like the accel is kicking in and the sens is higher so your probably right. It's hard to confine this problem without being able to use both logarithmic accel and deceleration. So basically my settings feel close to the kinzu but with worse very close range/very long range aim which means i have a lot more work to do.

Ok i did some long range aim tests again with no accel but the same sens this time and the sens seemed fine but the accel was definitely wrong. I could notice jumps in my tracking here and there. Here is the closest settings i have for now but it won't feel anything like the kinzu because it lacks a logarithmic accel and a malfunction speed at the end of the curve. My other settings felt more similar to the kinzu but were technically incorrect. Here are my current closest settings.

sensitivity 6.4
cl_mousesenscap 6.9
cl_mouseacceloffset 8
cl_mouseaccelpower 2.25
cl_mouseaccel 0.3

I wanted to cross-test this with a -1 sens and senscap to see if my accel settings were close but as you might expect without the logarithmic accel at the end, the more you lower ur sens, the more the differences in accel become drastic. At least with these settings, the tracking at long ranges feel much like the original kinzu.

Also i made accelpower 2.5 instead of 3 because true logarithmic acceleration is too aggressive and too hard to control.

cl_mouseaccelpower set to 2.5 (or 3) wouldn't be a logarithmic curve, a logarithmic curve is actually closer to 1.5-1.6, if 2 is a linear curve then anything above 2 must curve inward like a parabola, and anything below 2 besides 0 (x^0 = x^1) must curve outward like a logarithmic curve

Well technically your correct, i just called it logarithmic acceleration and deceleration (opposite curve) for simple terms but you're right, logarithmic deceleration isn't even close to an exponential curve.

i wanted the accel to curve gradually up using an opposite logarithmic curve instead of the "jolt" of acceleration a logarithmic curve gives and then have it switch to a logarithmic curve so the faster i move my mouse the higher the acceleration goes and then i wanted it to switch to a opposite logarithmic curve again so that the curve would transition to no accel more smoothly.

So an accel curve like a wave that basically goes outward than inward than outward again.

Looking at the curve again maybe you wouldn't even need the outward curve part at the end since very rarely will those speeds be reached and it will only just mess with the inward part of the curve.

Ok so 1/3 of the accel at the start is a opposite of a logarithmic curve then 2/3 of the accel at the end is a logarithmic curve that keeps on curving until it reaches it's malfunction speed. I think if somebody makes something very similar using the windows registry they should be able to get close to the kinzu accel. Except the malfunction speed at the end would be unnecessary.

EDIT: On second thought even at medium speeds accel seems to activate very easily with a high offset.so the malfunction speed is probably necessary.

Replicating this in C++ is possible, you can fork InterAccel from Povohat and then have it change from using an exponential curve to a logarithmic curve after you've hit a certain amount of reports. I'd look into it more if I wasn't using a Kinzu v1 as it is already, since I'm not interested in setting up another mouse to try to copy the accel curve.

I did a little bit of research and someone on OCN identified the accel curve as looking like 1*(exp(2 * log(mx^2)) and it looks relatively similar to the graphs I found in my google spreadsheet located here

Can you link to the ocn thread? I want to know what those numbers look like in a graph form.

EDIT: found the graph, I would still like a link to the ocn thread so i can understand what those numbers mean though.

http://www.overclock.net/t/1401294/the-unspec...t_25659178

Here is where we were talking about it, it only went on for like 3 posts.

I think some people here are too caught up on trying to figure out HOW the kinzu accel works instead of WHY it works. People got to remember the kinzu is really just a shitty sensor that somehow hit the lottery with it's hardware accel curve and if we can get something similar to that curve it will be good enough with room for fine-tuning and tweaking unlike the kinzu and probably a lot better than the kinzu accel curve with it's inconsistencies.

no it did not hit the lottery ROFL

some good players got used to its tedious fail and kept using it (they would be better with a serious mouse tho). end of story.

btw I think Evil just switched mice finally, judging from his sub par mouse movement in the last 125fps cup. FINALLY. Now, we will see some serious dominaton

Apparently the malfunction speed for the kinzu is 1.7/ms so if we combine the graph i showed above from pvh with the malfunction speed as a reference we should be able to get a pretty close estimate for the accelpower, accel, offset etc.

About 1.7m/s sounds correct, keep in mind that anything after around 60 counts (for the Kinzu) will not be accepted by the sensor anymore as that's the speed in which it malfunctions. I'm going to be doing some curve fitting with it tonight to try to find an exact formula.

Awesome, can't wait to see the results. I don't know how your going to get a curve like that without using the windows accel so here is a nice guide i found - http://translate.google.com/translate?js=y&am...&tl=en . It teaches you how to convert hex to dex and vice-versa and also how you can easily view the accel curves in windows with a graph chart using excel.

Also these might come in handy too -
http://www.esreality.com/index.php?a=post&id=1945096
http://www.esreality.com/post/2363191/custom-...r-windows/

I did some curve fitting already since it was actually much easier to find a program than I expected, here are the general results. The graphs were way too noisy to actually use due to the sensor's tracking code being broken, so I had to interpolate all data before pushing it through the curve fitter.

https://b.catgirlsare.sexy/MgSP.png

Gaussian seems to fit the curve best but I'm not sure how to implement it into code yet.

General model Gauss1:
f(x) = a1*exp(-((x-b1)/c1)^2)
Coefficients (with 95% confidence bounds):
a1 = 3.093 (2.905, 3.281)
b1 = 10.33 (9.569, 11.1)
c1 = 6.358 (5.525, 7.191)

https://b.catgirlsare.sexy/Cbeg.png

Exponential isn't really possible with an acceleration curve like this, the Kinzu curve is too slow at the start and lifts too fast to be exponential.

General model Exp1:
f(x) = a*exp(b*x)
Coefficients (with 95% confidence bounds):
a = 0.7139 (0.4814, 0.9464)
b = 0.1376 (0.1013, 0.1738)

https://b.catgirlsare.sexy/tTbG.png

Polynomial could work, but once again I'm not entirely sure how to implement it.

Linear model Poly3:
f(x) = p1*x^3 + p2*x^2 + p3*x + p4
Coefficients (with 95% confidence bounds):
p1 = -0.003592 (-0.007256, 7.122e-05)
p2 = 0.04966 (-0.02408, 0.1234)
p3 = 0.1716 (-0.2658, 0.6091)
p4 = -0.0499 (-0.7812, 0.6814)

Those are pretty much the only graphs I could get that didn't look weird or too off that it'd mess with muscle memory for someone coming from a Kinzu.

You do not need to code it, it would be easier to edit the microsoft pointer curve to the kinzu curve (search for "cheese mousefix" to find out how the curve works).

As easy as it should be, I would never do something like this, kinzu is a sick abomination of pure FAILURE

It's too late, I already implemented it into Povohat's acceleration driver, wasn't too complicated to be fair, just had to think of how I was going to do it.

Could you please upload the povohat driver with the code you implemented please? I want to try it out. Also i may try out what lorfa was talking about using two mices and we can probably get even closer altrhough i will need your help with coding since i have no clue about these maths stuff.

https://b.catgirlsare.sexy/uK1D.zip

This is it, in order for this to work you would've had to install the pvh accel driver (Interception version) in the past, otherwise you'll have to do that to have everything setup to work, the only options that actually do anything are "SensitivityCap", "Division1", "Division2", and "Offset", if you want to change the curve then play around with Division1 and Division2, I could get it pretty close but it didn't feel quite perfect.

How do divisions work? And would be nice if there was a graph. Also what dpi are those settings for?

Division1 and Division2 affect the bold numbers in this equation "0.0158615 (x^2)^(0.12686 (-1.033+log(x^2))^2)", just use Wolfram Alpha to understand the graph when you make changes, that's what I've been doing. 400 CPI on the Kinzu, which is actually about 515-520, I was testing with my G100s set to 500 CPI.

Ok i played around with it and from my understanding the problem with your settings is that all your accel curve does is transition from a exponential curve (or w/e you call it) to a logarithmic curve. I think both curves need to have different accelpower values and a different transition point like 30% exponential and 70% logarithmic when the accel starts for example. I couldn't seem to achieve this effect using divisions. I can't see this technique being close to the kinzu tracking without these two factors.

You can configure the acceleration amount how you like using the two division options, the curve should be pretty close to the Kinzu because I just took the Gaussian curve from the curve fitter and placed the equation into the code, but it might not have been perfect when I tried to transition it into proper movement.

Yes but transitioning between two different acceleration amount causes too much inconsistency in tracking compared to transitioning between two different curves imo. This is the way i see the kinzu work.

slow speed - no accel
med speed - exponential accel but controllable thanks to logarithmic curve that comes very soon after it
high speed - logarithmic accel gives impression of no accel because accel is being reduced the faster you move the mouse i.e faster mouse speeds, less reason for accel

And the malfunction speed just stops the logarithmic curve from being interfered with so the log accel curves all the way.

So the log accel is helping us reduce accel in all med and high speed moments whereas the divisions for e.g. the last division is just simply there at the very end to transition from a linear accel to a malfunction speed more smoothly i.e. the divisions have no real effect on a large majority of the accel.

Also in the past i was trying to find a perfect setup that would balance my lg and rl. I could rl well at sens 3.5 and accel .1 but lg was crap and i could lg well at sens 3.5 and accel 0 but rl was crap. I found a setup that made my sens go from 3 to 3.5 if i moved my mouse fast enough. I found it strange because at sens 3.5 and accel 0 i couldn't rocket for shit but with this setup even tho my max sens was the same i could rocket very well. This taught me what's important for rockets isn't just how high ur sens is but how high ur accel is. And my settings taught me if the accel curve was very aggressive (like a sens change) i didn't need the much accel applied over the whole sens, only 0.5 (3 to 3.5) of the sens. And the less accel applied over the sens the better my lg was.

So a very aggressive curve is useful because it allows you to reduce how much accel you need applied to the whole sens which is why the kinzu coincidentally has a exponential curve at the start but like i said before if the curve is aggressive then less accel is needed over the whole sens and so this is why only 1/3 of the accel curve needs to be a exponential curve.

So according to my minimum accel applied over whole sens theory i don't really need the log accel, only the exponential accel and in theory i should just have only that for best lg but without it the transition from accel to no accel is too dramatic and affects the lg.

I thought about what you said, and from this I determined that I failed to correctly implement the accel in the version I sent you, so it has been removed and replaced by 8(!!!) new types, each one is different and uses entirely different data points from the Kinzu graphs I have, the new variable to control these types is called "AccelType" and it goes from 1-8, Division2 was deprecated and removed, Division1 configures how fast the acceleration kicks in still.

This means that "AccelType", "Division1", "Offset", and "SensitivityCap" are the only values currently functioning.

https://b.catgirlsare.sexy/uGzk.zip

I'm not sure if we're on the same page about the division issue. From my very basic most liikely incorrect understanding of divisions it just determines how much accel is applied in the transitioning period to the linear accel curve. so it isn't affecting the curve of the whole accel like accelpower does. No matter how much i tried to alter the divisions to change the linearity of the curve in wolframalpha (actually i used google to see a larger graph) i could only change the distance between the linear accel and the division points, i couldn't actually change the linear accel to become logarithmic or exponential. Maybe it is still possible to do this using divisions but this seems like it's making things too dificult for ourselves imo.

I'm dividing the ENTIRE equation by the division amount that you set, this means the entire equation is moved up or down by the amount of division you do, the equation stays exactly the same it's just that things kick in earlier or later depending on what you have division set to.

Also i tried all the acceltypes. 5 was too laggy (try moving left and right and you'll notice huge lags in windows). None of them felt quite right to be honest. I can't see any of these settings getting close unless we find a way to have two separate accelpower values and the ability to set the destination point for the 2nd curve.

That is possible, it's relatively straight forward to do even.

Awesome! I think we will manage to get very close if you manage to get it implemented and I'll give it some solid hours of testing.

In simple terms this method is still transitioning from two different accel values and not accelpower am I correct? I just don't think this method will ever closely replicate the kinzu accel.

Is there another way to contact you? It'd be nice if we could communicate faster, I have my PMs open.

You mean like esr pm's? or instant messaging? I could do either but if it's esr pm's ur talking about it's better we talk here because i pretty much edit all my comments to fix it or simplify things. Anyway i'm going to bed now so i'll be back on tommorow.

I meant Steam preferably, since it's easier to have direct communication then, which means I can get things done faster rather than waiting for a reply for a while.

too late indeed ;]

Too late for me, I'm actually using the Kinzu, I should've just saved my money and bought a better mouse. :~)

I did some personal testing using the equations spit out by the curve fitter and got this equation, it looks and feels pretty similar but it's definitely not perfect.

0.0137467 (x^2)^(0.123688 (-1.033+log(x^2))^2)

What program can i use to see the accel curve of windows accel in graph form?

cg_madness "1"

you guys are mad...

and especially mad for thinking his sens was the equivalent of 6.4 @400dpi

You know there are clips on youtube of him playing at LAN, and you can clearly see his technique for strafing and aiming. Base sensitivity looks to be 35cm region, with accel needing a strong flick to kick in hard. Also it's important you test at fov92, or any feel you are trying to replicate will be incorrect.

https://youtu.be/ytF7mBx-H-w


edit: go try @400dpi sens 2.9 accel 0.1, it's probably not far off. But you will never replicate the accel of a broken mouse. Strenx once said he tried another kinzu v1 and it felt wrong.

Just "trying" things because they feel "similar" is an inherently flawed methodology of testing, I've gotten to this point using actual data from two separate mice, a lot of curve fitting, interpolation of data points, and various other mathematics, the Kinzu's acceleration curve feeling different can be a number of other things, I prefer to do things in my somewhat objective way rather than take someone's opinion on it, regardless of their level of play, so if someone wants to buy me a second Kinzu v1 then I'd be happy to actually figure out if the curve differs from mouse to mouse.

Just wanted to ask since it's pretty relevant, are you doing these tests according to firmware 1.0.7 or 1.0.10? Because both firmwares have different levels of acceleration and angle snapping (significantly higher on the latter). Evil uses (or was using) firmware 1.0.10 when I tried his set up on lan (I was sitting next to him at dhw 2013). Thought It should at least be mentioned.

Well this is new information to me. I always read online that 1.0.10 and 1.0.7 had the same amount of accel, just 1.0.10 has way more prediction. I've being doing my tests on 1.0.10 but i don't know about aiya.

1.0.7

Could you give me a source on the accel being different. This is the first time I hear about this.

Sorry i don't have any source, i'm just relying on my experience with my kinzu. Unfortunately I longer have it either as it was lost when my mom moved...

It could have something to do with this - http://www.esreality.com/post/1980502/nvc-so-...pid1980988

UPDATE:
Hello guys. Me and Aiya have being working on replicating the kinzu accel curve and we have made some decent progress. He has being doing a lot of modifying on povohat’s driver to replicate it. We have gotten the general feeling of the kinzu down pretty good except it has two issues. 1. Accel doesn’t slow down at high speeds 2. Accel doesn’t allow us to do lots of 360s like the kinzu. You can try his program with his settings (500dpi) here - http://www.mediafire.com/file/3cb7c9p399xyn19/alpha_program.zip . Also remember the kinzu has its sensor a bit behind the middle so if you're using a forwarded sensor like the wmo things may feel a bit faster.

These are the new settings he has added to povohat’s driver in his alpha testing program.

AccelType - Change accel curve to Gaussian or Fourier (all other values besides 11 will disable the equations setting)
•0-8 are gaussian curves
•9-10 are fourier curves
•11 is a gaussian curve
Division1 – Basically alters the accel value although it must follow the curve points (equations) which are basically like points in the windows accel (See here - https://www.microsoft.com/whdc/images/device/pointer3.gif *You cannot alter these curve points i.e. equations to start earlier or later, these are fixed, we can only alter the speed). So it’s like enlarging or reducing the size of the curve while the curve points (equations) change in speed but stay at the same spot for the same mouse speed which means some parts of the curve will be extended or cut (if you have a senscap) depending on the value.
For the moment, we don’t have a formula to compare the division, equationC1 and C2 value to cl_mouseaccel. Also unlike cl_mouseaccel, divisions work the opposite where the higher the value the lower the accel.
EquationA1 - (start of curve 1)
EquationB1 - (end of curve 1)
EquationC1 - (accel value of curve 1)
EquationA2 - (start of curve 2)
EquationB2 - (end of curve 2)
EquationC2 - (accel value of curve 2)
Remember 1 is the default value and the default value will follow the curve set by acceltype. So setting EquationA1 to 1 and EquationA2 to -1 does not mean you have a decelerating accel curve if your acceltype is not set to linear.

For any questions about the program or the mathematics involved please message Aiya since I have no clue about this stuff.

To Dos
Aiya is working on adding a feature to alter the accelpower values of each curve. We are doing this because right now we can only use curve points (equations) to alter the curve which is unwanted as it can cause the curve to be unpredictable if it’s not following a specific formula.

WHAT WE NEED HELP WITH!
At the moment we have no clue how we can alter the 2nd curve to start earlier or later. We need someone with the mathematic knowledge to help Aiya code this into his program.

I actually have an idea on how to set the 2nd/3rd point using the rate variable, I'll look into it.

Update #2

I have managed to replicate the kinzu feeling to the point where my aim feels the same switching back and forth between the kinzu and this program - https://www.mediafire.com/?28jhttp6odcic3y

ISSUES TO BE FIXED -
1. The switch from exponential accel to logarithmic accel is not smooth like the kinzu
2. In long range lg fights (small mouse movements) it feels like it still has accel unlike the kinzu

But i think the reason my lg acc still stays the same like the kiznu is because -

1. The curve is more consistent so lg feels more accurate at times
2. The sensitivity feels more precise for long range fights despite accel feeling

I also have a suspicion that this program is causing mouse movements to drop frames which may be causing both the issues. I will try and get Aiya to look more into it. As for now we are still looking for a methetician to help us with the equations for the program.

I forgot to mention Aiya updated the program so that the curves now use accelpower instead of plots. This way the curve is always smooth.

These are my settings i use now -
AccelerationLinear = 0.00000000000000000000000000000000001
AccelerationParabolic = 0.015
AccelerationLog = 0.15

The curves can't be changed from what they are named (logarithmic will stay logarithmic) but they can be altered smoothly now unlike before where this was only possible if you used very specific values in the equation.

hard to believe a grown ass adult (like all of us here) still cares about the most futile of things

just get a kinzu, or some zowie mouse

pretty ironic if you ask me, you claim that all of us are grown adults and we shouldn't care about something like this, but then go on to care about what another grown adult does in their spare time.

Update?

Me and another guy tried to make a program that replicates the kinzu accel but nothing felt quite as good. Your best bet is to just buy another kinzu off ebay.

Yes Covid-19 kills many people.

This thread is insane. Why replicate something so broken...

I don't doubt good players can adjust to Kinzu and aim well, but it has positive accel, negative accel, low malfunction speed. The translation curve must look bonkers...so why would you want to replicate that.

Just get a good mouse and tinker with windows accel or ingame accel a bit. Or go the best way and fuck accel, learn without it, after adjustment your hitscan aim will go through the roof.

"This thread is insane. Why replicate something so broken..."

My thoughts exactly xD

But hey if it works for some lol

Because the kinzu accel was the shit for ql. It was awesome for lg and rockets. That's why evil used it. But none of the pros seem to be using it anymore except maybe nitrino?

My guess is because either the kinzu max tracking speed is bad for a faster game like qc or people just found something better once the 3366 sensors came out. Or maybe it's just because the mouse is discontinued.

But if someone did manage to replicate the kinzu accel curve perfectly and remove all it's inconsistencies it should in theory feel even better than the kinzu accel.

I saw Strenx is using a SteelSeries Kinzu again. And is doing insane aim with it.

Sales in Kinzu will make a comeback again