When moving around, I’ve noticed my character snapping to cardinal directions. This makes movement feel less precise, especially on balance beams.
After extended fiddling with controllers, I now suspect that Wicked has built-in dead zones. I’ve learned that Unity has, or had, unusually separate x and y dead zones by default. This might explain the snapping behaviour.
Reflecting on my inability to fly, or at least land, as the Balak Taw do, I believe a change here might help us all maintain our balance on the many beams and branches that we so often decide to cross in plate-mail and heavy rain.
(If this is a controller-settings issue after all, please let me know and I’ll dig some more; but I’ve gone relatively far to verify that it is not.)
I usually play with a Switch Pro controller, which has no build-in dead zones, and for the sake of testing have verified with an Xbox Elite Series 2 and an XInput device I cobbled together to send arbitrary (16-bit) axis values to be really sure.
I also verified it isn’t Steam Input, which has circular dead zones (set to 0 for testing).
Been keeping an eye out on the movement and I don’t think I am experiencing deadzones like you have described. I am using a Vader 5 Pro. Wish I could be more helpful. Sounds like a bothersome issue.
Thank you, that’s very helpful in itself. If I can eliminate Wicked itself as the culprit, I’m one step closer to a solution. The dead zones are also rather slight, just hard to un-notice.
(I wonder if it’s related to gaming on Linux. I’ll check if it still happens to me when running Wicked under Windows. After that, the next ‘reasonable’ step might be to build a minimal Unity twin-stick game, run it through Proton, and see where the dead zones are happening if they do.)
in my attempts to incorporate run into the joystick I have encountered this issue. It’s seems to be related to the very low ranges. The game doesn’t recognize very low ranges as inputs, likely a built in deadzone, and because corners tend to ramp faster than cardinal directions what happens is the closest is recognized first before the combination and you get that janky movement. If you add in a antideadzone it will allow the corner ranges to ramp up faster and thus bypass 1 direction being recognized before the other.
For me, my final solution was to switch response to per axis, range to square, very low deadzone, very extreme max range, and low antideadzone. With this i am able to move directional smoothly with fine inputs, and by reducing maximum range to 68% I also only trigger run on the outskirt edges. Corners can still reach upwards of 78% which does mean true corner engages run slight sooner, but it basically still on the very edge and only way to ensure 68% was seen on all other edges. But that janky movement is 100% because the lower ranges are acknowledged and corners tend to ramp up 1 faster than the other axis in circular mode, so you will always get that initial janky cardinal movement before the combination is recognized with fine movement.
I think we might be describing slightly different behaviours: In your case, at low magnitude, there is a brief initial movement in a cardinal direction, then correction towards the final direction as magnitude increases, right? If that’s the case, I understand your explanation.
In my case, when I smoothly rotate the stick at full magnitude, there is an angular interval around the cardinal directions in which small adjustments to my direction do not change my character’s movement direction.
That said, thank you very much for making me aware of anti-deadzones. I was unaware they existed. I’ve managed to set a per-axis anti-deadzone to mostly fix my issue.
Still, I believe Wicked would benefit from a less fiddly solution.
I’ve also created a minimal Unity twin-stick shooter just to test this – or at least movement and aiming – and after eliminating all other factors I’m now sure Wicked has its own per-axis deadzones. While setting up my test, I noticed that Unity’s Input Manager defaults to dead zones of nearly 0.2, which is eyewatering, and the Input System package to around 0.12, which feels suspiciously close to Wicked. Dead zones are square/rectangular/per-axis in both cases.
yeah, while working on cleaning movement again yesterday I noticed this behavior. Dispite everything I tried… I could not break the initial snap off the cardial, the angle is hardlocked, no ammount of trickery seems to break it. The only solution to it would be keyboard and mouse mode, and use mouse region on stick with movement set to parameters. However because the game likes to off center the camera a lot this solution proves unviable aswell, but when centered it clearly demonstrate that I can move more precise.
I used the stairs in Sacrament off the whisper to test movement trajectory, it seem with the current system it is impossible to walk up the middle using joystick. Mouse region allowed me to split the hair.
If they ever give a camera is always centered option I may abandon controller mode altogether just for precision of mouse region and flexibility with binding.
also I notice too yesterday that the snap behavior is due to square or cross deadzone regions. While square allowed for a quicker ramp up it still has that initial snap, my final solution was to create a artifical deadzone by making the joystick only active once its deflected. This allow me to set input curve to be aggressive/ circular and start immediately 30 % on activation without dealing with touchy input or drift, eliminating the initial janky movement and then ramp up toward the edges gradually while having no snap. This is when I truly understood your issue and what you meant and why I came back here… because I could not reduce the trajectory no matter what I did, even when cardinals were blocked. All angles just shy of 40degrees off cardinal directions are impossible to achieve with joystick.
