
#Star citizen lower joystick sensitivity full#
As a one third deflection of the stick reports a position of 43,580.11 or 21,953.88 (depending on a left or right defelection) Which from my cursory testing is over the max input in cryengine, thus resulting in a full rotation of the mech's torso.Įven with the large deadzone, that seem to be implemented now, movements from full deflection to half are not possible due to the discrepancy between what cryengine reads as max and what the stick reports as max.Ĭhanging the sensitivity doesn't make the system more useable because it simply caps the max output. Which is a problem if sticks are reporting in a 16 bit format via Directinput. Thus any report over the max is read as maximum. What happens is cryengine is setup to read a number as max input. This is a function of Cryengine reading the reporting position as very large numbers and not handling them well or scaling them proportionally. Which is the true definition of absolute input control. A half deflection of the stick does not correspond to half the torso twist of the mech. The major problem with the system now is that, joystick outputs are not proportional to torso movements. Thus a mech which can move it's torso 180 degrees, would move more degrees per joystick reporting number than a mech which can only rotate 90 degreesĤ9151.34 = 45 degrees of mech rotation for a mech capable of a total rotation of 90 degreesĤ9151.34 = 90 degrees of mech rotation for a mech capable of a total rotation of 180 degreesĥ46.12 = 1 degree of rotation for a mech capable of a total rotation of 90 degreesĢ73.06 = 1 degree of rotation for a mech capable of a total rotation of 180 degrees With a report of 32767.5 being center.Įach degree of rotation per joystick reporting number, is a function of the mech's total possible amount of rotation. A report of 49151.34, should rotate the torso to 45 degrees. A joystick reporting a value 65,535, should cause the mech's torso to rotate 90 degrees. Thus, in a 16 bit unsigned reporting system, with a mech that is capable of rotating 90 degrees to each side. The way the system should work, is that each integer of joystick output should correspond to a position of the mech's torso. Thus it's possible for 8 bit stick, (range 0 to 255), to report in a 16 bit format unsigned ( 0 to 65,535,) or signed format ( -32768 to 32,768) What I want to see instead is the sensitivity slider acting as a variable to the rate of traversal.ĭirectInput is capable of reporting any range of motion for a joystick and translating it. It is behaving exactly as your math indicates such that you either lose torso movement or waste deflection. Right now it seems like the sensitivity slider is acting as you are describing, as a linear adjustment to the range of the axis. If I move my stick such that I am now reporting 12000,0 that is going to translate to a screen position, and the rate of traversal for the mech will determine how fast the cross hair moves to that position.

This is the current behavior under absolute positioning. We have mapped a centered screen of 0,0 to my centered sticks values of 8000,8000. We know that my centered stick has a value of 8000,8000. Let's say we know the value of a centered torso cursor position, say 0,0. It is like using a touch screen, where you put your finger is where the cursor is. With absolute position we get a x and y value out of the stick, that translates to a x and y value for the cross hair.

My joystick reports a value from 0 to 16383. You can translate that value to a percentage of that axis, but there is a specific value.


Axis position is effectively a percentage of available deflection.
