[CF-Devel] S2C map head information and map data caching

[Mark Wedel]

 Trustworthyness is a tricky issue.  There is some level of exposure of data
that the client maybe should not really know, but letting the client know it
doesn't expose much risk.

 That said, for the fog of war code, the server will send the client a message
that the player is on a new map.  The code isn't done yet, so I'm not sure how
it will handle tiled maps (from my mail with him, it seemed like for fog of war
code will treat the tiled maps as one large map, which IMO is the right thing to
do).

 It seems to me that the automap code use that same code.  I don't see any
reason why the automap code needs to know the actual map size the character is
on (aside from that being meaningless for tiled maps, it seems that information
is only useful if you know the precise location the character is on that map). 
Otherwise, it seems the automap can track what it sees, center as appropriate,
and scale as appropriate.

 Its a matter of debate how bit an issue know map size is.  I will maintain that
knowing the precise location the character is on relative to the map size is a
pretty big giveway.  This could make some maps much easier (those with linked
teleporters for example).  Would give may more clues to where secret areas may
be, etc.

 I'm unclear on what you are talking about when you refer to floor caching.

 The server already only sends floors that have changed.  This, if you are doing
combat, the floors will not be resent that the combat is occurring on.  This is
for the area that is viewable to the client (whatever mapsize the client sent to
the server).

 If instead you are referring to something like the player moves right 5 spaces,
but the client remembers that 5 spaces at the left that are now scrolled off,
such that if the player now moves to the left, the server doesn't send the
floors again, this gets tricky for the following reasons:

1) How does the server know what the client has cached, and thus what it doesn't
need to resend (maybe the client doesn't cache any floors out of sight.  You
could also get a case where the client remembers several maps of data (for
example, if in a dungeon, you might want to remember the previous levels).  

2) Given the case described yesterday, where he floor changes.  The server knows
the floor 5 spaces to the left of the clients viewable area has changed.  But
recording that fact gets tricky - the server just can't say that floor is now
different, because suppose you have a second player also on that map who is a
space left of the other player.  He moves back, server sees that floor is
different, sends to that player.  You now get a case where you always resend
that floor for every client where it reappears into view, even if it hasn't
changed (because you can't clear that fact because maybe the player to the
further right hasn't seen it yet).  Any attempt to clear this so the redundant
floor doesn't get displayed again requires having per client information for
what floors has changed, which means you basically have to have per client
information for the entire map size.

 I personally don't consider this a very big issue.  Worst case is that there
are 98 bytes send for floors (this presumes playing with 25x25 map size, and
moving diagonally, and all the spaces are in view).  For combat, this is trivial
compared to the potential for the spells (that 10x10 spell affect is 200 bytes
at least, and probably 400 if it obscures objects below it).  And a 10x10 effect
actually gets pretty small if your playing on a 25x25 map (which has 625
spaces).

 All in all, if we're concerned about bandwidth, I think there are other places
to look than trying to cache floors that are now out of sight.  Especially since
not all clients will do that anyways.