The datapad seems to not react to keyboard inputs that happen "too fast" (not actually too fast, only fast for what's processing them) after one another (eg. quickly pressing and releasing the same direction arrow more than once), resulting in the selection not moving at all. Previously this wasn't the case: the datapad controls had a small delay, but you cold "queue" keypresses and all of them were effective with that small delay in between them.
Also, after some time datapad controls started to produce several (usually 2-3 per keypress) of the "clicks" that happen when the selection moves for a single keypress, and these clicks are heard even when the selection itself doesn't move for the above reason.
I think the control rework caused mouse sensitivity to treat horizontal and vertical movement at a 1:1 ratio, which means that when horizontal is "conveniently fast", vertical becomes extremely twitchy, the smallest movement sending it to 90 deg up/down.
Previously it felt just right, so trying to reproduce a similar ratio or behaviour should work better.
On a related note, mouse look/control as a whole feels a lot different than before, but I can't quite tell in what way. Maybe as if turning was done in small but fixed amounts and input specifies how many of such discrete jumps are performed...? There also appears to be a loss of precision for small movements, while large/fast movements are capped at a certain rate, so essentailly working the opposite of how it should: slow movement should be smoother and fast should be more coarse.
Actually, I think it's mouse smoothing/dampening working in reverse. Small movements are amplified and large movements are attenuated. The faster the mouse moves across the same distance, the smaller the resulting turn rate becomes.
Since you mentioned you are working on some control changes currently, and I couldn't find mention of this after trying a few search terms...
In a considerable amount of cases (I'd estimate maybe one third of them) when you finish interacting with something (hab status console, inventory access hotspot, system status console, system maintenance area, etc.), but more commonly in the case of the hab storage hotspots and the status screens of the external systems, the heading and pitch of the player character's orientation jumps to some random values. It doesn't feel like some kind of buffered input being applied, as there is no transition, the view doesn't "move" to the new position, it "snaps" to it immediately, and it also can happen when you are very careful not to make any excess input while in interaction mode (datapad up). The amount of change in both values seems completely random, sometimes it's just a few degrees, but it can also be up to 180 degrees in heading and 90 degrees in pitch, which is really disorienting when happens, especially the heading.
Although the movement system is good enough as it is, I thought of two areas where some small improvements are still possible:
- You can change direction when jumping / falling. Obviously this isn't possible IRL.
- You climb just as quickly as you walk on level terrain. Even though gravity on Mars is much lower than on Earth, it shouldn't be possible to run up a nearly vertical slope with a speed of many m/s. Right now there really isn't any reason not to walk to your destination in a straight line. IMO it would be more fun if walking would require a bit more planning with regards to the terrain, i.e. find the shallowest approach to get to your destination fastest. Perhaps something simple as (pseudocode) newPosition = oldPosition + Time.fixedDeltaTime * speed * direction * (1 - Vector3.Dot(direction, Vector3.Up)) would work? Even at a 45deg slope it would still be doable at a .707 speed factor, while at more extreme angles it would quickly slow you to a near stop.
I don't know how easy they're to implement, and I imagine you have higher priority suggestions, but perhaps you could 'fix' these in the future :)
During one playing session a few days ago I noticed that the datapad would be in "walking mode" when I was walking and I didn't have to hold the shift key. Don't know what caused it and it has only happened once.
If you delete the last (only) photo in the Photos part of the Datapad, it gets "stuck" on the Photos screen: it's still displayed as if it was an existing photo but the Edit menu no longer works as the photo doesn't actually exit anymore.
Additionally, every time you make a single photo then delete it, the photo counter will get increased but never reset to 0 when the (last) photo is deleted. Eg.: take one photo, it will read 001. Delete it, it will still read 001 even though you have no photos. Take another photo, now it will read 002, even though it's the first and only photo you currently have. Delete it and take another one, now it will be 003, while again actually being the only photo you have.
When the heart rate display is visible, jumping or getting airborne in any other way causes it to disappear for the duration of not being in contact with the ground, then it reappears on touchdown.
It only happens when standing still or walking, but not while running.
(On a side not not related to the issue itself: it could be useful to add a category here for "User Interface" or something similar, since these kinds of issues are not really graphics nor control related, but currently there's no really suitable category for them.)
Customer support service by UserEcho