[crossfire] House sizes

[Mark Wedel]

Alex Schultz wrote:

>> I don't know if there's a limit on tile size, but there's a 10000-byte
>> limit on images sent to the server in MAX_IMAGE_SIZE.  If you raise
>> that, you soon run into MAXSOCKSENDBUF, which is currently 12239
>> bytes.  (I discovered those when I converted the Demon_Lord into a
>> single image and it was considerably larger than that before
>> compression.)  I was able to compress Demon_Lord, which is a 4x8
>> image, to 7841 bytes, but it only has two colors, so I'm guessing a
>> more colorful image would be larger.
>>   
> I'm thinking, that for 2.0 it may be desirable to use a separate port
> for media (images anyway) transfer, and perhaps we could even consider
> http for that part (though I'd say that if we wanted to use http, we'd
> want to optimize things by using cgi and GET parameters, or perhaps a
> micro-http-server specialized for serving cf images via http (after all,
> non-standard-complient http can be very simple ;P))

  This is getting a bit off topic, but if a separate media server is done, there 
isn't really any reason that multiple protocols couldn't be supported (eg, http, 
ftp, whatever).

  I'd personally think that we shouldn't rebuild the universe for that - 
instead, we should leverage existing technologies/programs (ftp & web servers, 
perhaps others if there are light weight servers).  I'm pretty sure there are 
some pretty light weight web servers out there if you don't want a big list of 
features.

  What I'd envision is something like this:

  Client connects to the server.  The server (upon request) provides a list of 
servers where the media content could be downloaded.

  There would be some extra logic - in a sense, common media servers which hold 
the standard distributions, and specialized/local media servers, which are 
guaranteed to have all the data the local server is using (eg, if I add a custom 
graphic to my server, the general media server probably won't have it, but need 
some way for the client to get it).  Most likely, the specialized one would be 
on the same system as the server itself.

  I'd need to think about this more, but I'd also like to have some way of 
versioning the data so that instead of the client having to query for all the 
media files the server is currently using, the client could do something like 'I 
have version 46 of the server media files.  The server is now up to revision 52, 
so I need to download mediapaks 47-52 and be updated'  And perhaps for 
efficiency reasons, the server makes jumbo packs every so often (so that if you 
don't play for 3 months and come back, it can upload jumbopak.60, jumbopak.70, 
and paks.71-73 type of thing).

  I think the way for this to work would be to change the collect logic - 
instead of the entire bmaps files getting rewritten each time, the file gets 
appended but isn't in order (it could be sorted internally by the server).  So 
in a simple case, you connect to the server - its highest image is 5146.  That 
matches what you have.  Next time you play, its highest image is 5180, so there 
is those 34 images to download.

  Another advantage of this is that if the clients stores the number->image 
mapping for the first 5146, in practice they should never change, so it saves 
some bandwidth.  If an image disappears, then there is just a whole in the bmaps 
file (or maybe some special tag is used, like none).

  Periodically, a completely rebuild would be needed, as I recall there are 
maximum image numbers, and if rebuilds didn't happen, we'd eventually overflow 
that (I think it is only 16 bits, so 65535 - that sounds like a lot, but if you 
only take into account that images get added, never removed, things would get 
out of date).


> I believe though, that for 2.0, we should consider depreciating, if not
> removing, gcfclient and the x11 client.

  Yes - it'd probably be nice to do that sooner, simply so as other changes 
happen, those don't have to get updated.


> Another thought is, do we want to toss the 'classic' tileset? On that
> same note, would it be worth just plain removing tileset support in
> order to simplify things?

  There probably isn't much reason to remove the classic tileset right now - it 
isn't harmful.

  And IMO, the tileset support is useful in other ways.  There have been 
discussions on IRC about a larger image tileset (64x64) - the multiple tileset 
that the server has makes it so this could be done right now without any server 
changes - you'd just need to create all those new images.  The client would need 
support to know about this larger tileset.

  Or likewise, if someone really wanted and isomorphic view, they could make 
such a tileset (or more likely, grab the one from daimonin)