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.