Last I looked, Diabotical sens was measure in arc minutes per mouse count.

So

dbt sens = QL sens * QL m_yaw * 60

Diabotical "linear" type of accel is the one I use. It corresponds to cl_mouseAccelPower = 2 (default).

In that case, the "ramp" value is the one that corresponds to cl_mouseAccel in QL.

cl_mouseAccel changes meaning depending on m_cpi. I'll just assume m_cpi is 0, as is usually the case.

dbt ramp = cl_mouseAccel / QL sens


FOV in Diabotical should just be vertical FOV by default.
QL uses a horizontal FOV based on a screen with 4:3 aspect ratio.

vertical FOV = 2 * atan( 0.75 * tan( QL FOV / 2 ) )

Hope that's all right. Don't sue me if I made a mistake. :D

What cvar is cl_mouseaccel in Diabotical?

I don't know whether there is a way to access it in the console. I'm guessing there is, but I just use the UI at the moment. It's quite comprehensive. Set your accel type to "linear" and change the value of "ramp".

I think there is also a cap to the accel by default. Default in QL is no cap, so you probably need to disable the cap in Diabotical if you want it to be the same.

So basically, I just have to enter Quake/Source on the sens converter and set my actual Quake Live values for the sens on the sens box, then on ramp I use the same accel value from QL and leave the other stuff as default?

How do I hide the weapon model?

Yes, but dbt's ramp is not the same value as QL's accel.

As I understand it:

dbt ramp = cl_mouseAccel / QL sens

I wrote that in my first comment.

I don't think you can hide the weapon model. I could be wrong.

As I understand it:

Can someone confirm this?

I base it on the graph shown on the accel settings screen, and it feels right to me. Unfortunately, I have not heard it from a dev though.

https://www.reddit.com/r/Diabotical/comments/...;context=3

I found this. Seems more complex.What the hell CPI im using on a WMO? was it 800?

I just double checked and my settings for cl_mouseaccel... are:

cl_mouseAccelPower: "2"
cl_mouseAccelOffset: "0"
cl_mouseSensCap: "0"
cl_mouseAccel: "0.25"

m_cpi "0"
m_filter "0"

my m_yaw and m_pitch values aren't default, it's a bit lower, not sure why I changed this, back in the day it must have felt better lowering it a bit, it's "0.217" and default is "0.022" so not sure if this would make the default Quake/Source converter innacurate and I have to change soemthing.

Why not just add an accel converter from Q3 too? geez

This post is sourced from this original post

https://www.reddit.com/r/Diabotical/comments/...n/fj8sj21/

The guy making the post says he is "not 100% sure" either.

About threshold:

[Diabotical Cap] = (100/( [Quake sensitivity] / [Quake cl_mouseSensCap] ))/100

This is weird to me because it is just equivalent to

[Quake cl_mouseSensCap] / [Quake sensitivity]

which I believe is correct, but the formula given in that post is unnecessarily complicated, and that's not making me confident.

I also don't see how that ramp formula would produce the correct accel plot shown in Diabotical's settings. Maybe the game changed at some point. I don't think you need to know your mouse CPI for this.

That plot has CPMS on one axis and +100% sens on the other.
The ramp seems to set the gradient of the ramp part in the plot.

That would make

ramp = 100% / [the CPMS needed to double the sensitivity]

