ID:1500081
 
Resolved
When turf appearances updated, they caused an entire map refresh for anyone in view, which was slow and used more bandwidth. Newer servers will send more streamlined updates to new clients, which can result in large improvements in cases where turfs are changed frequently.
Applies to:Dream Daemon
Status: Resolved (505.1233)

This issue has been resolved.
Changing turf appearances shouldn't cause the whole map to refresh.
Lummox JR resolved issue with message:
When turf appearances updated, they caused an entire map refresh for anyone in view, which was slow and used more bandwidth. Newer servers will send more streamlined updates to new clients, which can result in large improvements in cases where turfs are changed frequently.
Wow, thanks Lummox. This is the kind of stuff BYOND really needs imo.
For the sake of satisfying those of us who like to have an understanding of how things are handled internally a bit better, care to explain this upgrade a bit more thoroughly?

In our conversation earlier in the month I recall you saying that each update to turfs would either require a new message, or a more streamlined approach in general.

You also mentioned that clients would constantly poll for object and turf appearance changes in their vicinity. Is this still the case, or are you now using a more event oriented approach to package updates to concerned clients after each tick in which a change occurs?
In response to Ter13
Ter13 wrote:
In our conversation earlier in the month I recall you saying that each update to turfs would either require a new message, or a more streamlined approach in general.

That's correct. There is a new message in play, which is why this new setup requires both the server and client to be on 505+. The server will send updates the old way for anyone on an older client. The introduction of new messages almost always requires a major version bump.

You also mentioned that clients would constantly poll for object and turf appearance changes in their vicinity. Is this still the case, or are you now using a more event oriented approach to package updates to concerned clients after each tick in which a change occurs?

Here's the way map updates usually go:

1) If the player's position or view distance has changed, or a flag indicates their map has cleared, a turf map message is be sent. (There are actually a couple messages, but one routine handles them.) The turf map sending routine basically tries to figure out which turfs are new to the player--all of them, if there's been a full refresh--and sends those in a compressed format.

2) If the turf map routine indicates it sent out something, an area message is sent for those turfs as well. (I did some streamlining on the loop in the turf routine a while back, but did not streamline the area routine the same way. It's a place for future minor improvement but I don't think it's a major bottleneck.)

3) Even if turfs and areas were not sent, objs and mobs in view are checked for any changes: Appearance, pixel offsets (which for movables get handled separately for performance), step offsets, creation/destruction, etc. This is more of a polling kind of thing, because it has to look at anything in view. If there are no changes and the turf map message was not sent, nothing needs to be sent to the client.

In the 504 series of betas I made some tweaks along the way to the turf map routine, allowing it to avoid some unnecessary lookups (such as of animation) when the turf was more or less in "vanilla" mode: no contents, no animations, nothing much interesting on it. I likewise improved the obj/mob polling routines the same way, so turfs with nothing interesting on them weren't checked for contents.

This latest update impacts turf refreshes only. In the past, changing a turf's Appearance caused it to signal all clients in view to fully refresh their map. Now, operating on the assumption that turf changes are still relatively infrequent (e.g., maybe only a few will change in view on any given tick), instead it just makes a list of which turfs changed--if it's dealing with a new client that can handle the new message, of course. If any of these changes are found, the server sends out a new message with the list of changed turfs, and info on their Appearances and areas.

I ran some tests in a scenario where several turfs in view were changed every tick. In this case I ended up with an astonishing 60% improvement just in the time it took to process the map update. This is obviously about a best-case improvement, but games that do frequent turf updates should see a boost.
^Thank you for the excellent write up. That definitely gives those of us with a more in-depth understanding of how things work a good insight, as well as offers a very compelling justification to those with less understanding why this update was a good thing.

Amazing work as always, Lummox.
Absolutely fantastic. I can think of a few systems some games use that this could help out with quite a bit, and it's a good improvement regardless; so excellent work. It was interesting and informative reading that write up, too, so thank you for taking the time to do that.