Emulator

The bisect doesn't make any sense, that commit doesn't touch DTM code at all, it's just saving of options in the UI.

Techjar wrote:

The bisect doesn't make any sense, that commit doesn't touch DTM code at all, it's just saving of options in the UI.

Whether or not it makes sense, I see this problem on 5.0-80972 but I don't see it on 5.0-8970. If you get a different result, please let me know.

Can I not edit my last post? I meant 5.0-8972, not 80972.

What I'm implying is that it looks like a bad bisect. Do you use the bisect tool, or git bisect?

I did it manually in this case. If I'm not mistaken, the bisect tool has a problem with me needing to close the emulator and open the same version again, which is necessary to run replays on these versions. I never tried git bisect. After your first comment, I did run another quick test with 5.0-8970 and 5.0-8972, but I still got the same result as before. All I can go by right now is my own tests until someone else tries it.

I found there was something wrong with my testing after all. I will update this if I can figure out what went wrong.

It seems this was the result of something wrong with my configuration, that for some reason was only causing a problem starting at the version of Dolphin listed. This can be closed and I might make a new bug report depending on what caused this.

When the buffer is set to 12, the replay is created with the inputs playing from the wrong port. If the buffer is set to 5, it's normal. Going to test this further.

Are you adjusting the buffer while the game is running? This is known to break input recordings, but we don't fully understand why.

In my tests just now, the buffer was set before the game started and wasn't changed during gameplay. I have heard of input recordings breaking if you change the buffer while it's running, but that has never happened to me even though I usually do it when playing games online and recording.

Getting different results depending on the buffer number and version of Dolphin version. I was able to make the wrong controller problem happen on 5.0-8790 with the right buffer number, so I'm going to see how much farther back I can go to find where the problem really starts.

Seems this goes right back to 5.0-8324 when reduce polling rate was added, which is connected to the problem, since it needs to be checked for this to happen. I set the buffer to 12 before starting the game on that version. When it was set to 5, there was no problem with the controller order being wrong in the replay.
Again, to test, it's GC adapter as controller 1 in netplay while local controller 2 is standard. Buffer set to 12 and reduce polling rate is checked, and the game is Double Dash.

Can you upload one of the "broken" DTM files?

https://www.mediafire.com/file/3y7yywawy1l58j9/Double_Dash_broken_replay.dtm/file
Created with Dolphion 5.0-8324. To play this as I made it, you need to make sure that the first controller port is set to GC adapter while controller port 2 is standard controller. I originally got past the title screen and was sitting at the main menu, but this won't show up if played normally. If you were to start the replay with standard controller set as port 1, and then quickly switch it to GC adapter, it would switch to the correct order and player 1 will get past the title screen. However, this is not the "right" way of playing it.

Please upload the file to the issue tracker, as your mediafire link does not work here for whatever reason.

Also please use the latest version to make the DTM, forgot to mention that. It's more tedious to debug if I have to pull up old code.

bReducePollingRate is set correctly in the header, so it's not an issue with saving the setting in the header.

Starting at version 5.0-10479, I haven't had a problem with a dtm playing back with the wrong controller order. It's still worth noting that if I record on 5.0-10479 with reduced polling, GC adapter and fair input delay starting at buffer 12, it plays back with the right controller order on 5.0-10479 but the wrong order on 5.0-10477. If I start the recording with pad buffer 5, the controller order is right on both versions, so there is still something different about the dtm file when recording with pad buffer 12, but it appears to play back correctly no matter what on the latest Dolphin. I still haven't had a chance to do a serious 4p game to be absolutely certain everything works.

Eh, who knows what sort of weird nonsense can happen when a DTM desyncs. Sounds like the cause is the same as the other GC adapter bug, and it's fixed now, so I'm happy with that.