[crossfire] server map code redo.
Mark Wedel
mwedel at sonic.net
Wed Aug 31 02:26:57 CDT 2005
tchize wrote:
>>
5) To convey some of these changes to the client, a new protocol command is
>>
needed. But no reason to write that until we have data to actually send to
>>
it.
>>
>
>
>
I'll opt for a complete rework of whole client/server protocol in a branch.
>
This way we can easily tweak new protocol for performance and not take
>
care of old protocol compatibility. Backward compatibility could come
>
afterwards when new protocol is mature enough.
The problem, as mentioned in layering thread, is that some of these changes
basically necessitate some mechanism for backward compatiblity.
Basically, right now, the server stores 3 layers of information in the
mapcells. I don't want to have to have those as well as all the new layers -
I'd want those old layers to go away - this means some mechanism to pull the
right data to display.
As far as new protocol, I'd actually argue that there is less reason to branch
that than making a change to an existing protocol. After all, we could pretty
easily put something in at the top of socket/request.c which will basically have
it refuse to serve the new protocol (by refusing setup command) unless
uncommented - if someone is savy enough to mess with that, they can live with
the consequences.
I do note that I wrote up a 'map2' protocol proposal a while back and it does
sit in the doc/Developer/protocol file as the proposal. I think tha should
cover everything, but in that one, I only did 8 image layers (including
smoothing), which wouldn't cover the proposal I just sent out.
More information about the crossfire
mailing list