Alex Schultz wrote:
Mark Wedel <[EMAIL PROTECTED]> 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'
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
