ID:154042
 
Well, I was goofing around with various ways to customize games based on the user's computer settings. Such as setting view based on resolution (640x480 = 3, 800x600 = 6, 1024x768 = 9, these will max out the map size for that resolution). I came up with an idea to get the user's modem type, save it to a modem_type variable, seperate the high and low end modems, then modify the tick_lag variable accordingly. This would help to balance action games out, so that all persons get a more even playing field, as far as lag delays and such. My basics thoughts on how to code this, is simply 2 variables, highspeed_modem, lowspeed_modem, then when a player logs in or out, it will check their modem, and one (or subtract one, for logging out) to the proper variable. I couldn't come up with a decent formula for uh... formulating this. But, basically, you figure that if there are more low end modems, the tick_lag will be higher (to a cap of 6-8, or so), if there are significant amounts of either, it will hit the average of 3, which is the normal ping for most 56k modems (0.33 seconds). Thoughts?


Polatrite
Sounds wierd...maybe it should go in General?
I'd probably do this:

H = highest speed modem
A = average modem speed
tick_lag = round((H-A)/1000)

Aye?

-LoW
In response to Lord of Water
Yeah LoW's idea looks good too me.
In response to Akarat
ok..maybe I'm not keeping up with DM feature-creep lately: how do you determine what the user is using for a connection? Is there a DM function that see's what they are connected with (similar to Javascript browser detection, maybe)?

If there is no such animal, a simple bandwitdh-over-time test at the start of a game (say first 5 seconds) could give you a clue about the connection speed of the player, then you set your lag accordingly...
In response to digitalmouse
I believe he was requesting a connection detection var.
Interesting that an idea that would increase lag for half the players and not change it for the other half is put forth as a lag reduction thought. :)
I too have been searching for a way to even the playing field for different connections. Actually, it's more of a problem of a big advantage to the host, if they play on the same machine as is doing the hosting.

Currently, there doesn't seem to be a way to programmatically determine how much lag there is between client and server. There needs to either be a client.time variable so the client can tell the server how much time it thinks has passed, or a client.ping() proc, so the server can offset timings based on a delay. I wouldn't mind seeing both put in, though client.time is more valuable to me at the moment.
sounds cool, too bad i got lost around the first few setences though
In response to Lesbian Assassin
Maybe "Interesting Lag Balancing Thought" is better.
In response to Skysaw
Skysaw wrote:
Currently, there doesn't seem to be a way to
programmatically determine how much lag there is between
client and server.

While I do agree with the need for something like a client.ping(IP) proc, you could fake it with this trick (I did it a old VB program many moons ago):

Play 'throw-catch-return' with a client. Start a timer, then send a special one-to-four byte packet to the client who is instructed to immediately return that packet back to the server, no matter when asked. Record the round trip time. If you do this 4-5 times a second, and collect a couple of seconds of timings (maybe at login), you can figure out what the client's bandwidth capabilities (roughly) are, and can adjust your game accordingly.

I guess you can also set up a verb in the GM screen that allows that person to initiate the 'throw-catch-return' to all the clients anytime they see lag getting bad - this finds the low speed guy from all the players connected. Or you can automate the process (once a minute or so)...

In response to digitalmouse
digitalmouse wrote:
Skysaw wrote:
Currently, there doesn't seem to be a way to
programmatically determine how much lag there is between
client and server.

While I do agree with the need for something like a client.ping(IP) proc, you could fake it with this trick (I did it a old VB program many moons ago):

Play 'throw-catch-return' with a client. Start a timer, then send a special one-to-four byte packet to the client who is instructed to immediately return that packet back to the server, no matter when asked. Record the round trip time. If you do this 4-5 times a second, and collect a couple of seconds of timings (maybe at login), you can figure out what the client's bandwidth capabilities (roughly) are, and can adjust your game accordingly.

I guess you can also set up a verb in the GM screen that allows that person to initiate the 'throw-catch-return' to all the clients anytime they see lag getting bad - this finds the low speed guy from all the players connected. Or you can automate the process (once a minute or so)...

This is more or less what I'd like to do, thanks for the suggestion.

Now, how do I ensure that the information is actually being passed to the client, and not being processed solely on the server? I could perhaps check the value of client.address a few times, but I don't know if it may be cached on the server after the first time.
In response to digitalmouse
Did a little looking around. There doesn't seem to be a way to play "catch and return" with BYOND. I believe everything is processed on the server. Deadron made a request back in February regarding this, but nothing has come of it.
In response to Skysaw
Skysaw wrote:
There doesn't seem to be a way to play "catch and return"
with BYOND.

Look into the stuff related to client-server communications - I think Deadron's own material on the subject should give some clues...

Unfortunately, I don't know enough about DM to be of more help at the moment...

In response to digitalmouse
digitalmouse wrote:
Skysaw wrote:
There doesn't seem to be a way to play "catch and return"
with BYOND.

Look into the stuff related to client-server communications - I think Deadron's own material on the subject should give some clues...

Unfortunately, I don't know enough about DM to be of more help at the moment...

Don't think it's there. Deadron's request page on this topic on ByondBwicki has had no activity since February.
In response to Skysaw
How about:

http://www.byond.com/hub/ hub.cgi?qd=hubIndex;hub=190;channel=1182

that's the client-server library... bound to be some useful tidbits in there...
In response to digitalmouse
In fact, Sky, (now that I actually looked at the ClientServer code) I think it should be able to do exactly what we were just was talking about... but instead of 'SubmitPhrase()' to the server, you would do it to the client... throw a timer in there, put it all inside a loop (for a few iterations), and *presto* !
In response to digitalmouse
digitalmouse wrote:
In fact, Sky, (now that I actually looked at the ClientServer code) I think it should be able to do exactly what we were just was talking about... but instead of 'SubmitPhrase()' to the server, you would do it to the client... throw a timer in there, put it all inside a loop (for a few iterations), and *presto* !

Hmm... now that I look at it, I disagree. But I honestly hope you can prove me wrong, and show me code that would do it.

Deadron's library let's a someone running an instance of DS to communicate with an external server. I have similar code myself (working up a generic high score server). But it does not seem to address a client that has joined a game run by someone else in DS. As far as I know, you cannot use world.Export() to get a response from another instance of DS.
In response to digitalmouse
Actually that does server to server. That library.
It's a good idea, I like the overly thought... hmmm now to find a way for the server and client to communicate a ping time and manipulate it to even out... it's a good idea, however you know there are some Cable users who think they should be the best cuz they can ping in like... .0000001 Seconds.... *shrugs*... But getting a Cable user who has a modem FASTER than 5.6k/sec (average speed) to slow down and wait until it matches up. You said that average 56k ping is .33 seconds right? Well, if you can get 6 or 7 computers to ping and see their time, average, and then form a wait command based on that ping time

Ok... now we got the slow computer ping, now a fast computer ping, average is, and if their computer registers faster than say 15k/sec (which no dial could possibly make)
make them wait .33 seconds instead of the usual ping time they have. It'd take work and how to communicate a modem info from a client is beyond me. So you'd have to get someone else with that knowledge besides me.

Ronn

"I've lost more than my fiance, I've lost my soul"
Page: 1 2