Emulator

This does technically appear to just be a result to how you guys have Dolphin handle the controller swapping after loading a state. I'm not sure if you'd consider it a bug. All I know is I was running into it until I figured out what was wrong

In si.cpp we have

    if (type == device->GetDeviceType())
    {
      device->DoState(p);
    }
    else
    {
      // If no movie is active, we'll assume the user wants to keep their current devices
      // instead of the ones they had when the savestate was created.
      // But we need to restore the current devices first just in case.
      SIDevices original_device = device->GetDeviceType();
      std::unique_ptr<ISIDevice> save_device = SIDevice_Create(type, i);
      save_device->DoState(p);
      AddDevice(std::move(save_device));
      ChangeDeviceDeterministic(original_device, i);
    }

Looking at ChangeDeviceDeterministic,

  if (GetDeviceType(channel) != device)
  {
    CoreTiming::ScheduleEvent(0, s_change_device_event, ((u64)channel << 32) | SIDEVICE_NONE);
    CoreTiming::ScheduleEvent(SystemTimers::GetTicksPerSecond(), s_change_device_event,
                              ((u64)channel << 32) | device);
  }

You're disconnecting the controller on the first tick, then one second later you're connecting the new one. The controller code does what it's supposed to and sets the neutral position when it detects the controller one second later, but it's not made clear to the user that their controller isn't connected so if they try and input stuff right away, they can goof the neutral position.

Billiard26 wrote:

This is just something the games do. They calibrate the controller when it is connected. The only solution would be to suppress inputs for some time and hope the game is done calibrating. I think this falls under "Working as intended".

Understandable. In my testing, games calibrated instantly. It's that one second delay after loading the state that was causing the problem more than anything as there's no indication of the fact Dolphin is detaching the old controller and then attaching the new one a whole second later.

Yeah, we could add an OSD message so the device change is apparent at least.

After looking closer at the relevant code I think forcing neutral values on calibration might be feasible (and sensible) (or at least optional).