Region list addition to yml file for increased flexibility and compatibility

[thesystemcoder168]

This pull request adds the RegionList key to the config.yml file. Instead of relying only on the default of:
regions = {"asia", "au", "cae", "cn", "eu", "hk", "in", "jp", "za", "sa", "kr", "tr", "uae", "us", "usw", "ussc"};
a user can now specify the regions which are used.

YML Syntax (Under the Misc Section of config.yml):
Example 1:
RegionList:
- Asia

Example 2:
RegionList:
- Asia
- Europe

Example 3:
RegionList: Asia

Example #2 has been added to the config.yml file but it is commented out.

Reasons to add this:

1. This can be used to try to match the region names used/displayed by the client. Unknown regions from the client side may not always be responded to appropriately.
2. It has been observed at least in one case that going down to 1 region (or at least less number of regions), can result in less issues. This can led to the initial phases of creating a game / joining a game to succeed most/all of the time. Whereas with a big list of unrecognized regions, either or both sides can fail. Secondly, this erratic behavior can make finding problems much more difficult.
3. It has been observed in at least one case, that a smaller region list of valid names can result in a shorter time for the join/create game to initially respond back to the user. (observed around 5 seconds vs 35 seconds)
4. This does not change the default behavior if the new key is not specified in the .yml file. So this will not break existing configurations.

[niansa]

Hi! Thank you for your pull request.

First of all:

• This can be used to try to match the region names used/displayed by the client. Unknown regions from the client side may not always be responded to appropriately

• It has been observed in at least one case, that a smaller region list of valid names can result in a shorter time for the join/create game to initially respond back to the user. (observed around 5 seconds vs 35 seconds). This can led to the initial phases of creating a game / joining a game to succeed most/all of the time.

Which game(s) are you observing this with exactly? Just so that I can reproduce this myself and verify.

It has been observed at least in one case that going down to 1 region (or at least less number of regions), can result in less issues. This can led to the initial phases of creating a game / joining a game to succeed most/all of the time. Whereas with a big list of unrecognized regions, either or both sides can fail. Secondly, this erratic behavior can make finding problems much more difficult.

"Either or both sides"? Well if that's the case we can't do much about the client failing here besides giving the client exactly what it expects. But are you indicating the server can fail occasionally based on this? Can you give me more info on that, like server side debug logs?

This can led to the initial phases of creating a game / joining a game to succeed most/all of the time

That's weird. The game creation phase is no longer in any way related to the region list, since each region will point to the same master and game servers. Can you give me more info on this, like debug logs?

---

Your implementation is too unforgiving. Clients expect region strings like eu. us, usw, etc.

This would be up to the person configuring this to figure out... in fact, your configuration example got this wrong and would send strings to the client it doesn't expect. I am not sure what the correct solution to this is, but your current solution ain't it :-(

[niansa]

@thesystemcoder168 I have received your email and have been unable to decrypt it, since the published key is not up to date.

Here's my current keys fingerprint: B79A 5AAD C66F F02E 098C 254D 2D26 A680 600B A537

You can find it here: https://keys.openpgp.org/vks/v1/by-fingerprint/B79A5AADC66FF02E098C254D2D26A680600BA537

[niansa]

It's also available under my domain: https://public.tuxifan.net/tuxifan/Tuxifan_0x2D26A680600BA537_public.asc