Using software like CheatEngine to 'hack' my sensitivity.

[bread94]

Hi, is there a way to use CheatEngine or similar software to 'hack' my sensitivity so it's correct, setting values that aren't available with a games slider?

I like using 6400 dpi so my only way to use it in every game is if I can 'hack' the game's sensitivity value.

 

Whatever program... I'm desperate to know if this is possible and secondly, how?

I would sell my soul to the devil to repay you if you could figure out a way to do this.

[DPI Wizard]

This is possible for some games, but there's not universal way of doing it so for every game it requires someone to make a working table to use, or for you to find it yourself. For multiplayer games this will in most cases trigger some anti-cheat countermeasure.

The easiest way to fix your issue is probably to use a program like Raw Accel, and you will find the perfect multiplier in the advanced output of the calculator.

[bread94]

26 minutes ago, DPI Wizard said:

This is possible for some games, but there's not universal way of doing it so for every game it requires someone to make a working table to use, or for you to find it yourself. For multiplayer games this will in most cases trigger some anti-cheat countermeasure.

The easiest way to fix your issue is probably to use a program like Raw Accel, and you will find the perfect multiplier in the advanced output of the calculator.

The issue is rawaccel changes my dpi. My dpi i can change without third-party software, it's the actual sens i want to change and then i get to keep my dpi. sounds like a no-go from what ur saying

[DPI Wizard]

Ok, then it will be very difficult I think, unless you actually find a way to modify a sensitivity multiplier or something in addition to the sensitivity using cheat engine etc. With 6400 DPI you will for a lot of games require a sensitivity below their absolute minimum.

[bread94]

21 minutes ago, DPI Wizard said:

Ok, then it will be very difficult I think, unless you actually find a way to modify a sensitivity multiplier or something in addition to the sensitivity using cheat engine etc. With 6400 DPI you will for a lot of games require a sensitivity below their absolute minimum.

 Yup. Is there any workaround (no matter how ludicrous) to modify/hack the sensitivity in The Callisto Protocol? 

[TheNoobPolice]

16 hours ago, bread94 said:

The issue is rawaccel changes my dpi. 

Why would it be required to scale sens and not DPI? If you want a smaller turn increment, just set sens to the lower value of whatever the change is. You could load the rawaccel profile only when playing the game or even script it trivially with something like Autohotkey to load both the game and the profile automatically, this is much safer and would work better than trying to modify game memory using cheat engine.

[bread94]

On 21/09/2023 at 12:21, TheNoobPolice said:

Why would it be required to scale sens and not DPI? If you want a smaller turn increment, just set sens to the lower value of whatever the change is. You could load the rawaccel profile only when playing the game or even script it trivially with something like Autohotkey to load both the game and the profile automatically, this is much safer and would work better than trying to modify game memory using cheat engine.

Thank you, I am aware of that and actually have a program called Custom Curve Pro which I used to use for this reason and also to modify the DPI while RMB is being held (it's honestly really great for that. I t allows you to have a different ADS sens in games that don't support it natively). The reason why I don't want to change my DPI itself is because I get used to one and I prefer one. Changing DPI all the time messes with my muscle memory as some micro adjustments become impossible (if I have to change it lower) and some, it's giving too much data for my liking and it feels a bit jittery.

This is why, for me, changing sens wherever possible is better.

[TheNoobPolice]

4 hours ago, bread94 said:

Changing DPI all the time messes with my muscle memory as some micro adjustments become impossible (if I have to change it lower) and some, it's giving too much data for my liking and it feels a bit jittery.
This is why, for me, changing sens wherever possible is better.

I have contributed some features to Custom Curve since I met the owning author (through this site funnily enough) so very familiar with it, but I think you may be expecting something different to happen that actually would if you could dynamically alter game sens rather than scaling DPI...

Let's say you're at 6400 dpi and the game is set to some sensitivity; for arguments sake we'll imagine source engine at sens 1, so each count from the mouse turns 0.022 degrees.

This means for every 1/6400th of linear inch hand motion, 1 count is sent to the game and the game updates the camera to a new angle offset by 0.022 degrees. If we wanted to turn 10 degrees in game we'd need:

