Alrighty, we did alot different tests and monitored the connection for the past hour.
Out of the 390k packets total sent, only 6 were ever dropped (4 were by et-0-0-48-br01-eqsy4.as57976. net, 2 by unknown.telstraglobal. net).
No other issues or big spikes seen anywhere over my ISP’s network or my route to the Sydney AWS (SYD2 data center).
For what it’s worth I’m told my connection to PSE1/LAX1 servers are also as good as they can be, with suprisingly 0 packet loss despite being on the other side of the planet.
He then remoted in and installed wireshark and did some more tests.
On game startup the client connected to 11 total IP addresses and chatted/pinged with them over 5ish seconds.
These included the SYD2 data center IP 37.244.42.0/24 and US Central 24.105.62.0/24.
It’s highly likely this is the ping test for the matchmaker to see what server best suits.
And then? Nothing.
My client never once talks to the SYD2 data center or any instance/‘subnet’ of it ever again, not until actually entering the server when a match pops (The actual loading screen).
Pre-joining PSE1 or LAX1, no packets are sent or recieved over any protocol to test my connection against SYD2 beforehand.
We tried: Entering/exiting queue, creating custom lobby, joining/leaving a group, return to lobby after game end, left game at main menu for over an hour and repeated.
I would love someone to explain to me why tests like WinMTR to see personal connection stabilty are at all relevant to this issue when the game client itself isn’t even testing against the actual data center it intends to connect too? Stable connection or not, it’s irrelevant to where its putting me if it’s using a snapshot from when game first launched and has put me on several SYD2 sessions beforehand?
An interesting fact he also brought up was that when placed on a foreign server, it’s always a full lobby of au/nz people.
This actually suggests the matchmaker is infact working correctly, as it’s finding and grouping people from the same region correctly without issues before match start.
However for whatever reason it’s not starting the match with the group it’s made on SYD2, instead it looks like it’s using whatever else is available.
Further suggesting the fault actually lies with the SYD2 data center itself.