A yaw axis multiplier is wrong (because the motion server has inconsistencies of another nature) about ds4drv-cemuhook HOT 9 CLOSED

I sent a pull request for this #5
Also I edited the readme on my fork to allow to install it directly with those instructions: https://github.com/epigramx/ds4drv-cemuhook

from ds4drv-cemuhook.

I noticed that platforms in shrines rotate fine now just like PadTest(PadTest under wine). But the bow aiming is much slower than normal on the yaw axis. That appears to be a bug with Cemu or Cemuhook when under wine and I guess that's why you had initially multiplied it by 4.

from ds4drv-cemuhook.

There's a chance that something (either in this software or wine) limits the rate of the udp reception or dispatch. Motion on PadTest is not as smooth as on Windows(!) which might explain the bug with bow aiming.

from ds4drv-cemuhook.

Rethinking it the bug must be specific to BotW emulation on wine, because shrine motion-platforms rotate correctly and only the bow aiming is wrong, and even padtest is right as long as only one motion client runs (that last part seems to be a limitation of the server software).

from ds4drv-cemuhook.

After yet further investigation it seems that the problem is solely on this motion server, because a linux motion server for a Wii Remote Plus has no inconsistencies between BotW bow aiming and Shrine platform movement and I suspect an issue with either the timestamping of this server or the udp server dropping packets, but in either case I won't further look into it myself for now.

from ds4drv-cemuhook.

But the bow aiming is much slower than normal on the yaw axis. I guess that's why you had initially multiplied it by 4.

Yes, that was a quick fix for aiming in BotW to make the game playable.

padtest is right as long as only one motion client runs

This part is not implemented yet. The server only sends UDP packets to the last client it received a request from. Even if the last client goes offline, server will continue to send packets to the same socket.

I suspect an issue with either the timestamping of this server or the udp server dropping packets

Totally possible. I didn't change anything in the original ds4drv code, so timings may be inconsistent and incompatible with cemuhook. IIRC, ds4drv just parses raw events from DS4 and doesn't change their timing, so it might be difficult to fix.

from ds4drv-cemuhook.

Here it bugs if multiple clients connect to it. It's as if half of the packets go to one PadTest/Cemu and half to the other or it appears random in other cases. What is very odd about this server is that (after removing the X4 multiplier) moving a platform in a BotW Shrine that requires motion controls looks perfect just as PadTest but the bow aiming is wrong (and one could argue it's more important to do required platforms than aiming).

from ds4drv-cemuhook.

Some thoughts by Rajkosto (the author of Cemuhook) on the matter:

consistently dropping packets shouldnt matter as then it will just use the last sent packet for longer
but having more than one packet with same id or timestamp would be bad
ds4windows shows how to "expand" the ds4 timestamp into full microsecond timestamp

from ds4drv-cemuhook.

Oops! It appears that timestamps were encoded in the wrong format all this time (double instead of unsigned long long). After I changed the format, motion became much more smooth and all axes now have the same sensitivity in both motion shrines and during bow aiming.

I will push the fix in a minute. Feel free to reopen this issue if the problem still persists.

from ds4drv-cemuhook.