We want to use positional arguments in translatable strings
that have more than one argument so that translators can change
the order of them, but the question is: Should we also use
positional arguments in translatable strings with only one
argument? I think it makes most sense that way, partially
so that translators don't even have to be aware of the
non-positional syntax and partially because "translatable
strings use positional arguments" is an easier rule for us
to remember than "transitional strings which have more than
one argument use positional arguments". But let me know if
you have a different opinion.
Instead of comparing the game ID, revision, disc number and name,
we can compare a hash of important parts of the disc including
all the aforementioned data but also additional data such as the
FST. The primary reason why I'm making this change is to let us
catch more desyncs before they happen, but this should also fix
https://bugs.dolphin-emu.org/issues/12115. As a bonus, the UI can
now distinguish the case where a client doesn't have the game at
all from the case where a client has the wrong version of the game.
With the SI poll line count fixed, pretty much all games are polling
twice per frame anyways, making this option superfluous. Since it's a
bit of a gross hack and makes DTMs incompatible with console, let's
just bin it.
This new setting is like Override Language on NTSC Games, except
instead of only applying to the GameCube language setting,
it also applies to the Wii language setting.
Fixes https://bugs.dolphin-emu.org/issues/11299
The logic didn't account for the case where a player leaves, so the
host would be left in a dangling state where the UI is disabled but the
game won't start, requiring a full restart of Dolphin to fix.
This is an extension of host input authority that allows switching the
host (who has zero latency) on the fly, at the further expense of
everyone else's latency. This is useful for turn-based games where the
latency of players not on their turn doesn't matter.
To become the so-called golfer, the player simply presses a hotkey.
When the host is the golfer, latency is identical to normal host input
authority.
Small addition of NetPlay code in Core.cpp was needed to set the
extensions at the right time, as init would override them otherwise.
This solution is more elegant than modifying the user's INI files on
game start.
The implementation of peer initialization would hang if the initial
packet was never received. This fixes that issue by deferring the
initialization to the packet receive loop.
This sends arbitrary packets in chunks to be reassembled at the other
end, allowing large data transfers to be speed-limited and interleaved
with other packets being sent. It also enables tracking the progress of
large data transfers.
Its usage was inconsistent, confusing, and buggy, so I opted to just
remove it entirely. It has been replaced with PadIndex for the
appropriate instances (mainly networking), and inappropriate usages
(where it was really just a player ID) have been replaced with the
PlayerId type. The definition of "no mapping" has been changed from -1
to 0 to match the defintion of "no player", as -1 (255 unsigned) is
actually a valid player ID.
The bugs never manifested because it only occurs with a full lobby of
255 players, at which point the last player's ID collides with the "no
mapping" definition and some undefined behavior occurs. Nevertheless, I
thought it best to fix it anyways as the usage of PadMapping was
confusing.
Adds a tickbox to the server's window to syncronize codes. Codes
are temporarily sent to each client and are used for the duration of the
session.
Saves the "sync codes" tickbox as per PR Netplay: Properly save hosting
settings #7483
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.
also did these things
fixed crash from joining user that isn't hosting via a direct connection
current game stat can now pass to override the current game in config
uses ip endpoint from dolphin.org
