Run as Client

Page: 1 2
ID:132900
 
Aug 12 2009, 12:26 pm
A new Build -> "Run as Client" option that would setup an invisible server, and then connect you to it. The invisible server would close along with the seeker you were logged in to.
This is of course do-able already, but requires several extra steps, and if you're continually trying to test things that can get annoying/tedious/time consuming.
The reason I request this is because you can notice a major "lag" difference in game play from a client's perspective, even if its over a local connection.
Aug 12 2009, 12:56 pm
Falacy wrote:
A new Build -> "Run as Client" option that would setup an invisible server, and then connect you to it. The invisible server would close along with the seeker you were logged in to.
This is of course do-able already, but requires several extra steps, and if you're continually trying to test things that can get annoying/tedious/time consuming.
The reason I request this is because you can notice a major "lag" difference in game play from a client's perspective, even if its over a local connection.

I've never noticed any lag on any sort of localhost or lan connection. :/
Aug 12 2009, 1:00 pm
In response to AJX
AJX wrote:
I've never noticed any lag on any sort of localhost or lan connection. :/

Madness! Its blatantly noticeable with any type of frequently updating HUD.
Aug 12 2009, 1:05 pm
In response to Falacy
Frequently updating the HUD always causes a significant amount of delay due to the way client.screen works.
Aug 12 2009, 1:06 pm
In response to Popisfizzy
Popisfizzy wrote:
Frequently updating the HUD always causes a significant amount of delay due to the way client.screen works.

I know, Lummox said he can't fix it =[
Its not noticeable if you're playing in the seeker that's actually "hosting" the game though.
Aug 12 2009, 1:33 pm
Falacy wrote:
The reason I request this is because you can notice a major "lag" difference in game play from a client's perspective, even if its over a local connection.

Hmm, that's pretty interesting. Normally I'd attribute a client.screen lag that appears in remote games as a result of the networking, but if you are seeing it in the client -> local server situation, that is something different. One difference between the client-server and client->local server is the way resources are cached, although it would be surprising if that were the issue.

Are you seeing the lag problem only with the HUD, or with all updates? Do you have a demo or previous post that illustrates this in more detail? In [link] you do mention lag quite a bit, but as I read it there you were talking about games running fine locally (either client-server or client->local server) but not remotely. That is a different issue that is not as easy to fix (some comments in that thread-- the gist of it being that we probably have to multithread to get more out of the cpus). What you are saying here should be fixable if it is indeed happening consistently.
Aug 12 2009, 1:39 pm
In response to Tom
http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=122
That illustrates the HUD issue pretty well. Its also much more noticeable if you're hosting it through seeker than if you're hosting through daemon.

EDITS:
Tom wrote:
Are you seeing the lag problem only with the HUD, or with all updates?

What do you mean "all updates"?
And it may also be worth nothing that the world.cpu is reporting a steady 0-1% usage.
Aug 12 2009, 1:59 pm
In response to Falacy
Falacy wrote:
http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=122
That illustrates the HUD issue pretty well. Its also much more noticeable if you're hosting it through seeker than if you're hosting through daemon.

OK. The main bug report here is referring to remote network lag, correct? But you are saying that the problem is happening locally as well? That is, if you host this game in DD and then connect to it from the same machine in DS, you are getting different results than if you just host/play in DS?

EDITS:
Tom wrote:
Are you seeing the lag problem only with the HUD, or with all updates?

What do you mean "all updates"?
And it may also be worth nothing that the world.cpu is reporting a steady 0-1% usage.

I'm just wondering if the problem is only with client.screen or with everything, like map updates / movement. I'm specifically talking about the difference between hosting in DD vs DS, but connecting locally.
Aug 12 2009, 2:12 pm
In response to Tom
Tom wrote:
OK. The main bug report here is referring to remote network lag, correct? But you are saying that the problem is happening locally as well? That is, if you host this game in DD and then connect to it from the same machine in DS, you are getting different results than if you just host/play in DS?

That bug report was made about over-network lag yes. But it apparently applies to local connections as well (as I just found out before posting this topic (mostly by accident)).
And though it is still slightly noticeable when hosting with DD, its far more noticeable if you host with DS, and then connect to that DS with another DS.

I'm just wondering if the problem is only with client.screen or with everything, like map updates / movement. I'm specifically talking about the difference between hosting in DD vs DS, but connecting locally.

It did seem like all commands were slightly slower, but nothing as blatant as the HUD. I'll run some tests later.
Aug 12 2009, 2:15 pm
In response to Falacy
Falacy wrote:
That bug report was made about over-network lag yes. But it apparently applies to local connections as well (as I just found out before posting this topic).
And though it is still slightly noticeable when hosting with DD, its far more noticeable if you host with DS, and then connect to that with another DS.

Ok, thanks for the update. I bumped your old report out of "deferred" since this isn't a latency issue. We'll take a look. Possibly you're onto something that could resolve a lot of lag issues.
Aug 12 2009, 2:42 pm (Edited on Aug 12 2009, 2:51 pm)
In response to Tom
Tom wrote:
I'm just wondering if the problem is only with client.screen or with everything, like map updates / movement. I'm specifically talking about the difference between hosting in DD vs DS, but connecting locally.

There seems to be definite map lag. When flying around (movement for which runs off of an internal loop, not actual commands) I get that old "bug" where you would go back into your hover state every once in a while. This does not happen at all when playing directly through the host seeker. The map also seems to move slower/jumpier overall.

