The original simulated net params did function in online games, and as such were used to exploit the same flaw timescale changes did: servers would stop simulating a player that stops sending packets. On the client end it was restricted to local listen server connections to mitigate this, though it'd be safe enough to allow it in offline mode in general for testing on dedicated lan servers.
At the time I rewrote the packet delivery logic, the simulated net delay settings were being used for routing through part of the original netcode for testing certain behaviour with both protocols speaking to each other. The round-trip timing is tracked differently on the original code, which is why the ping display breaks down with it being routed, and you also consequently currently only have a delay for packets going in one direction.
Alright I feel silly for saying it wasn't a cheat now even though I suppose I must have suspected it might be a bit sketchy or I wouldn't have mentioned that.
Thanks for the quick reply. Do you care to elaborate on the last sentence please? The delay only going in one direction.
Does it mean, it is no good to practice with offline for the purpose of simulating a higher ping?
For the moment, in the current version you're only applying a delay to packets sent from the client to the listen server. The listen server is still sending you packets every ~32ms regardless, but because listen servers don't communicate with the host over the network, and aren't currently allowing simulating a delay, every server packet is processed by the client instantly. This means for every other object you see moving in a local game, there's zero delay from the server, but... Because the server tries to keep your player object synchronized to moves it receives from you, delaying client input packets can effectively simulate the feel of latency on your own player object: server trigger responses for weapon firing, jetpacks, jumps, etc. will all be visually delayed more or less as expected (but if you were targetting a moving enemy, it may have travelled twice as far as expected before your projectile actually fired on the server).
For testing skiing routes this is probably fine. As you've noticed though using the prefs to apply it, those variables are halved by the host startup script - because the control applies a delay of x milliseconds on any packet sent by a connection object, the script normally tries to apply half the requested delay to the trip back.
If you check the previous page, there was some discussion on the subject to catch up on, but because there are so few people using them, it's taken some time to get crashlogs/information to narrow down what issue MacBook users are having. Currently, I'd been hoping to hear back on the capabilities the Apple OpenGL driver is reporting (specifically most importantly the supported formats and extensions), as mentioned at the end of this post:
Any idea why my ping to all T2 servers whether they are in the US or Europe could have doubled overnight?
I used to ping 100-105 in the T2 browser tab to Chicago servers, 135-145 in game. Now it is 200 with some rubberbanding to boot. I have tested with my old Vanilla non QoL install, exact same issue. Been playing for almost a year and my ping has been rather stable until yesterday.
The most puzzling part is I don't have this problem at all with other games. Just T2 and last week was just fine.
I spent 3 hours on the phone with my ISP help desk, they ran all sorts of tests. I mean I even talked to a guy that sounded competent. I did reset my router twice, plugged, unplugged everything. People at my ISP say my connection is good, debit is good, my wifi is great too and I have tried messing with my DNS. No Luck.
Hmm, well, the game itself fires off raw UDP packets well under the IPv4 MTU, meaning there's no additional overhead or fragmentation of the packets to cause delays or drop packets under modern broadband, and there are no DNS lookups involved in game server connections. Essentially as soon as the packets are created they're out of the game's control, and your OS passes them along to your router/modem.
Barring hitting your bandwidth limits and not having queue priority, or something bizarre like your router's CPU being overloaded, I wouldn't expect anything within your own network to create a delay of more than a few milliseconds.
I'm sure you might know some of this info, but I'll throw it in in case it helps you or others reviewing the latency you might see from the game:
The ping shown in the browser is (when both client and server are patched) is an almost pure measure of the time it takes to send a packet to the server and receive a response. The "almost" being that a server isn't necessarily handling those packets instantly if there's a heavy load, being that the event loop running network processing and gameplay all runs on the same thread. It's the most optimal ping you'll see, though.
The ping shown in the lobby is a recent record of the running average of the time it takes for a gameplay packet sent by the server to reach you, be noted in one of your input move packets and sent back, and finally to be received back by the server. Because the server only sends gameplay packets every 32ms, and the client response time may be slightly delayed if e.g. you have opengl's blocking vsync on (but not to a problematic degree), it's normal for this to be a little higher than the raw ping.
The ping shown in the network options, huds, or with client variables is the running average of the time it takes for an input packet sent by you to reach the server, be noted in a gameplay packet, and arrive back. This also the gameplay tick rate, so will be reasonably close to the server's measurement shown in the lobby, but is usually a little lower.
Are the pings higher to all servers, or just the ones you normally playing on? My suspicion for a sudden increase in latency of that magnitude would be that the it's using a new BGP route to reach some servers, maybe one of the hops the traffic passes through started advertising incorrect info or is terribly inefficient... but the specifics in broader ISP network management in that area aren't my field of expertise. Your ISP could work around this if it were confirmed, but you'd probably have to get a case escalated to someone on their end willing to take the time.
You could try running a traceroute to each of the servers impacted, and ask one of the server hosts to run a traceroute to your IP. Maybe fiddle around with a BGP toolkit or looking glass utility. If anything does point to an obvious problem node, you could note it down to present to your ISP's tech.
Otherwise... you could try seeing if you get similar results while using a VPN, if only to confirm that the routing path is the issue. It'd probably still come in a little higher than your "normal" expected ping, but the packets would take a different path across the net, so you could rule out local issues if it's any lower latency than you're getting now.
Comments
The original simulated net params did function in online games, and as such were used to exploit the same flaw timescale changes did: servers would stop simulating a player that stops sending packets. On the client end it was restricted to local listen server connections to mitigate this, though it'd be safe enough to allow it in offline mode in general for testing on dedicated lan servers.
At the time I rewrote the packet delivery logic, the simulated net delay settings were being used for routing through part of the original netcode for testing certain behaviour with both protocols speaking to each other. The round-trip timing is tracked differently on the original code, which is why the ping display breaks down with it being routed, and you also consequently currently only have a delay for packets going in one direction.
Alright I feel silly for saying it wasn't a cheat now even though I suppose I must have suspected it might be a bit sketchy or I wouldn't have mentioned that.
Thanks for the quick reply. Do you care to elaborate on the last sentence please? The delay only going in one direction.
Does it mean, it is no good to practice with offline for the purpose of simulating a higher ping?
For the moment, in the current version you're only applying a delay to packets sent from the client to the listen server. The listen server is still sending you packets every ~32ms regardless, but because listen servers don't communicate with the host over the network, and aren't currently allowing simulating a delay, every server packet is processed by the client instantly. This means for every other object you see moving in a local game, there's zero delay from the server, but... Because the server tries to keep your player object synchronized to moves it receives from you, delaying client input packets can effectively simulate the feel of latency on your own player object: server trigger responses for weapon firing, jetpacks, jumps, etc. will all be visually delayed more or less as expected (but if you were targetting a moving enemy, it may have travelled twice as far as expected before your projectile actually fired on the server).
For testing skiing routes this is probably fine. As you've noticed though using the prefs to apply it, those variables are halved by the host startup script - because the control applies a delay of x milliseconds on any packet sent by a connection object, the script normally tries to apply half the requested delay to the trip back.
Yes it is for running HO routes. Okay this is pretty clear now, good explanation.
Thanks a lot.
Hi, I'm new here and hoping to get up and running on an M4 Max MacBook Pro. Is there anywhere I can find a guide?
I'm willing to spend some time helping @Krash or anyone else get this up and running if I can.
Thanks in advance!
If you check the previous page, there was some discussion on the subject to catch up on, but because there are so few people using them, it's taken some time to get crashlogs/information to narrow down what issue MacBook users are having. Currently, I'd been hoping to hear back on the capabilities the Apple OpenGL driver is reporting (specifically most importantly the supported formats and extensions), as mentioned at the end of this post:
Any idea why my ping to all T2 servers whether they are in the US or Europe could have doubled overnight?
I used to ping 100-105 in the T2 browser tab to Chicago servers, 135-145 in game. Now it is 200 with some rubberbanding to boot. I have tested with my old Vanilla non QoL install, exact same issue. Been playing for almost a year and my ping has been rather stable until yesterday.
The most puzzling part is I don't have this problem at all with other games. Just T2 and last week was just fine.
I spent 3 hours on the phone with my ISP help desk, they ran all sorts of tests. I mean I even talked to a guy that sounded competent. I did reset my router twice, plugged, unplugged everything. People at my ISP say my connection is good, debit is good, my wifi is great too and I have tried messing with my DNS. No Luck.
HALP.
Hmm, well, the game itself fires off raw UDP packets well under the IPv4 MTU, meaning there's no additional overhead or fragmentation of the packets to cause delays or drop packets under modern broadband, and there are no DNS lookups involved in game server connections. Essentially as soon as the packets are created they're out of the game's control, and your OS passes them along to your router/modem.
Barring hitting your bandwidth limits and not having queue priority, or something bizarre like your router's CPU being overloaded, I wouldn't expect anything within your own network to create a delay of more than a few milliseconds.
I'm sure you might know some of this info, but I'll throw it in in case it helps you or others reviewing the latency you might see from the game:
Are the pings higher to all servers, or just the ones you normally playing on? My suspicion for a sudden increase in latency of that magnitude would be that the it's using a new BGP route to reach some servers, maybe one of the hops the traffic passes through started advertising incorrect info or is terribly inefficient... but the specifics in broader ISP network management in that area aren't my field of expertise. Your ISP could work around this if it were confirmed, but you'd probably have to get a case escalated to someone on their end willing to take the time.
You could try running a traceroute to each of the servers impacted, and ask one of the server hosts to run a traceroute to your IP. Maybe fiddle around with a BGP toolkit or looking glass utility. If anything does point to an obvious problem node, you could note it down to present to your ISP's tech.
Otherwise... you could try seeing if you get similar results while using a VPN, if only to confirm that the routing path is the issue. It'd probably still come in a little higher than your "normal" expected ping, but the packets would take a different path across the net, so you could rule out local issues if it's any lower latency than you're getting now.