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

[Mark Wedel]

Michael Toennies wrote:

>
     
      Well, at the moment the client knows nothing about the current map the
     
     >
     
      player is in.
     
     >
     
      Not the size, not the name, etc.
     
     
 This sort of goes back to a non trustworthy client.  If we presume we can't
trust the client, then sending this may violate that principal, but seen notes
further down.


>
     
      Also, i want show the name where we are (if player should not know it, make
     
     >
     
      it unknown).
     
     
 Note that currently the vast majority of maps have no meaningful name. 
Currently, the user can also the the 'mapinfo' command that returns the current
map name.  So including name isn't a big deal.

 I know Scott MacFiggen is working on fog of war code (spaces on the map that
are no longer in view show a greyed out version of what was last seen there). 
As part of those changes, I believe he is needing to modify the server so that
it tells the client when it changes map.  Presumably, it wouldn't be too hard to
extend that to also include a map name.

 xlen and ylen from the map are pretty meaningless, as well a violation of the
trustworthy principals.  But more relevant, such a scheme does not work at all
with map tiling (or if it does, does not give results as you want them).

 I personally would wait to see what Scott's code does.  Presumably if that can
get along without know the map coordinates, so could your autotiling code, as
most all the issues should be the same.


>
     
      This give us a REAL new point: If the server also knows that the client
     
     >
     
      stores the floor layer data,
     
     >
     
      the server can use dirty flags too! So, he don't must send a unchanged floor
     
     >
     
      tile twice for a map!
     
     >
     
      This will shrink the map cmd for nothing...!
     
     
 This gets more complicated because floors can change.  godfloors is the
immediate case I can think of, there are probably others.

  Note that the current use of dirty tags I put in with tiling is marking a
space of being dirty with regard to how the server thinks it should look.

 While presuming the floor will not change 95% of the time and your caching
system would work in that case, its that 5% that are critical - if the client
doesn't display it properly to the player, it could make some maps pretty
unusable, as the player does not realize that the space has changed.  Any method
of making sure this gets updated gets pretty complicated pretty quickly (server
now needs to store a list in the client of spaces out of view whose floors has
changed, or when the floor changes tell the client that space has changed, which
IMO is a very serious violation of trustiness, as player now instantly know he
did something that changed the status elsewhere on the map that may not be
directly visible).


>
     
     
     >
     
      Ambient sound should be clear - background sound the client plays at
     
     >
     
      random - like dropping water
     
     >
     
      for a dungeon, bird noices in a wood, etc.
     
     
 IMO, the sound system for crossfire needs to be completely redone.  And until
how it is handled in the server is done, trying to figure out how we send it to
the client is premature IMO.

 There are several categories of sounds:

1) sounds that replay constantly if player is close enough to sound (ie, near
woods, water sound from fountain, water movement from river, etc.).  The source
of these sounds is static.

2) Sounds that replay pretty constantly, but their nature is more dynamic. 
Monster sounds will fall into this category - generally, most should make some
noise, but the source may move, or the source may even be eliminated.

3) Sounds that only need to get played once (spell sounds, door open sounds,
etc).  These are already handled, but their generation within the code is hard
coded - this should be derived from object attributes.

 Case #1 can be handled as you described.  However, sound source should really
be an offset from when the player enters the map - I think this will work better
with the tiled maps - as the player moves around, server can send ambiant sound
information for all sounds within some radius.

 My bigger question would be how do you handle the ambiant sounds?  are they
played with directional bias from relative to the source of the sound on the
speaker channels, or is distance only relevant for purposes of volume?  If the
former, it seems that you then need several ambiant sources - say you have a
road with woods along the entire length - having just one ambiant source in the
middle of the woods wouldn't work very well (actually, this wouldn't work very
well even for distance - so presumably that woods needs to get sprinkled pretty
liberally with ambiant sources for sounds to be played properly.