Pootez
Pootez
About
- Username
- Pootez
- Joined
- Visits
- 116
- Last Active
Comments
-
I've found a workaround for the accessibility issue:
-
Hey, I finally found a workaround for using hybrid inputs!
-
Another update
Through testing and analyzing footage I've made these discoveries.
The input/update suppression appears to occur roughly as frequently regardless of framerate cap.Upon inspecting footage frame by frame at multiple FPS caps, I've noticed this: The control scheme consistently changes back and forth between controller and KBM, where the interval where no control scheme is active being visible for an interval among the switch.
The intervals are as follows:
framecap
Glyphs
NoGlyphs
30 fps
4 frames
0 frames
60 fps
6 frames (sometimes 7)
1 (sometimes 0)
120 fps
10-11 frames
2-3 frames
Estimated ms
90-100 ms
20 ms
The intervals of these observations may be machine dependent. Through these estimates, we can make the hypothesis that inputs/updates should be suppressed in a ratio of around 1 to 5 (1/6).
Through limited testing, this seems accurate.
If we speculate that the interval where the control scheme doesn't change is constant, and the interval the game spends switching control schemes, we can assume that the bug will occur more consistently on lower end machines, and less frequently on higher end machines.
If anyone would like to recreate this experiment, to compare intervals, here's the setup I used:
- Boot up custom game as Pig (// if testing input consistency)
- Set FPS cap (or keep it at the highest, as it seems consistent across FPS)
- Start recording
- Consistently move mouse while moving with analog stick
- // Bind crouch to a mouse button (KB or controller buttons will be ignored half of the time)
- // Try crouching and uncrouching, and note how many attempts are ignored out of total attempts
- Check the video frame by frame and count the frames glyphs are and aren't present.
- Convert result to ms: 1000 * frames / FPS
Fun fact, Ghostface's crouch is seemingly never ignored by this bug, while Pig's crouches are 😎They are likely different input types.
Attempts at configuring the Engine.ini file to change the interval or disabling input type switching hasn't worked for me.
The interval observed in these tests is likely a debounce interval to prevent accidental switching (or performance loss), and is likely inaccessible without changing the game's source code.
In short:
There is around a 1/6 chance that the bug suppresses an input or an update, but might be machine dependent.
Lower end machines may experience the bug at higher frequencies. If the game takes 50 ms to switch input types, the bug would occur around 1/3 times.
-
An update after testing:
https://forums.bhvr.com/dead-by-daylight/discussion/comment/4009031#Comment_4009031
-
Through some testing, here is an update:
Mouse buttons function in both control schemes, are never neglected by the control schemes themselves, and do not cause a switch in control schemes. This means they can be used to minimize the issues caused by this bug.
However, there appears to already be an interval implemented after a control scheme switch occurs, in which another switch cannot occur. This appears to de dependent on framerate (higher framerates mean more scheme switching). This may have been introduced in a previous update, which would explain why FPS drops (and missed inputs) are less prevalent, since switching doesn't appear to happen every frame (anymore?).
My observations/hypotheses:
- The interval in which a control scheme switch is happening causes game updates that happen within the interval to be suppressed.
- Any (instant) inputs given during this interval are not registered. Key bindings of held actions such as sprint/crouch/attack isn't affected by the switching, given they are registered differently, probably by checking their up/down state each tick. Key bindings for instant actions, such as toggle actions(survivor interactions, crouching on pig/ghost face), are monitored for instances that they are pressed, which doesn't register when a control scheme switch is occurring, regardless of input type.
This was tested by moving/looking around and trying to continuously crouch/uncrouch as Pig, where the input was inconsistently & infrequently missed. The same could be observed from pallet stuns, where the effect is infrequent, but noticeable.
In brief, there is a tiny interval where inputs & game updates can occur every time control scheme switches, which can occur after an interval of frames.
Hypothetically, to explain the concept: If the interval where control scheme switching couldn't happen was extended to something like 1 second, the issue wouldn't be functionally exploitable, but this would be the effect on the use of hybrid controls:
- Any instant/toggle input on keyboard/controller would be unusable in 1 second intervals, resulting in it being unusable.
- The method of only using mouse buttons would be almost perfectly usable, given that mouse buttons inputs aren't dependent on control scheme.
- Glyphs would possibly change every 1 second.
- Updates and inputs could be ignored for a tiny interval every 1 second.
Even if analog inputs are stopped from causing constant control scheme updates, things like scroll wheel can still be used to this effect. Software rebinding and Steam input can be used to create continuous scroll wheel inputs, which would recreate this bug, potentially for exploitation.
Optimal fix suggestion:
Stop analog/spammable inputs from causing a control scheme switch, whilst ensuring that multiple input types are compatible simultaneously, to maintain hybrid controls support (possibly through settings option).
-
@Laurie268 said:
Atleast now people will start abusing it and BHVR will be forced to patch it… sad that that’s what it takes to get something fixed
I thought about not making a larger post about it, but I feel like this would be the result:
- I post a bug report on the forum. Only people who are looking through bug reports would find out about it.
- Those people may start abusing it, and people who witness it would just assume they're cheating.
- The issue gets misdiagnosed by the community as a cheat, and awareness around the specific exploit isn't clear.
- The bug would remain for longer, even though less people may have the knowledge of how to abuse it.
At least if the community is made aware of it, they can more actively campaign for change, and hopefully acknowledge that the accessibility aspect shouldn't be ignored in fixing it.
That, as well as we might see more skill expression if people are made aware of and able to try out this alternate hybrid control scheme, especially for those that would gain aid in accessibility. I genuinely think that'd be an nice direction for the game, even though some might complain that a hypothetical "optimal" control scheme is harder to access, since controller + mouse may be the only option for some, without purchasing something like an Azeron Cyborg (or similar).
Some Youtube videos may at least contain less frequent mouse flicking, as seen by some youtubers that use controller.
-
@AbsolutGrndZer0 said:
Thank you so much. I had no idea something like this was even possible, though I now see why it would help many people. Heck, if not for the bugs you mention here, I might even consider trying it myself instead of KB/Mouse as sometimes I can't play very long as my keyboard hand starts to cramp up… But definitely don't want to deal with these bugs.
I haven't witnessed anything abusable using it on survivor, where I think the main benefit is, since you're more actively looking behind yourself in chase. I've been using the method of rebinding some keys to mouse buttons, and it seems somewhat stable, although some inputs are still ignored at times. I notice I'm not instinctively doing precise 90 degree flicks, and have an easier time looking around while maintaining my direction 👍
-
One day for sure guys
-
Is this still being worked on? Seems like most games fix this by allowing you to force one layout (keyboard or gamepad), so that multiple inputs don't trigger a switch. Would be great accessibility for people who use hybrid inputs.