In Q3 and QL (ignoring fancy shit like powers and offsets, which you're not using anyway):

the accelerated sensitivity = the base sensitivity + [cl_mouseAccel * mouse CPMS]

so the CPMS needed to double the sensitivity is

[base sensitivity] / cl_mouseAccel

which makes the ramp =

100% / [the CPMS needed to double the sensitivity]
= 1 / ([base sensitivity] / cl_mouseAccel)
= cl_mouseAccel / [base sensitivity]
= cl_mouseAccel / QL sens

which is the formula I gave you.

Again, I could be messing something up here, but that's what currently makes sense to me, and it doesn't feel wrong in game either (not that that is necessarily the best way to tell).

If you wanna try my way, we need your QL sensitivity value.

If you wanna use the formulas in your link, then:

Last I checked, WMO has a CPI of 400 (Wanna double check?).

[Diabotical Ramp] = [Quake cl_mouseAccel] x [Actual mouse CPI] / 2000

= 0.25 x 400 / 2000 = 0.05

You're not using a sens cap, so dbt's cap should be zero (I think that disables it) or set it very high like 99.

You're not using an offset, so dbt's threshold can just be zero too.

As for the yaw and pitch, just take the default yaw or pitch in dbt and multiply it by (your yaw or pitch value / 0.022).

Hey! I'm that guy from the reddit post.

Still haven't seen a conversion formula from the devs or the game's actual accel calculation. I may be the one misinterpreting something, but here's where I think we differ.

1. Actual terminology dbt uses is +100% / cpms

This basically means that your formula should use 200% or (2 x sensitivity) / cpms.
Sticking with QL calculations for a second...to find the correct dbt ramp value accoding to diabotical's definition, you need to first determine the number of counts per millisecond needed to double your sensitivity, then divide double your sensitivity by that number of counts. So if my QL settings are sensitivity = 3.6 and cl_mouseaccel = 0.4, then the cpms needed to double my sensitivity would simply be 3.6 / 0.4 = 9 cpms. Then, the expected dbt ramp should be (2 x 3.6) / 9 = 7.2 / 9 = 0.8. There's some scaling factor missing though because actual ramp value is 0.08.

2. You don't actually need the sensitivity value to convert accel values between QL and dbt.

As you can probably tell from the QL example formulas in point #1, the sensitivity value actually cancels itself out when you combine both together.
Combined formula would be (2 x 3.6) / (3.6 / 0.4) = 2 x 0.4 = 0.8

3. CPI / DPI absolutely matters when converting acceleration values, but they scale differently in QL vs. dbt.

Your DPI is essentially used TWICE when determining your "real" QL sensitivity. First, the game reads your cpms in order to scale the raw sensitivity value according to cl_mouseaccel. But once the game calculates your new sensitivity value, your "real" sensitivity in cm/360 or deg/mm (which reflects actual crosshair movement) would still have to take DPI into account. This means that while you can scale QL sensitivity 1:1 with DPI, cl_mouseaccel needs to be scaled by the square of your DPI change. For example, 3.6 sensitivity and 0.4 cl_mouseaccel @ 400 DPI is equivalent to 0.9 sensitivity and 0.025 (not 0.1) cl_mouseaccel @ 1600 DPI. DPI scale is 4x, so I simply divide sensitivity by 4, but cl_mouseaccel is scaled by 4^2.
In dbt, ramp can simply be scaled by the same factor as sensitivity. So 3.6 sensitivity and 0.08 ramp @ 400 DPI is the same as 0.9 sensitivity and 0.02 ramp @ 1600 DPI.

4. Yaw/pitch calculated after acceleration in QL

In QL, yaw/pitch affects your sensitivity only after the acceleration calculation. This means that when changing DPIs, you can either adjust the sensitivity and cl_mouseaccel values as described above or simply scale your yaw/pith values by your DPI factor instead.

In dbt, it seems like yaw/pitch is already taken into account before acceleration. Still haven't received confirmation on this, but my expectation is that non-default yaw/pitch values should be used to adjust BOTH dbt sensitivity (or yaw/pitch) AND dbt ramp:

Example QL settings:
- sensitivity = 3.6
- yaw/pitch = 0.018
- cl_mouseaccel = 0.4

Initial converted dbt settings (before adjusting for non-default yaw/pitch):
- sensitivity = 3.6
- yaw/pitch = 1.32
- ramp = 0.08

yaw/pitch conversion factor = 0.018 / 0.022

Final converted dbt settings (after adjusting for non-default yaw/pitch):
- sensitivity = 3.6
- yaw/pitch = 1.08
- ramp = 0.065455


Regarding diabotical's ramp plot...I think the game's graph is inaccurate. The povohat/kovaak driver uses bascially the same sort of plot, and that one is also much steeper than the diabotical chart. You can try this formula to recreate diabotical chart though:
%sensitivity = ((sensitivity x yaw/pitch) + (ramp x cpms x 6.6)) / (sensitivity x yaw/pitch)

Thank you for your reply.

you need to first determine the number of counts per millisecond needed to double your sensitivity

I agree with that.

So if my QL settings are sensitivity = 3.6 and cl_mouseaccel = 0.4, then the cpms needed to double my sensitivity would simply be 3.6 / 0.4 = 9 cpms.

Agreed.

Then, the expected dbt ramp should be (2 x 3.6) / 9 = 7.2 / 9 = 0.8.

This is where we differ.
I just have ramp = 1 / 9 = 0.11111.

My reasoning:

If I set my cap to 2 and adjust ramp, I can see where the sensitivity is doubling in the accel plot in dbt's settings.

At CPMS of zero, the plot starts at 1.
That is to say that the sensitivity multiplier is 1---naturally, because there is no acceleration applied yet.
As CPMS increases, the value grows linearly, as expected.
What is of interest is the CPMS value where the plot reaches its cap.
That's the point at which the sensitivity has been doubled.

If I use a ramp of 0.1, that point is reached at 10 (1/ramp).
If I use a ramp of 0.2, that point is reached at 5 (1/ramp).
If I use a ramp of 0.125, that point is reached at 8 (1/ramp).
If I use a ramp of 0.250, that point is reached at 4 (1/ramp).
If I use a ramp of 0.05, that point is reached at 20 (1/ramp).
Etc.

And as for our example, if I use a ramp of 0.11111, that point is reached at 9 (1/ramp) (though it is a bit harder to read precisely on the plot).

So it seems that no matter which value I use for ramp, that point of doubling sensitivity is reached at 1/ramp.

And that makes sense because in the plot, the vertical axis is labelled x100% and the horizontal is labelled CPMS.
If the ramp is just the slope of that part where the linear increase happens, then the slope (ramp) of that part is
1 / (CPMS needed to double sensitivity).

That's the case because the vertical axis change on the slope is 1 (going from 1.0 to 2.0) and the horizontal axis change on the slope is the CPMS needed to double sensitivity.

I'm not sure of any other way to interpret the plot shown there.

If we take your example and change the values slightly to something that is easier to read on the plot:
QL sensitivity = 3.6
QL cl_mouseaccel = 0.36

We agree the CPMS needed to double sensitivity is 3.6 / 0.36 = 10.
Well, it seems like that can be easily achieved with a ramp of 0.1 (1/10).

Regarding diabotical's ramp plot...I think the game's graph is inaccurate.

If that's the case, then we don't have a lot to go by other than how it feels in the game.
I haven't seen any reason to doubt the plot. It seems to be something the dbt devs are quite meticulous about.

We still have the units given for the ramp variable (+100%/cpms).
100% = 100/100 = 1, so I read this as +1/cpms,
where I interpret the "cpms" to be "the cpms needed to add 1 to the sensitivity multiplier", which is the same as "the cpms needed to double the base sensitivity".
That's consistent with my observations about the plot.

At least for my own settings, when I do the conversion this way, it feels about right, but y'know, maybe I'm just not that sensitive to it.

Thanks for you input; you could still be the one who is right, but I just thought I'd share my reasoning.


Quickly, on your point number 3:

This means that while you can scale QL sensitivity 1:1 with DPI, cl_mouseaccel needs to be scaled by the square of your DPI change.

Yeah, that's true, but I would just convert QL to use the same DPI as dbt first, and then convert sens and accel from QL to dbt.


EDIT:

I felt I should add that it makes logical sense that

dbt ramp ("dbt accel") = QL accel / QL sens

This makes acceleration in dbt "normalized" with respect to sensitivity.
It's basically the same as QL acceleration except that in QL, if you halve your sens, you have to halve accel as well (assuming you want to keep everything scaled).
If you don't halve accel that way, then the strength of accel relative to sens would increase.
In dbt, you can halve sens and leave accel unchanged---its pull on sens will automatically be halved given the way that dbt ramp works.
The strength of the accel is proportional to the sens in dbt.

I think this is intended to be an improvement over the way it is done in QL, to allow settings to be changed more independently

Yes, I think your method makes sense and seems to be corroborated by yakumo, who is usually pretty well in the know. He's been linking to http://mouseaccel.blogspot.com/2015/12/copyin...tween.html which matches your formula.

When I first posted my findings months ago, there really wasn't any documentation I could find and also had to test partially by feel which is unreliable. I think I may have also been using 83 FOV instead of 83.whatever that actually matches the 100 FOV I used in QL, so maybe that's why 0.1 felt too fast for me.

Anyway, I'm going to edit my reddit post to hopefully prevent further confusion. :)

No worries. It's always good to get confirmation from others; it helps me to know I'm not just imagining things. : )

