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.
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.