Doing this:
var/Number
mob/verb/LabelUpdate()
    while(usr)
        Number+=1
        winset(usr,"label1","text=[Number]")
        sleep(1)

Shows the same problem the HUD demo does, except through the interface.

As for the input of actual commands, its hard to tell really. The 1-3 tick slowdown is hard to notice, if its even there. And I can't think up a competent test to try for it.
Aug 12 2009, 3:06 pm
In response to Falacy
Falacy wrote:
As for the input of actual commands, its hard to tell really. The 1-3 tick slowdown is hard to notice, if its even there. And I can't think up a competent test to try for it.

Best I could come up with:
var/ComInpt
mob/verb/CommandInput()
    if(ComInpt)
        usr<<"<b>[world.timeofday-ComInpt]"
        ComInpt=0
    else
        ComInpt=world.timeofday
        //usr<<"Click the button again quickly to test responce time"

Seems to present no delay on inputs.
Aug 12 2009, 3:08 pm
I made another icon which would make the lag much more noticable.

I wasn't able to reproduce the bug locally, but when connecting to my external IP the icon would only update every other tick. About every 18 seconds (18 complete loops of the animation) it would also skip a tick, so the animation would switch to the odd frames you were previously not seeing.

Manually spamming Refresh() would cause the animation to play in full.
Aug 12 2009, 3:30 pm
In response to SuperAntx
SuperAntx wrote:
I wasn't able to reproduce the bug locally...

Were you hosting through daemon or seeker? The issue seems it may only be present locally when hosting through seeker.
Aug 12 2009, 3:36 pm
In response to Falacy
I tested it with Dream Seeker, though Dream Daemon showed the exact same results. The bug only appeared when connecting to my external IP.
Aug 12 2009, 4:12 pm (Edited on Aug 12 2009, 5:23 pm)
In response to SuperAntx
SuperAntx wrote:
The bug only appeared when connecting to my external IP.

*EDITED*
Yes, the bug only seems to occur if you connect to the world via an actual IP:PORT, if you do that (in my case 166.82.8.247:4449) even daemon hosting will display the lag.
Clicking the little join button on daemon, and/or connecting by loop back address/local IP seems to avoid the bug.

EDIT:
Removing the router from the equation also seems to resolve the issue.

EDIT 2:
So, based on this revelation, thanks to some super antics by SuperAntx, it seems like BYOND is forcing some sort of delay on itself when it *thinks* its connected to a network. Even though that delay serves no real purpose (besides presenting false lag) especially considering it can be nullified by spamming.
If this fixes what I think it will; it may even allow for actual pixel movement games =o But again, I don't really know what I'm talking about =P
Aug 12 2009, 9:04 pm
In response to Falacy
You have to consider that when you connect to your outer IP, you are in fact going out of your router and then back in, as if you had been connecting to somewhere else. As such, you suffer some network delay there, and this has nothing to do with BYOND.

In order to test local to the computer, you must use 127.0.0.1 (localhost). In order to test local to the network (LAN), you must use the internal IP the router has assigned to you.
Aug 12 2009, 10:41 pm
In response to Tom
Tom wrote:
I'm just wondering if the problem is only with client.screen or with everything, like map updates / movement. I'm specifically talking about the difference between hosting in DD vs DS, but connecting locally.

I did some testing with this, and basically my conclusion is this:

If you connect locally, through either localhost or your LAN IP, it will act without delay. If you connect using your external IP, it will have the same 2 frame delay minimum as there is with outside games, but as previously mentioned in one of the bug reports if you do any kind of input it will cut that down to 1 tick.

These results were the same for me whether hosting in DS or DD.

Below is a short clip of my test results.

Short summary of what exactly you're seeing there:
The window on the left: Host
Middle window: Connected through localhost
Right window: Connected through external IP

The left number on map is a single icon state that cycles from 0-9 and is being flicked
The right number on map is 10 separate icon states being set each tick

The label timer and grid timers are being set at the same time as the timer on map. (The grid timer always had a 2 second gap, and I haven't really figured out a way for this not to happen. Inputting commands sometimes changes if it bounces on odd or even numbers, but RARELY a 1 tick gap)

The input latency test is simply a clone of Falacy's verb listed in this thread. For anyone, regardless of connection method, the latency test will stay at 0.1 and bounce to 0.2 occassionally.

http://www.byond.com/members/AJX/files/clip0001.avi

Aug 13 2009, 5:19 am (Edited on Aug 13 2009, 5:28 am)
In response to Alathon
Alathon wrote:
You have to consider that when you connect to your outer IP, you are in fact going out of your router and then back in, as if you had been connecting to somewhere else. As such, you suffer some network delay there, and this has nothing to do with BYOND.

I'm gonna have to say that's wrong in just about every aspect, but I'm no networking guru. However, I can pretty much guarantee this has everything to do with BYOND.
Aug 13 2009, 7:35 am
In response to Falacy
Falacy wrote:
I'm gonna have to say that's wrong in just about every aspect, but I'm no networking guru. However, I can pretty much guarantee this has everything to do with BYOND.

I don't understand why you consistently reply when you (admittedly!) have no idea what you're talking about. Alathon is 100% correct. By joining to your external IP, you are leaving your local subnet and coming back in.
Page: 1 2