ID:68847
 
Resolved
Game servers did not send outgoing packets as frequently as they should due to Nagle's algorithm. By default, TCP/IP does not send more outgoing packets until the previous packet has been acknowledged. In newer implementations of TCP/IP, acknowledgement of packets is often delayed by 200ms (2 BYOND ticks) or more. This caused some games to only refresh icons or images every 2-3 ticks instead of once per tick even when lag times were low. This version disables Nagle's algorithm but uses some internal queuing to prevent a bunch of tiny packets from swamping the server's bandwidth. This change significantly improves the performance of every action-oriented game, and games that use pixel movement extensively.
Applies to:Dream Daemon
BYOND Version:440
Operating System:Windows Vista Home Premium
Web Browser:Firefox 3.0.10
Status: Resolved (463)

This issue has been resolved.
Descriptive Problem Summary:
http://www.byond.com/developer/forum/?id=698793
client.screen (and possibly other map related graphics) only update once every few ticks unless a macro command is sent from the client.

Demo:
You can login to it here: byond://67.18.180.178:9999
(you need to be over a network to see the effect)
And download it here if you want: http://www.angelfire.com/hero/straygames/ByondBugs/ ScreenSpeedDemo.zip
And here's the source: http://www.angelfire.com/hero/straygames/ByondBugs/ ScreenSpeedDemo_src.zip

Once you login, press the StartLoop verb; as you can see the number on screen is only updating once every 2 to 3 ticks. If you spam ASDF, which runs the Refresh verb (which does nothing but return), you can see a noticeable speed increase, however it still isn't perfect. If you run the supplied demo locally; the number correctly updates each tick.
After looking into this further, this appears to be some kind of timing issue between the server and client. In your demo I see multiple screen redraw messages arriving during the same tick. Forcing a redraw doesn't improve the problem since the messages are coming in at the same time.

I'm not sure to what extent this is avoidable over a network, since latency times in excess of 100ms are hardly uncommon.
I'm "bumping" this due to recent discussion on the matter in the developer forums. The observation that sent commands can improve drawing speed indicates that it is not a latency issue but rather an intentional (and incorrect) delay in the interaction. We'll need to investigate further.
I didn't really see how this could be network delay in the first place (at least not to the full extent), seeing as how spamming macros would properly increase the refresh rate, and if it was network lag you wouldn't have the proper information to update with.
But I don't really know what I'm talking about so I wasn't gonna argue =P