I presume the 1000x1000 maps are 50 (or some other size) spaces/side? Or is each map 1000x1000, but you have some smaller set of maps being tiled together?

With map tiling, things can move to adjacent maps even if players don't move to them. The game doesn't really distinguish between objects, and just as you wouldn't want an arrow to stop at a map edge, same goes true for monsters.

What should eventually happen is that maps with no players on them will get swapped out. However, what probably also happens is that maps that are still in memory are touching the other maps, keeping them active, so this never happens (at least in the case of mice which keep multiplying). One could have a monster that just wanders and moves to a new map, but it would eventually get swapped out if nothing else is keeping the map it is on active.

As far as compression goes, at one time, the server did support map (or really, all file) compression. However, the typical size of an entire installation was small enough on current hard drives, there really wasn't much point to it (even 100 GB isn't that big for modern systems). Also, some newer filesystems (ZFS for example) support compression, eg:

NAME                    USED  RATIO
export/home/crossfire  18.0G  2.09x

(that is all my crossfire stuff - sources, binaries, etc, so size is reduced by 50+%)

Also, I'm not aware (though may have missed it) of client side map caching. But even if that did exist, at least as far as the protocol goes, transmission of map data is much more efficient in the protocol that the method used in the map client itself. In the protocol, its probably around 6 bytes/map object (with some additional overhead to note the space, darkness, and a few other attributes). Where as in the map file, a pretty minimal object is something like:

name grass
x 5
y 5

 Which is going to be 20 bytes.

crossfire mailing list

Reply via email to