10 / 0.022 = 454.54..
454.54 / 6400 = 0.071 inches of hand movement turns 10 degrees

If you could then somehow dynamically scale the game to sens 0.5, then 1/6400th of an inch offsets the camera by only half that, so 0.011 degrees instead, so we now need..

10 / 0.011 = 909.09..
909.09 / 6400 = 0.142 inches of hand movement turns 10 degrees (exactly double of course)

So what happens if we instead scale the DPI down to 3200? Our sens is still set to 1, so our increment is still 0.022 degrees. We now have:

10 / 0.022 = 454.54..
454.54 / 3200 = 0.142 inches of hand movement turns 10 degrees - exactly the same hand motion produces exactly the same turn.

So I am not sure what kind of muscle memory you think could be affected by changing DPI, that wouldn't occur by changing the sensitivity? The only difference is in the resolution of minimum turn, and as I previously mentioned you could just set the game to the minimum sens (i.e highest turn resolution) you need to feel smooth on slow motions, and then scale the DPI higher for the exact same effect. If you increase the DPI, the amount of data sent is capped anyway by the polling rate (the whole reason polling is part of the USB spec is to limit data bandwidth that would otherwise occur if the CPU was interrupted every time the mouse had data to send) so it would not be possible for this to cause additional jittering unless you are trying to use 8k or something; in which case, just don't

[bread94]

Assuming you adjust your DPI and sens to keep the same cm/360 and for argument's sake, let's say we're comparing 800 DPI and 1600 DPI both set up to come to a 30cm/360.

While moving 30cm will put your cursor in the exact same place, the sens with 1600 DPI will register input sooner as it has more counts per inch and therefore, will register a count sooner than the 800 DPI set up with the same cm/360.

It's this that makes things like recoil control better for me on a higher DPI as it responds sooner and with the extra info the mouse is sending, more granularity of control.

Wow, very interesting to see you contributed to that program, it's good. I like it. It's a lifesaver for old FPS games that don't have a separate sensitivity slider so thank you for your work on that.

[TheNoobPolice]

2 minutes ago, bread94 said:

While moving 30cm will put your cursor in the exact same place, the sens with 1600 DPI will register input sooner as it has more counts per inch and therefore, will register a count sooner than the 800 DPI set up with the same cm/360.

This is correct - but this is also just the increment resolution I mentioned; so you just set the game to the lowest of the sensitivities you want. You could then have the DPI scaling in Custom Curve to start at 2x, and then scale down to 1x on your modifier key / button for the exact same effect as the sens moving between 1 and 0.5 in game with DPI scaling at 1x.

12 minutes ago, bread94 said:

Wow, very interesting to see you contributed to that program, it's good. I like it. It's a lifesaver for old FPS games that don't have a separate sensitivity slider so thank you for your work on that.

Thanks, my main contribution is the Bias mode (technical explanation) that changes vertical sensitivity scaling from a component multiplier to a directional weighting, which should be the standard way to do it in my opinion. A lot more people would benefit from differing vertical sensitivity if it didn't normally change the diagonal direction of their cursor, as it makes things like tuning recoil control much easier, or for in games that have a lot of verticality whilst still requiring aiming accuracy that requires low horizontal sensitivities.

[bread94]

43 minutes ago, TheNoobPolice said:

This is correct - but this is also just the increment resolution I mentioned; so you just set the game to the lowest of the sensitivities you want. You could then have the DPI scaling in Custom Curve to start at 2x, and then scale down to 1x on your modifier key / button for the exact same effect as the sens moving between 1 and 0.5 in game with DPI scaling at 1x.

Thanks, my main contribution is the Bias mode (technical explanation) that changes vertical sensitivity scaling from a component multiplier to a directional weighting, which should be the standard way to do it in my opinion. A lot more people would benefit from differing vertical sensitivity if it didn't normally change the diagonal direction of their cursor, as it makes things like tuning recoil control much easier, or for in games that have a lot of verticality whilst still requiring aiming accuracy that requires low horizontal sensitivities.

if im honest, idk what these numbers are you're explaining to me but it doesn't matter, as I know that program changes DPI on a driver-based level (correct me if im wrong). I'm not looking for something to change DPI, I can do that all day everyday, ezpz. It's strictly only the possibility of changing the in-game sens (via hacks or whatever will work) that im interested in as keeping the same DPI throughout all my games that I want. I do thank you for for all the effort you've put into trying to help me though, I appreciate it.

