Hello Guardians. Destiny 2 first released on September 6, 2017. It has been 1,840 days since. On that day, we no longer had a latency display in the current game to help diagnose problems with connectivity. Without access to diagnostic tools, we have no insight into why certain functions within the game are acting up. _________________________________________________________ This also negates the purpose of having a player report option for "Bad Connection" if we can't verify where the problem is happening. Here are a few general reasons for connectivity problems in game: 1. A player in the lobby is having internet issues (maintenance from ISP, home congestion, ISP congestion, etc) or device issues. The latency display would typically stand out for this player. 2. You are having internet issues (maintenance from ISP, home congestion, ISP congestion, etc) or device issues. The latency display would typically indicate problems to multiple players. Potential error codes would be raised. 3. Bungie is having internet or server issues. The latency display would typically indicate problems to multiple players. Potential error codes would be raised. You would sometimes see other people from the same match also lose connection if you did. _________________________________________________________ I am proposing and asking for Bungie to bring this back and make a few small changes. 1. Instead of a metered bar sprite, please change to a numerical value or introduce a toggle to flip between sprite and numerical view. 2. For players, the latency would be displayed on the roster panel of the UI. This would show the latency between you and them. 3. With Destiny 2, Bungie introduced their own activity host as a client, so a render of latency to that host could be displayed on screen like with the frame rate display. _________________________________________________________ As all platforms use the Steam UDP relay service, I assume Bungie is using the Steamworks SDK in all platforms too. Within the Steamworks SDK, there are functions such as "EstimatePingTimeBetweenTwoLocations" or "EstimatePingTimeFromLocalHost" , which assumes one of the two locations is the localhost. These make it ridiculously straightforward to calculate ping values. Here is an example from an Unreal Engine port of the Steamworks SDK: [quote]int32 FSteamSocketsPing::GetPingFromHostData(const FString& HostPingStr) const { if (!SteamNetworkingUtils() || HostPingStr.IsEmpty() || !IsUsingP2PRelays()) { UE_LOG(LogNet, Warning, TEXT("SteamSockets: Could not determine ping data as SteamNetworking is unavailable.")); return -1; } // Attempt to serialize the data that we've gotten already. SteamNetworkPingLocation_t HostPingData; if (SteamNetworkingUtils()->ParsePingLocationString(TCHAR_TO_ANSI(*HostPingStr), HostPingData)) { // This should be an extremely quick function, as it compares regional data within the node network // that we got from the host to our own node information. This ping data is mostly just math. int32 PingValue = SteamNetworkingUtils()->EstimatePingTimeFromLocalHost(HostPingData); if (PingValue == -1) { // A value of -1 occurs when there's a critical failure (We don't have our own ping data ready). // However, it's not a fatal error, and we can always request for that data again later. return -1; } return PingValue; } else { // This happens if the string has been tampered with, the protocol has upgraded or just something overall went wrong. UE_LOG(LogNet, Log, TEXT("SteamSockets: Could not parse the host location in order to determine ping.")); return -1; } }[/quote]