Problem is that USBDeviceAddToWhitelistDialog starts a timer once created to poll for devices every second. In Qt, closing a heap-allocated dialog doesn't delete it, so it keeps on polling. This fix is to allocate dialog on the stack, then use "exec" to run it modally without returning. Once closed, the stack instance will get destroyed, thus killing the timer.
Gecko codes are a core foundation of most netplay sessions and most general modding cases. It has gone so far as to now have an ini for almost every game.
After the massive UI overhaul, the gecko code sorting defaults to Alphabetical with no option to change it. This removes the possibility for netplay builds to have important and necessary codes at the top for easy selecting, and removes the ability to sort massive code lists in categories.
This will also make the sorting consistent with AR codes, which are sorted manually.
* Removed the Cancel button since the code doesn't react to it anyway.
* Only show a window title, not the help icon (?), and disable the close button
* Set the title to "Dolphin" instead of repeating the label text
The current approach results in the UI thread creating a graphics device
whilst the core is running, leading to races on function pointers, and
potentially crashing.
Currently, each player buffers their own inputs and sends them to the
host. The host then relays those inputs to everyone else. Every player
waits on inputs from all players to be buffered before continuing. What
this means is all clients run in lockstep, and the total latency of
inputs cannot be lower than the sum of the 2 highest client ping times
in the game (in 3+ player sessions with people across the world, the
latency can be very high).
Host input authority mode changes it so players no longer buffer their
own inputs, and only send them to the host. The host stores only the
most recent input received from a player. The host then sends inputs
for all pads at the SI poll interval, similar to the existing code. If
a player sends inputs to slowly, their last received input is simply
sent again. If they send too quickly, inputs are dropped. This means
that the host has full control over what inputs are actually read by
the game, hence the name of the mode. Also, because the rate at which
inputs are received by SI is decoupled from the rate at which players
are sending inputs, clients are no longer dependent on each other. They
only care what the host is doing. This means that they can set their
buffer individually based on their latency to the host, rather than the
highest latency between any 2 players, allowing someone with lower ping
to the host to have less latency than someone else.
This is a catch to this: as a necessity of how the host's input sending
works, the host has 0 latency. There isn't a good way to fix this, as
input delay is now solely dependent on the real latency to the host's
server. Having differing latency between players would be considered
unfair for competitive play, but for casual play we don't really care.
For this reason though, combined with the potential for a few inputs to
be dropped on a bad connection, the old mode will remain and this new
mode is entirely optional.
Tilka