Oh man... that looks SO interesting. I've been having a few bees tonight tho so I'm gonna check that out tomorrow, it seems promising. Possibly bringing something to the table that'll help me

[bread94]

10 hours ago, TheNoobPolice said:

This is correct - but this is also just the increment resolution I mentioned; so you just set the game to the lowest of the sensitivities you want. You could then have the DPI scaling in Custom Curve to start at 2x, and then scale down to 1x on your modifier key / button for the exact same effect as the sens moving between 1 and 0.5 in game with DPI scaling at 1x.

Thanks, my main contribution is the Bias mode (technical explanation) that changes vertical sensitivity scaling from a component multiplier to a directional weighting, which should be the standard way to do it in my opinion. A lot more people would benefit from differing vertical sensitivity if it didn't normally change the diagonal direction of their cursor, as it makes things like tuning recoil control much easier, or for in games that have a lot of verticality whilst still requiring aiming accuracy that requires low horizontal sensitivities.

Doesn't Custom Curve only affect DPI?

[TheNoobPolice]

3 hours ago, bread94 said:

Doesn't Custom Curve only affect DPI?

Well, yes, but not really.

There’s no Windows API function to change your mouse DPI. Windows itself doesn’t even know what Mouse DPI is. Only your mouse vendor driver can communicate with the device to change its sensor resolution.

What we do with filter drivers like Custom Curve, Raw Accel, ReWASD etc etc, is just perform simple math on the input in kernel space before it reaches the core of OS input processing (we refer to this as “beneath Windows”). For all intents and purposes it would be more useful to imagine those filters to exist along the cable between your mouse and PC, because any application that runs on Windows and gets input in any normal way cannot even know the input is modified. So this is why we refer to it as “scaling DPI” - but your mouse is still always operating at the same DPI internally.

I’ll go over an example one more time, and if it still isn’t helpful I probably can’t think of a better way to explain it:

Let’s say you want to cut the game sens in half dynamically on a keybind and let’s imagine we can do that. The sens you want when the key is not pressed turns 0.2 degrees each input and when the key is held turns 0.1 degrees.

Your mouse is at 400 dpi for arguments sake, so upon moving the mouse, nothing happens until you reach 1/400th of an inch distance on the mouse pad, which then sends an input and turns 0.2 degrees when the key is not held, and 0.1 degrees when it is.

Now, back to reality; we can’t actually modify the sens in game. So instead, we can set the game to the lowest sens of 0.1 degree and we can set a scaling factor of 2x the effective DPI with Custom Curve that we then set the keybind to in order to dynamically cut in half back to 1x when held.

This means that when the key is not held, 1/400th of an inch sends 2x inputs instead of 1 in a single packet, so instead of turning 0.1 degree, the game turns 0.2 degrees. When you press the key, this goes back to normal scaling, so the game turns 0.1 degree for every input, which is exactly the same result as if we could modify the game sens directly, with exactly the same granularity to hand motion - if you could compare the two frame by frame, there would be no difference at all at any point.

Edited September 23, 2023 by TheNoobPolice

[bread94]

11 minutes ago, TheNoobPolice said:

Well, yes, but not really.

There’s no Windows API function to change your mouse DPI. Windows itself doesn’t even know what Mouse DPI is. Only your mouse vendor driver can communicate with the device to change its sensor resolution.

What we do with filter drivers like Custom Curve, Raw Accel, ReWASD etc etc, is just perform simple math on the input in kernel space before it reaches the core of OS input processing (we refer to this as “beneath Windows”). For all intents and purposes it would be more useful to imagine those filters to exist along the cable between your mouse and PC, because any application that runs on Windows and gets input in any normal way cannot even know the input is modified. So this is why we refer to it as “scaling DPI” - but your mouse is still always operating at the same DPI internally.

I’ll go over an example one more time, and if it still isn’t helpful I probably can’t think of a better way to explain it:

Let’s say you want to cut the game sens in half dynamically on a keybind and let’s imagine we can do that. The sens you want when the key is not pressed turns 0.2 degrees each input and when the key is held turns 0.1 degrees.