dbt ramp ("dbt accel") = QL accel / QL sens

* dbt yaw/1.32 right?

And what about mouseacceloffset? Same ql value?

I went through the calculations, and I don't currently believe that multiplication (* dbt yaw/1.32) is necessary so long as sens is converted correctly.

If you use a yaw of 1, then it's just

<dbt sens> = <QL m_yaw> * <QL sens> * 60

If you're using the built-in converter, yaw will get set to 1.32, and everything will be right, but if you change yaw, you need

<dbt sens> = <QL m_yaw> * <QL sens> * 60 / <dbt yaw>


Dbt's threshold value should just be the same as QL's cl_MouseAccelOffset so long as m_cpi is 0.

In that case, they are both measured in CPMS.

I guess my sens is correct, same value as ql, just the .018 ql yaw converted to 1.08 in dbt.
Dunno if a non-default yaw in dbt influences the ramp setting too or the accel/sens formula is enough

As far as I know, the formula is not public, so we have to make assumptions and see whether it feels right.

That said, I don't see any benefit in making the "yaw multiplier" anything other than what it has always been: a multiplier that is applied at the end of all other calculations (like m_yaw).

If that's what it is, then if one day you just doubled it, effective sens and accel would both double too. But in order to keep your cm / rev unchanged, you would have to halve the dbt sens value, which would also cause the effective dbt accel to be halved automatically (no need to halve ramp as well).

