if the configured local pad is none, it will make dolphin behave
incorrectly (due to the game expecting inputs from the device while it
doesn’t exist).
Introduced in 6e13496d8, pads would get assigned to their netplay
position, which breaks assumptions. With this behavior, the SI devices
should be mapped properly.
This is only queried, there's no need to expose it for writing.
Even if it was written to, a data member shouldn't be part of
your public API unless its part of a dumb object or trivial struct.
Clients have no need to send their configuration information on start and the server straight out ignores it.
Not to mention it shouldn't try sending a struct as a null terminated string.
Cleans up how the server sends the configuration slightly as well.
So that it contains the current commit and not an arbitrary date that
may or may not be up-to-date. This will cause tears as people will not
be able to use netplay with one diverging commit that does not touch
anything related. On the other hand, users can’t be trusted.
Note - I removed a SleepCurrentThread(1) the patch added which seemed to
be unrelated to the actual job at hand. If there was a real need for it
(which sounds like it would be an enet-related bug - enet_host_service
is supposed to *sleep*), that needs to be dealt with...
I tried to change messages that contained instructions for users,
while avoiding messages that are so technical that most users
wouldn't understand them even if they were in the right language.
Replaces them with forward declarations of used types, or removes them entirely if they aren't used at all. This also replaces certain Common headers with less inclusive ones (in terms of definitions they pull in).
With some specific, STUN-hostile routers, the netplay client can get
stuck forever while trying to connect to the stun server. This adds a
5 seconds (much more than should be necessary if it works) timer until
a failure is registered and the attempt stops.
Otherwise, it would work but any async sending would be delayed by 4ms or
wait until the next packet was received.
Also increase the client timeout to 250ms, since enet_host_service is now
really interrupted.
Add std::unique_ptr<sf::Packet> objects to a queue instead of functions,
makes things easier to read, and avoids headaches while checking the
lifetime of the concerned objects.
Won't work with all games, but provides a nice way to spend extra CPU to make
a variable framerate game faster (e.g. Spyro or The Last Story), or to make
a game use less CPU at the cost of a lower framerate (e.g. Rogue Leader).
This takes the giant mess of controller-like devices (dance mat and
steering wheel) down to something more manageable, similar to how
the Donkey Konga bongo controller works.
Based-on-a-patch-by: comex <comexk@gmail.com>