Your mouse is at 400 dpi for arguments sake, so upon moving the mouse, nothing happens until you reach 1/400th of an inch distance on the mouse pad, which then sends an input and turns 0.2 degrees when the key is not held, and 0.1 degrees when it is.

Now, back to reality; we can’t actually modify the sens in game. So instead, we can set the game to the lowest sens of 0.1 degree and we can set a scaling factor of 2x the effective DPI with Custom Curve that we then set the keybind to in order to dynamically cut in half back to 1x when held.

This means that when the key is not held, 1/400th of an inch sends 2x inputs instead of 1 in a single packet, so instead of turning 0.1 degree, the game turns 0.2 degrees. When you press the key, this goes back to normal scaling, so the game turns 0.1 degree for every input, which is exactly the same result as if we could modify the game sens directly, with exactly the same granularity to hand motion - if you could compare the two frame by frame, there would be no difference at all at any point.

Tbh, it was the first part of that response that cleared it up for me. The whole bit before you said 'I’ll go over an example one more time, and if it still isn’t helpful I probably can’t think of a better way to explain it' which is kinda ironic hahahaha

But no, I get it now and hey... you really had a lot of patience with me there and went through a lot to help out and I want you to know I really appreciate that. This knowledge will deffo help me out a lot and now I've got some possibilities to think about - the ways in which I can use it to my advantage

Just one last quick things. In your examples you've mentioned 'scaling' a lot. Is it only this 'scaling' feature that is working 'beneath windows' or does any utilisation of Custom Curve Pro work 'beneath windows'? Like if I edited the graph or if I used Sensitivity Toggle, for example

[TheNoobPolice]

3 minutes ago, bread94 said:

Tbh, it was the first part of that response that cleared it up for me. The whole bit before you said 'I’ll go over an example one more time, and if it still isn’t helpful I probably can’t think of a better way to explain it' which is kinda ironic hahahaha

Just one last quick things. In your examples you've mentioned 'scaling' a lot. Is it only this 'scaling' feature that is working 'beneath windows' or does any utilisation of Custom Curve Pro work 'beneath windows'? Like if I edited the graph or if I used Sensitivity Toggle, for example

Ha! oh well, nevermind lol

So when I refer to "scaling" it is just a term to describe "does math on". All the functions in Custom Curve operate in a single binary in kernel space beneath Windows and generate a cached table of values  - only the cumulative factor for all functions you select is applied to each input in one go. When you make a sens toggle, for example, nothing is loading dynamically, everything is already pre-loaded - it is essentially different positions of the same vector (this was also a requirement for Faceit anti-cheat compatibility - nothing can be loaded to the driver faster than 1 second).

[bread94]

So... does that means everything in Custom Curve Pro is operating in this 'beneath windows' space? You've kind lost me with that complicated answer. I still have the original question and now a couple more on top of that haha.

What is this about 1 second? Are you saying Custom Curve will inevitably cause an input delay of at least 1 second?

[TheNoobPolice]

2 hours ago, bread94 said:

So... does that means everything in Custom Curve Pro is operating in this 'beneath windows' space? 

Yes! Well, everything that actually affects your mouse input. The GUI which is just used to visualise and apply settings is in user space.

2 hours ago, bread94 said:

What is this about 1 second? Are you saying Custom Curve will inevitably cause an input delay of at least 1 second?

Obviously not as that would be ridiculous lol. When you press "Apply" all profile settings are written to the driver, and there is a 1 second delay until they are operational. There is no delay in use.

Edited September 23, 2023 by TheNoobPolice

[bread94]

On 23/09/2023 at 12:04, TheNoobPolice said:

Yes! Well, everything that actually affects your mouse input. The GUI which is just used to visualise and apply settings is in user space.

Obviously not as that would be ridiculous lol. When you press "Apply" all profile settings are written to the driver, and there is a 1 second delay until they are operational. There is no delay in use.

ohhh okay. Thanks a bunch for explaining everything to me and great work on that program, I'm glad I bought it way back. And yeah, that '1 sec' thing really threw me off, i was thinking im sure i didnt notice a delay in input hahahaha. Have a great day dude