[crossfire] Re: Map Protocol Question
Mark Wedel
mwedel at sonic.net
Fri Jul 8 02:18:32 CDT 2005
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'
More information about the crossfire
mailing list