client.ping

Page: 1 2
Jul 15 2015, 11:40 am
In response to Airjoe
Airjoe wrote:
2) You can automatically kick players with high ping.

That sounds like the stupidest game design choice ever, just saying.

As far as legitimate uses, it would be somewhat useful for the player to know their ping, but also for devs for testing and debugging purposes.
Jul 15 2015, 12:08 pm
I don't want to get into a big debate on a feature request, but it's not a stupid game design choice. Players with high pings can ruin the game for other players. Sometimes they appear to fly around the map which doesn't work well in action games, or in co-op games, they can slow things down for everything else. At the very least, even if you don't kick high ping players, you can alert them to the fact that their game experience may be diminished because of their connection. Otherwise they might just think you have a shitty game.
Jul 15 2015, 12:17 pm
In response to Airjoe
Airjoe wrote:
1) Matchmaking servers could determine the best server to place you on.

I don't see how that would work at all. If you're already connected to the server, it's too late to run a matchmaking process. We're talking about the server determining the ping time for an already-connected client.

2) You can automatically kick players with high ping.

While I agree with Kats that this isn't a legitimate use, I do think you have a point that having the information and being able to tell players about it could potentially be valuable.

All things being equal though, I think it'd be difficult to make good use of this feature, as it requires a little finesse. You'd more likely see people making bad use of it, kicking the high-latency players. Meanwhile the implementation of this would require the proc to sleep and reawaken later, so there are a few pieces to put into place. I don't much love it for that reason alone. Seems like a very high work/reward ratio.
Jul 15 2015, 12:40 pm
In response to Lummox JR
Lummox JR wrote:
I don't see how that would work at all. If you're already connected to the server, it's too late to run a matchmaking process. We're talking about the server determining the ping time for an already-connected client.

That's true and I guess I wasn't thinking of it in that regard. I believe Feval used to have a BYOND world that you joined before you joined the actual game- it was a place for joining other servers. I had thought about doing this for some of my own games, and I believe SuperAntx had as well, just for a few anecdotal points.

Given that structure, then the "launch pad" server could use Export/Topic with the actual game servers to determine the client's ping time to them- but you're right, since the client is not connected to the destination servers, this wouldn't work as requested. You would need the ability for a client to ping an arbitrary address (i.e, the launch pad would have the client ping the available destination servers). While I don't see the harm in that, I understand it's not something you'd want to touch (inb4 someone starts whining about DoS or something) and it is more complex than what was originally requested here.
Jul 15 2015, 12:43 pm
In response to Airjoe
Airjoe wrote:
Given that structure, then the "launch pad" server could use Export/Topic with the actual game servers to determine the client's ping time to them- but you're right, since the client is not connected to the destination servers, this wouldn't work as requested. You would need the ability for a client to ping an arbitrary address (i.e, the launch pad would have the client ping the available destination servers). While I don't see the harm in that, I understand it's not something you'd want to touch (inb4 someone starts whining about DoS or something) and it is more complex than what was originally requested here.

Actually this makes me wonder if the "launch pad" wasn't a hosted server but was run client side, you could probably get a rudimentary ping going just between the client using Export and Topic alone, checking time when the request is sent and when the response is received, but I'm not sure what kind of accuracy and precision that would yield with the overhead involved.
Jul 15 2015, 1:02 pm (Edited on Dec 27 2016, 11:58 pm)
This is something that could easily be implemented as a variable. The implementation should happen on the client-side, not on the server.

http://files.byondhome.com/Ter13/Ping_src.zip

This is a basic implementation of a client-side pinging approach that uses Javascript and Topic() to manage the brunt of the work.

It's fairly accurate compared to the built-in .ping command.

Interestingly, the ping is exposed to the client as a variable. If I can do it on the front-end, I don't understand the claim that it'll be a pain in the ass on the back-end.
Jul 15 2015, 1:03 pm
In response to Airjoe
Airjoe wrote:
Export/Topic with the actual game servers to determine the client's ping time to them-

You'd be right in assuming this if Export()/Topic() between worlds didn't have a minimum latency of between 200ms and 500ms. This was never fixed.

Jul 15 2015, 1:23 pm
In response to Ter13
As a variable it'd require polling, or at least something updating the ping info frequently so the var had up-to-date information. (I hugely dislike the idea of pinging, say, every second for the sake of polling.) Presumably a ping wouldn't need to be done that often, so a proc makes more sense. But a proc would have to sleep, which is why it's really a pain, because then I'd have to setup the return routines and all that.

I like your client-based solution better because it's a pretty clean implementation.

The export delay, insofar as the reply is not being handled on the same tick when feasible, is on my to-do list because I think solving that would have some big benefits for all kinds of games.
Jul 15 2015, 1:26 pm
I like your client-based solution better because it's a pretty clean implementation.

D'awww. You sure know how to treat a girl during an argument, Lum. Anyway, back to the fighting:

Dec 27 2016, 7:42 pm
++
Dec 27 2016, 9:34 pm
honestly, byond should just track latency of all commands it sends out that it knows the client has to respond to, then keep some kind of rolling avg accessible as a var.

Latency info does not have to come from ping/pong, you can infer it from the already existing traffic.
Dec 27 2016, 9:35 pm
I think Lummox should dig these really old Feature Requests (this one is from 2010)... There is gold here.
Dec 27 2016, 11:45 pm
In response to MrStonedOne
MrStonedOne wrote:
honestly, byond should just track latency of all commands it sends out that it knows the client has to respond to, then keep some kind of rolling avg accessible as a var.

Latency info does not have to come from ping/pong, you can infer it from the already existing traffic.

http://www.byond.com/forum/?post=2142520
Dec 28 2016, 12:07 am
Also, to replace my earlier implementation of a simple ping command implemented in DM:

client
    var
        ping = 0
        ping_id = 0
    verb
        ping(time as num)
            set instant = 1
            set hidden = 1
            set waitfor = 0
            ping = (world.time+world.tick_lag*world.tick_usage/100)-time
            var/lping = (ping_id+1)%10000000
            ping_id = lping
            sleep(1)
            if(ping_id==lping)
                winset(src,null,"command=ping+[world.time+world.tick_lag*world.tick_usage/100]")


Just call this function on client/New(), and it will self-maintain the client's ping. No need for javascript.
Dec 28 2016, 12:18 am
In response to Ter13
U da real MVP
Dec 28 2016, 12:20 am
In response to NSBR
NSBR wrote:
U da real MVP

Actually, those would be Lummox and MrStonedOne. world.tick_usage was their baby. The above snippet wouldn't exist at all if it weren't for Lummox's efforts to improve the language, and MrStonedOne's tireless efforts to break BYOND come up with smart features to make BYOND better for all of us.
Dec 28 2016, 1:03 am
actually, it was somebody at goon station who had the idea, and somebody at vg station made the feature request tick_usage. http://www.byond.com/forum/?post=1904435

I just rolled with it for /tg/station once i saw what it could do after goonstation posted a video about it.

(but the ms from tick_usage idea was all me)
Dec 28 2016, 2:20 am (Edited on Dec 28 2016, 2:33 am)
hidden client verbs didn't seem to work, byond refused to accept the verb existed.

hidden mob verbs worked, so either byond is doing something odd, or our admin verb code (that does some shit to the client verb list) is fucking things up. (if I had to guess, it's the latter causing the former)

I instead just made it a . client verb.

https://github.com/tgstation/tgstation/pull/22531
Dec 28 2016, 12:59 pm
In response to MrStonedOne
It actually seems to be a byond bug. Created bug report http://www.byond.com/forum/?post=2192937
Page: 1 2