So... my GIMX parts have arrived. I did a quick test today.

Results are amazing. Basically I've fixed the virtual joystick problem (completely bypassing CCP's virtual joystick and simulate our own DS3 controller) and now it feels like an almost linear input and zero acceleration. The only problem remain is the native speed limit of the DS3 analogue stick (at in-game settings 100%). If you move your mouse too fast you will hit the speed limit which feels awkward. The precision needed some tweaking (deadzone settings etc). Also the framerates can present a challenge to aiming, but in general aiming is much more predictable and there is much less weird magnetic feelings. But without much tweaking it already feels so much better than the native kb/m support. This thing's USB runs at 250hz too! (Compared to the native 100hz)

The keyboard mapping needs some time getting used to since it is now simulating the DS3. The shift key (L3) also toggles sprint which is a bit weird.

Parts. Top right: An ATMEGA32U2 board from Canada (NooElec brand). Bottom left: A bunch of unbranded CP2102 USB to serial boards from China. The seller sent me several by mistake, I just needed one.

Soldering up.

Testing. The instructions were wrong and I had to swap two wires to make it work.

Put on some protective nanites and we are done.

GIMX in action. To the left is my laptop (USB), to the right is mini-usb to PS3 (same cable as DS3 controller).

This is what the settings look like in Windows.

Mouse sensitivites.

What it looks like in-action. All your inputs (keyboard and mouse) will be sent to the PS3 as simulated DS3 controller signals.

Can't say my kd ratio has improved yet but I'm having fun playing with it. I can also dance around corners and toy with enemies with much more accuracy. It's nowhere near perfection, it is only as good as a DS3 controller can get. I need more time tweaking but I think I've already fixed the game to some extent.

Kinda sad that you had to spend extra RL $'s to get this game to work.

Dislike because basically you're modding a modded controller (KB/M). You're trying to have an advantage over the already advantage of KB/M over DS3.

I'm curious as to whether or not something like this is even "legal"?

What is CCP's policy on people using obviously modded hardware, and then advertising it on the forums?

Just wondering.

This is legal. Are you aware of the commercially available Eagle Eye adaptors? The GIMX does exactly the same thing. It is nothing more than an adaptor.

After extensive testing, I can confirm that CCP's DS3 aiming is broken.

It is not acceleration, it is not smoothing, it is not aim assist, it is PURE JITTER is being introduced into the aiming.

In the GIMX there is a calibration mode which simulates a set of inputs to test if the game is responding as predicted. It can repeat a series of sweeps of set distances (slowly turn left x amount, quickly turn right x amount) for observation so there is unmistakable that the issue is not in the player or DS3 controller. When I run the test, when in theory moving left X and moving right X (EXACTLY the same amount) should end in the same position, the game will turn the aim either not enough or too much.

This is not related to acceleration, sweeps with different speeds were mixed together and the aim do not solely overshoot/undershoot (which would indicate acceleration) but it jitters back and forth. This is done with aiming assist turned off.

This is not related to hardware issues either because different USB polling rates and simulation modes are all tested.

It means Dust 514's aiming somehow introduces RANDOMNESS into your movement from absolutely nowhere and there is no way to eliminate it.

This is a very bad news. Because this proves that Dust 514's aiming has inherited Unreal Engine 3's poor design - aiming cursor movements depend on frames (framerate). And it means that THIS GAME IS NOT FIXABLE because of the engine it uses. A very sad but undeniable truth which will deny any future potential for Dust to become an e-sport.

There, CCP I've done the work for you. You don't have to mess with your sensitivities anymore, the problem is not there.

It means Dust 514's aiming somehow introduces RANDOMNESS into your movement from absolutely nowhere and there is no way to eliminate it.

I'm curious as to whether or not something like this is even "legal"?

What is CCP's policy on people using obviously modded hardware, and then advertising it on the forums?

Just wondering.

Thats what competitive gamers do. Every single competitive genre allows customized controllers.

Only in offline, tournament situations is modded hardware bannable, and only when it destroys an entire dynamic to the game with a function such as turbo. I swear to god the console FPS community is more than ten years behind the rest of the industry when the average joe doesn't even recognize this.

After extensive testing, I can confirm that CCP's DS3 aiming is broken.

It is not acceleration, it is not smoothing, it is not aim assist, it is PURE JITTER is being introduced into the aiming.

In the GIMX there is a calibration mode which simulates a set of inputs to test if the game is responding as predicted. It can repeat a series of sweeps of set distances (slowly turn left x amount, quickly turn right x amount) for observation so there is unmistakable that the issue is not in the player or DS3 controller. When I run the test, when in theory moving left X and moving right X (EXACTLY the same amount) should end in the same position, the game will turn the aim either not enough or too much.

This is not related to acceleration, sweeps with different speeds were mixed together and the aim do not solely overshoot/undershoot (which would indicate acceleration) but it jitters back and forth. This is done with aiming assist turned off.

This is not related to hardware issues either because different USB polling rates and simulation modes are all tested.

