Alex Schultz wrote: > Mark Wedel < mwedel at ... > writes: > >> The server is arguably behaving properly - as said, the design is that the >> server basically just sends what changes. The event that causes those changes >> isn't a concern to the server > > > If one calls properly, to the spec of the doc/Developers/protocol file, then it > would depend on your interperation of certain parts of that document (hence the > "arguably" part). Yes - the definition of what 'newmap' really should do isn't explained especially well. > > Yes, and on that topic, I think it would be best to use a newmap1 command or > something like that to include both the map name and starting coords for the > 'fog map caching', but also allow individual maps to disable 'fog map caching' > (if the coords would give away too much, or it there's some sort of storyline > reason), in which case the server wouldn't send the coords and the client gets a > special signal that tells it that it can't cache fog maps here. The easiest way to handle maps that we want to keep the coordinates secret is to send -1 -1 as the starting coordinates in the newmap1 command. The client can still go and cache the data for fog purposes - it will just have to invalidate it each time, but that is no worse than how it works right now. The trickier part is trying to come up with a standard of for what maps should be secretive and what shouldn't. Because from a player perspective, you'd always want all maps to be non secretive, and that could lead to a discussion of 'why is map xyz secretive? Map abc isn't, and the info is basically the same'