Sonic: Denoting or having a speed equal to that of sound.
Ping: The time it takes for a network packet to leave your computer, go to another one, and return.
Crappy wordplay in my part. Essentially, it's a script that allows you to "measure" a player's "latency" made possible by the 'Play Sound' and 'Wait for Sound' functions.
SonicPing's premise
Sound in SC2 does not go in sync with what's happening in the Game World. If say, a Marine dies and emits his death sound, and then suddenly, you lag for a long period of time, the Marine's death animation and everything about that unit pauses EXCEPT for its death sound. It's death sound continues to play smoothly. This pause applies to triggers as well.
SonicPing's Elements and Explanation
There are four elements in this script.
PacketProcessing? is a boolean variable array (15 players) that toggles the measuring process.
PacketAmount is a real variable array (15 players) that relies on the player's responsiveness to add weight to the PacketAmount. Weak response (due to lagginess) and it will have a small weight. Perfect response (no lag) and it will have the ideal weight. (Determined by you through testing this script using a specific sound)
SonicPing for Player (Action Definition)
Set PacketProcessing? = True
Play (5 second sound) for Player at 0% volume and set this sound as 'soundtester' variable.
Start SonicPing Process Action (Requires that PacketProcessing? is true)
Wait until soundtester finishes playing.
Set PacketProcessing? = False (Stops SonicPing Process)
SonicPing Process (Action Definition)
Set PacketAmount = 0.0
While PacketProcessing? = True, wait for 0.1 seconds and add 0.1 to PacketAmount.
Once SonicPing Process is finished, you can use the value it's added up on (PacketAmount) and compare it to the "ideal" or average value.
Certain Tweakables
Sound: You can change the sound used. The sound duration determines your PacketAmount's ideal/average value. The sound's properties, such as if it's a music type, also play a critical role. I have little knowledge on how Sound works, so if anyone could help me make a perfect Sound object, it would be nice!
Packet Amount (Gain): You can change the amount of gain per interval. This has no real effects, depends on how you use this.
Interval: The duration between adding weight to Packet Amount. I'm not sure why a duration less than 0.05 will give a value less than the sound's duration but it seems to be consistent with whatever value it returns. This has an effect on precision. Obviously, by measuring per 1 whole second, it would give vague data.
Test & Results
I recently tested this and sadly, all players have more or less similar values. I guess SC2's synchronization is near perfect (I guess that can be a good thing) and I don't think (as of now) you can pinpoint the player causing the lag. But, I think there's still potential for using SonicPing. Maybe lag compensation? I don't know, but for now, I have no purpose for this other than giving the latency a numerical value.
So I'll be posting the script soon... If anyone has an idea to improve this script or to put it into good use, post it here.
Rollback Post to RevisionRollBack
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Here is the script. I apologize for the month long delay, lol.
Also, in regards to what I wrote in "Tests and Results", it seems to work. I had one guy who was lagging and his PacketAmount was significantly lower than the rest.
No offense, but from my understanding of the way things actually work, the value you would get from this would be absolutely worthless. The value your measuring from my understanding is the clients "speed", as in if they have a very shitty computer... there could possibly be a much larger delay. This doesn't actually indicate net work code speed.
Not to mention that any attempt to adapt a game to adjust to these values would degrade game play further.
I think your right that a shitty computer on a good network will make this number go up. However if you play a game with someone with a shitty computer, they will lag u.
I think your wrong about the lag. I think it would also catch if the network is significantly laggy since sound doesn't seem to sync between players, and u can measure which time in the sound they are at,
I'm not too sure with that. If there was a really bad network lag, the audio will continue to play but not the SonicPing Process, in result, lower PacketAmount values since the audio will end early and the process will fall short from the expected value.
Or is there something I'm missing?
Rollback Post to RevisionRollBack
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat is SonicPing?
Sonic: Denoting or having a speed equal to that of sound.
Ping: The time it takes for a network packet to leave your computer, go to another one, and return.
Crappy wordplay in my part. Essentially, it's a script that allows you to "measure" a player's "latency" made possible by the 'Play Sound' and 'Wait for Sound' functions.
SonicPing's premise
Sound in SC2 does not go in sync with what's happening in the Game World. If say, a Marine dies and emits his death sound, and then suddenly, you lag for a long period of time, the Marine's death animation and everything about that unit pauses EXCEPT for its death sound. It's death sound continues to play smoothly. This pause applies to triggers as well.
SonicPing's Elements and Explanation
There are four elements in this script.
PacketProcessing? is a boolean variable array (15 players) that toggles the measuring process.
PacketAmount is a real variable array (15 players) that relies on the player's responsiveness to add weight to the PacketAmount. Weak response (due to lagginess) and it will have a small weight. Perfect response (no lag) and it will have the ideal weight. (Determined by you through testing this script using a specific sound)
SonicPing for Player (Action Definition)
SonicPing Process (Action Definition)
Once SonicPing Process is finished, you can use the value it's added up on (PacketAmount) and compare it to the "ideal" or average value.
Certain Tweakables
Sound: You can change the sound used. The sound duration determines your PacketAmount's ideal/average value. The sound's properties, such as if it's a music type, also play a critical role. I have little knowledge on how Sound works, so if anyone could help me make a perfect Sound object, it would be nice!
Packet Amount (Gain): You can change the amount of gain per interval. This has no real effects, depends on how you use this.
Interval: The duration between adding weight to Packet Amount. I'm not sure why a duration less than 0.05 will give a value less than the sound's duration but it seems to be consistent with whatever value it returns. This has an effect on precision. Obviously, by measuring per 1 whole second, it would give vague data.
Test & Results
I recently tested this and sadly, all players have more or less similar values. I guess SC2's synchronization is near perfect (I guess that can be a good thing) and I don't think (as of now) you can pinpoint the player causing the lag. But, I think there's still potential for using SonicPing. Maybe lag compensation? I don't know, but for now, I have no purpose for this other than giving the latency a numerical value.
So I'll be posting the script soon... If anyone has an idea to improve this script or to put it into good use, post it here.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHere is the script. I apologize for the month long delay, lol.
Also, in regards to what I wrote in "Tests and Results", it seems to work. I had one guy who was lagging and his PacketAmount was significantly lower than the rest.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
This is good, i will differently have to try it out.
No offense, but from my understanding of the way things actually work, the value you would get from this would be absolutely worthless. The value your measuring from my understanding is the clients "speed", as in if they have a very shitty computer... there could possibly be a much larger delay. This doesn't actually indicate net work code speed.
Not to mention that any attempt to adapt a game to adjust to these values would degrade game play further.
@SouLCarveRR: Go I think your wrong and right.
I think your right that a shitty computer on a good network will make this number go up. However if you play a game with someone with a shitty computer, they will lag u.
I think your wrong about the lag. I think it would also catch if the network is significantly laggy since sound doesn't seem to sync between players, and u can measure which time in the sound they are at,
-
View User Profile
-
View Posts
-
Send Message
Curse Premium@SouLCarveRR: Go
I'm not too sure with that. If there was a really bad network lag, the audio will continue to play but not the SonicPing Process, in result, lower PacketAmount values since the audio will end early and the process will fall short from the expected value.
Or is there something I'm missing?
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.