It means Dust 514's aiming somehow introduces RANDOMNESS into your movement from absolutely nowhere and there is no way to eliminate it.

This is a very bad news. Because this proves that Dust 514's aiming has inherited Unreal Engine 3's poor design - aiming cursor movements depend on frames (framerate). And it means that THIS GAME IS NOT FIXABLE because of the engine it uses. A very sad but undeniable truth which will deny any future potential for Dust to become an e-sport.

There, CCP I've done the work for you. You don't have to mess with your sensitivities anymore, the problem is not there.

They can, you know, tweak the engine?
There are Unreal Engine 3 games that don't have this issue, because they did the smart thing of tweaking it before making a game out of it.

After extensive testing, I can confirm that CCP's DS3 aiming is broken.

It is not acceleration, it is not smoothing, it is not aim assist, it is PURE JITTER is being introduced into the aiming.

In the GIMX there is a calibration mode which simulates a set of inputs to test if the game is responding as predicted. It can repeat a series of sweeps of set distances (slowly turn left x amount, quickly turn right x amount) for observation so there is unmistakable that the issue is not in the player or DS3 controller. When I run the test, when in theory moving left X and moving right X (EXACTLY the same amount) should end in the same position, the game will turn the aim either not enough or too much.

This is not related to acceleration, sweeps with different speeds were mixed together and the aim do not solely overshoot/undershoot (which would indicate acceleration) but it jitters back and forth. This is done with aiming assist turned off.
....
There, CCP I've done the work for you. You don't have to mess with your sensitivities anymore, the problem is not there.

Million ISK says this thread gets locked, deleted, or moved and hidden.

Wow, the GIMX looks really cool. We're gonna buy one to test with. Thanks for the heads up on this and your testing, this is very cool stuff.

I want to make this totally clear: The aiming issues on the KB/M are really high priority and we're working on totally overhauling the mouse input system. I've already fixed the core of the problem and it's pending a lot of tweaks and regression tests before it's considered complete. I'll probably post some more info on exactly what we did when we release it, for now all I can say is I think everyone will be really happy with it :)

To sum up, because we accumulate movement discretely, the GIMX has to be synced to the dust framerate (which of course is impossible for you and very tricky for us as devs) and not move fast enough to trigger acceleration to guarantee 100% repeatable values. Otherwise you'll be off by a couple of frames with constant value input or more if you are sweeping the input.

Nothing short to what most pro gamers would do.

It's not random, it happens only when you have a target in your sights - it's very steady otherwise.

Nothing short to what most pro gamers would do.

Wow, the GIMX looks really cool. We're gonna buy one to test with. Thanks for the heads up on this and your testing, this is very cool stuff.

I want to make this totally clear: The aiming issues on the KB/M are really high priority and we're working on totally overhauling the mouse input system. I've already fixed the core of the problem and it's pending a lot of tweaks and regression tests before it's considered complete. I'll probably post some more info on exactly what we did when we release it, for now all I can say is I think everyone will be really happy with it :)


Warning! Highly technical stuff follows!

Regarding the over/undershooting polling rate and acceleration are the only frame dependent parts of the pad movement. Think of it this way: when the pad input is above a certain threshold it will enter acceleration mode and ramp up to a set max speed. That speed accumulates over every frame discretely so changes in frame rate or when exactly you start ramping down the pad input would make a difference on your ending point.
The same discrete accumulation affects polling rate.
The best test is to sweep with small movements over a long time with steady values (IE keep the input constant). If you change input values the exact moment that change happens during the frame could affect the final result. Also, even with constant input values you should still see +/- a couple of frames because when you start and stop the input test it could fall in different parts of the frame.

To sum up, because we accumulate movement discretely, the GIMX has to be synced to the dust framerate (which of course is impossible for you and very tricky for us as devs) and not move fast enough to trigger acceleration to guarantee 100% repeatable values. Otherwise you'll be off by a couple of frames with constant value input or more if you are sweeping the input.

If you're hungry for more testing, you can take some of this into account and see if it matches your experiences.

The aiming issues on the KB/M are really high priority

Wow, the GIMX looks really cool. We're gonna buy one to test with. Thanks for the heads up on this and your testing, this is very cool stuff.

I want to make this totally clear: The aiming issues on the KB/M are really high priority and we're working on totally overhauling the mouse input system. I've already fixed the core of the problem and it's pending a lot of tweaks and regression tests before it's considered complete. I'll probably post some more info on exactly what we did when we release it, for now all I can say is I think everyone will be really happy with it :)


Warning! Highly technical stuff follows!

Regarding the over/undershooting polling rate and acceleration are the only frame dependent parts of the pad movement. Think of it this way: when the pad input is above a certain threshold it will enter acceleration mode and ramp up to a set max speed. That speed accumulates over every frame discretely so changes in frame rate or when exactly you start ramping down the pad input would make a difference on your ending point.
The same discrete accumulation affects polling rate.
The best test is to sweep with small movements over a long time with steady values (IE keep the input constant). If you change input values the exact moment that change happens during the frame could affect the final result. Also, even with constant input values you should still see +/- a couple of frames because when you start and stop the input test it could fall in different parts of the frame.

