dolphin
dolphin copied to clipboard
IOS/KD: Add WiiLink as WC24 service provider by default
As discussed, this PR has WiiLink as the default service for WiiConnect24 services by default (More are coming!)
Currently, there is a checkbox users can toggle in the config to disable or enable WiiLink. If enabled, it will reroute requests by a supportted channel to the WiiLink equivalent.
Image of the config option under Wii
TODO: Somewhere to put the Terms of Service visibly. JMC had the idea of having it popup much like the Analytics disclaimer.
The changes look sane - I wonder if we should use a dropdown instead of a checkbox though, just in case we decide to add more WC24 service provider in the future. Also, I think it'd be nice to have a description of what WiiLink is in the tooltip text.
Alternatively, let's add an INI override for the server names to e.g. make local testing/development of WiiLink style services easier
Added an INI field as requested, as well as rename Enable WiiLink
to Enable WiiConnect24
. If Enable WiiConnect24
is checked, Dolphin will load the default INI for the WiiConnect24 title. Otherwise, it will load the user's INI.
I have also added WiiLink URLs to the default INI. Nintendo Channel is also currently not in a complete state as main requests use SSL.
Looks like MSVC is unhappy about operator< being used on bools; this is a side effect of the wrong overload of TryParse getting selected.
Consider adding a specialisation of TryParse for boolean enums: https://godbolt.org/z/xPn5dzzof
// add this:
template <typename T> requires (detail::IsBooleanEnum<T>())
bool TryParse(T* output) {
bool value;
if (!TryParse(&value))
return false;
*output = static_cast<T>(value);
return true;
}
// and then change the integer/enum template to this:
template <typename T>
requires (std::is_integral_v<T> || (std::is_enum_v<T> && !detail::IsBooleanEnum<T>()))
bool TryParse(T* output);
Just added the patches in the INI files for all regions of the Nintendo Channel. Should be good to merge now.
Aside from those this seems fine. I'll grant that it's not particularly likely that those domains would appear anywhere outside the specific places you're expecting them, but it still doesn't seem a great idea to run a blanket search-and-replace when you could be more targetted to what you're actually expecting.