Problem with wiimote v1

[FlyingPC]

I've been using linuxmotehook2 for some time with Cemu. Thanks a lot for this job, I greatly appreciate it.

It works well but I had to make a modification to the source code of gcemuhook/src/Server.vala so that the movement of my wiimote is correctly taken into account.

In the "normal" case, I had to modify the accelerometer consideration in this way (l. 449 of gcemuhook/src/Server.vala):
"""
case NORMAL :
//retour accel;
retourner MotionData() {
x = -accel.x,
y = -accel.y,
z = accel.z
"""

Without this modification, I have to flip my wiimote in order to be able to play Mario Kart 8 but I didn't quite understand why.

Despite these changes, there is still a problem and that is why I am sending you an email.

When I hold my wiimote flat (in this way: ---), I notice while playing Mario Kart 8 that the kart does not go straight but turns slightly.And to go straight, I have to turn my wiimote a little bit. I think there is a calibration problem.

I would like to know if it is possible to somehow calibrate the accelerometers with linuxmotehook2. I couldn't find anything in the .ini file or the source about this.

[FlyingPC]

Now I am testing new commit under dolphin. But it seems to not work properly. I am trying to play Mario Kart Wii but the kart doesn't turn. But it is maybe a configuration problem. In the input configuration panel, I see accelerometer moving but I don't understand what I am looking at.

With the new commit there is still a problem with the neutral position. with Cemu

[v1993]

Please post screenshot of dolphin's motion input tab.

[FlyingPC]

Here a 6 screen shots of accelerometer position see by dolphin in 6 positions of the wiimote.

1 : correspond to the wiimote placed on a table face up.
2 : correspond to the wiimote rotated 90° to the left in relation to position 1
3 : again 90° to the left (so the wiimote is face down
4 : again 90° to the left.
5 : wiimote placed vertically (power button at the top)
6 : wiimote placed vertically (power button at the bottom)

[FlyingPC]

Everything of that with the last commit.

[v1993]

Can you try changing this line to if (true) { and test dolphin again (with screenshots)? It would seem that orientation for gen2 was correct all along.

[FlyingPC]

Can you try changing this line to if (true) { and test dolphin again (with screenshots)? It would seem that orientation for gen2 was correct all along.

Ok, I'll try tomorrow. Thanks for your help !

[FlyingPC]

Here is the test :

[v1993]

Judging from this picture old original orientation was indeed correct all along, oh well. I went ahead and reverted last commit. So this suggests that something is off in your cemu setup. I've asked this in email - are you emulating gamepad or wiimote there? If gamepad, can you try connecting motion plus (assuming you have it)?

[FlyingPC]

Have you ever try to disable gyroscopes in linuxmotehook2 to "simulate" the behaviour of a wiimote v1 ?
I ask that because, from what I have understood, a wiimote Motion Plus is a wiimote v1 with gyroscopes. So maybe disable gyros will generate same issue.

[FlyingPC]

My wiimote doesn't have motion plus and in Cemu, I'm using this config in Cemu :

[v1993]

The thing is - clients tend to offer limited support for no-gyro motion sources due to significantly reduced amount of information available. Some (yuzu and likely dolphin/cemu too) run their own simulation of movement rather than directly pass input values to program, which worsens data quality in no-gyro situations. On my end lack of motion plus only makes linuxmotehook2 report that gyro is missing - and that's about it.

That said, this shouldn't lead to incorrect axis mapping like you're describing. Sadly, I don't have any wiimote-accepting games on WiiU to test this, but this sounds like a potential issue on cemu's side, possibly hidden by testing only with motion servers that have gyros. Judging by Dolphin screenshots, there's nothing wrong with data I'm sending.

[FlyingPC]

I have posted an issue in cemu github.

[v1993]

Closing this issue as apparently not caused by us, will reopen if needed.