To sum up, because we accumulate movement discretely, the GIMX has to be synced to the dust framerate (which of course is impossible for you and very tricky for us as devs) and not move fast enough to trigger acceleration to guarantee 100% repeatable values. Otherwise you'll be off by a couple of frames with constant value input or more if you are sweeping the input.

If you're hungry for more testing, you can take some of this into account and see if it matches your experiences.

I'll take that bet

Regarding the over/undershooting polling rate and acceleration are the only frame dependent parts of the pad movement. Think of it this way: when the pad input is above a certain threshold it will enter acceleration mode and ramp up to a set max speed. That speed accumulates over every frame discretely so changes in frame rate or when exactly you start ramping down the pad input would make a difference on your ending point.
The same discrete accumulation affects polling rate.
The best test is to sweep with small movements over a long time with steady values (IE keep the input constant). If you change input values the exact moment that change happens during the frame could affect the final result. Also, even with constant input values you should still see +/- a couple of frames because when you start and stop the input test it could fall in different parts of the frame..

That scratched my nerdy itch... but really needs a GRAPH

Warning! Highly technical stuff follows!
[...]
That speed accumulates over every frame discretely so changes in frame rate or when exactly you start ramping down the pad input would make a difference on your ending point.
The same discrete accumulation affects polling rate.

Wat?!

Are you sure the input processing is frame-rate-dependent? I think I misunderstood you, but are you saying that the input behavior is different when looking at someone standing in front of flaming wreckage than it is when looking the other way?

Please, be a nice dev and tell me that all input handling regardless of input device is done at 100 Hz outside the graphics thread based on the best timer the PS3 has available. Please.

Wow, the GIMX looks really cool. We're gonna buy one to test with. Thanks for the heads up on this and your testing, this is very cool stuff.

I want to make this totally clear: The aiming issues on the KB/M are really high priority and we're working on totally overhauling the mouse input system. I've already fixed the core of the problem and it's pending a lot of tweaks and regression tests before it's considered complete. I'll probably post some more info on exactly what we did when we release it, for now all I can say is I think everyone will be really happy with it :)


Warning! Highly technical stuff follows!

Regarding the over/undershooting polling rate and acceleration are the only frame dependent parts of the pad movement. Think of it this way: when the pad input is above a certain threshold it will enter acceleration mode and ramp up to a set max speed. That speed accumulates over every frame discretely so changes in frame rate or when exactly you start ramping down the pad input would make a difference on your ending point.
The same discrete accumulation affects polling rate.
The best test is to sweep with small movements over a long time with steady values (IE keep the input constant). If you change input values the exact moment that change happens during the frame could affect the final result. Also, even with constant input values you should still see +/- a couple of frames because when you start and stop the input test it could fall in different parts of the frame.

To sum up, because we accumulate movement discretely, the GIMX has to be synced to the dust framerate (which of course is impossible for you and very tricky for us as devs) and not move fast enough to trigger acceleration to guarantee 100% repeatable values. Otherwise you'll be off by a couple of frames with constant value input or more if you are sweeping the input.

If you're hungry for more testing, you can take some of this into account and see if it matches your experiences.

By the way there's a universal quarter a second of input lag, unless you run the game at 480p (where it's still there but minimized), that effects aiming as much if not more than this randomness problem. You guys do realize the Dualshock is affected as well right?



Aiming issues with KB/M have top priority in a console game where your target audience is going to primarily be using a controller with analog sticks? Where the aiming is just as bad if not worse? Sigh...

Again, input lag the main culprit here. It's almost certainly a performance issue that could be fixed...

I use a mouse exclusively and I'm gonna be honest, I had no idea aiming was still messed up.

Unless it was re broken in 1.2

I swear I can't figure out what you guys are talking about. Not about the jargen I mean I don't feel my aiming is off. At best I can say there have been a few sniper rounds that made me think, "I swear that should have hit that guy" but nothing to suggest aiming is broken altogether. I can still turn and shoot a dude in the face. What is the problen?

I use a mouse exclusively and I'm gonna be honest, I had no idea aiming was still messed up.

Unless it was re broken in 1.2

I use a mouse exclusively and I'm gonna be honest, I had no idea aiming was still messed up.

Unless it was re broken in 1.2

I want to make this totally clear: The aiming issues on the KB/M are really high priority and we're working on totally overhauling the mouse input system. I've already fixed the core of the problem and it's pending a lot of tweaks and regression tests before it's considered complete.

Read mechanics section for aim assist improvements

I've read this article about how they are going to improve aim assist, which will most likely benefit the DS3 only. I initially thought this was a horrible idea, but if they are implementing it the way it sounds it may really help DS3 people. I've been promoting better controls for all input systems, it seems like this will help with the DS3 fine aiming and tracking, which I can agree needs some work as well.

You're trying to have an advantage over the already advantage of KB/M over DS3.

-XOXO