I reckon everything should be fine so long as your base sens is right (dbt sens + dbt yaw combination is producing the correct cm / rev), the accel is linearly increasing, and the accel is doubling at the right CPMS.

After that, it is straightforward to apply threshold (offset) and cap.

Yakumo in reddit says (if I understood correctly) to basically:

1) put same sens as in QL in DBT but use Quake/Source converter
2) Put accel enabled in linear mode and leave all in default state
3) Use the blogspot link and convert your accel and use the "drive" column accel value for your ramp

That's it, unless im missing something.

Edit: I just tried it like that, it sucks, accel kicks only when you make a movement that is too fast compared to my QL feel.

What Yakumo said looks correct to me.

The equivalent of step 3 should just be the formula I gave earlier:

dbt ramp = QL accel / QL sens

If it is not kicking in early enough, make sure you haven't got a threshold set.

Otherwise, I expect it is always going to feel a little different even if the values are mathematically correct. Lag and accel are often perceived similarly, and it can be a problem if you are very sensitive to small differences. You already were saying that you were having problems with lag.

Q3 (and most likely QL too) has accel that is influenced by frame rate. I don't know how dbt does it, but it probably tries to fix that, which might cause small differences in the feel.

You can also try it with the multi-threaded mouse input disabled.
You can try making very small increments to ramp until it feels more like what you are used to.

Multi threaded did improve it but I still feel a bit of lag.

Im going to try the natural one and adjust by feel.

Assuming you meant "0.0217" instead of "0.217"

Try these values in diabotical...

- sensitivity = [same as QL]
- yaw/pitch = 1.302 (1.32 * 0.0217 / 0.022)
- ramp = 0.0493181818... (0.05 * 0.0217 / 0.022)

Also, I would recommend temporarily disabling multi-threaded input to test whether the feel matches QL. Once you're satisfied that it is close enough, feel free to turn multi-threaded input back on if you'd like.

EDIT: Actually, can you also try making the yaw/pitch adjustments within the "Anisotropy..." part of the mouse acceleration settings? Might feel exactly the same or might feel completely different. Curious which one should actually be used. So, instead of the above settings, try these instead...

SENSITIVITY
- sensitivity = [same as QL]
- yaw/pitch multiplier = 1.32

MOUSE ACCELERATION
- ramp = 0.05
Anisotropy...
- Yaw response = 0.986363636363636 (0.0217 / 0.022)
- Pitch response = 0.986363636363636 (0.0217 / 0.022)

Where did you get 0.05 from?

https://mouseaccel.blogspot.com/2015/12/copyi...tween.html

Using the converter here, I get a different ramp value (Yakumo said to use "drive" value as ramp in DBT)

Can't play this fucking game, it has input lag on the mouse.

You can try turning off the multithreaded mouse input.

If you just hit TAB in the console, all commands will come up. I definitely remember seeing the accel cvar in there.

mouse_accel_cap or accelcap

or something along those lines.

1 is no accel

could be wrong

hello all. With my broken english it's hard for me to understand everything you wrote here. Can please someone help old quaker to set his sense in DB?
seta m_pitch "0.022"
seta m_filter "1"
seta sensitivity "2.9"
seta m_yaw "0.022"
seta m_forward "0.22"
seta m_side "0.22"
seta cl_mouseAccel "0.3"
seta cl_mouseAccelStyle "0"
seta cl_mouseAccelOffset "0"
seta in_mouse "2"
seta cl_mousesenscap "0"
seta cl_mouseAccelPower "2"

My mouse is IE3 (400dpi I guess).

At the moment I use yaw/pitch multipler 1.32 (default) , sens 2.9 (quake/source engine). Accel type LINEAR ,CAP 2, Treshold 0, RAMP 0.10344

Those dbt settings look right to me.

One thing though, you are not using a sens cap in QL, so the cap in dbt can be zero as well, but it might not matter much.

How did u caculate your ramp?