Images, was Re: [CF-Devel] arch/object changes.

Thu Dec 13 02:12:10 CST 2001

David Hurst wrote:

>

      > 1) Image format for all images should be png.

     >

     >

      I believe this was agreed upon awhile ago, I defn don't think we should move from png yet ;).

 Note the idea here is to have a formal document, no matter how obvious it may
seem.  Otherwise, when someone checks in a set that uses gif and you say 'what
did you do that for' and the answer is 'nothing ever said what the format
was...'.  

>

     >

      > 2) There must be an active maintainer of each of the image sets.  If a set gets

     >

      > too out of date because of no maintainer, that particular set gets removed.

     >

     >

      What do you define as active out of interest? Commiting something new once a week, once a month, hanging around in #crossfire?. I guess this is fair ambiguous, I would prefer something alittle clearer, like..

     >

     >

      'we reserve the right to move unsupported sets off the main cvs tree if support discontinues or because it is supersceded"

 Of course, depending on the person, that could also be ambiguous (support
discontinues?  superceded?).  What it really comes down to is that if there is a
problem in the set, that problem is sent to the developers, and no one fixes it,
the set gets removed.  If there is an active maintainer, they would fix it - if
there is no active maintainer, it doesn't get fixed. 

>

      Would it then be possible to change sets while in the game? I certainly see that feature as being quite important.

 Changing sets in the game is really a client issue.  Whether the clients will
be designed to do so is up to it - it certainly means a lot of work.  Suppose
you are running flat and want to change to another set (maybe different tile
size or whatever).  For it to really work, the client would need to request a
new copy of all the images it currently has from the server in this new set.

 A client is free to say 'start using set 3' or 'start using set 6' at any
time.  What should probably really be done for the client is to force caching,
eg, the server will only send an image when the client requests it, otherwise
always send the first number->name mapping (like it does for caching).

 In terms of the client, it would be something like:

C->S: askface <setnum> <image_num1><image_num2....>
S->C: image <setnum><image_num><len><data>

 The server would include the set that the image is actually in, so that in
theory the client could cache each set differently.  This way the client would
also know what set the image really is from the fallback, eg, if the client is
playing set 6, but the image does not exist in set 6 but set 6 fallbacks to set
3, which does have the image, the client would know to put it in its set 3
cache.

 Fortunately, the server already includes the checksum in the face1 command.  So
in the case where the client does not have an image in its cache for that
particular set, it could look in the other sets for that samed name image, and
if the checksum is the same, use it.  In this way, the client wouldn't get a
bunch of images it already has copies of.

 The face command could also be extended to be:

S->C: face2 <image num><checksum><set num><name>

 where set_num is the set of the image the client would get sent if it asks for
a copy of this face.  In that way, the client would know where to look.

>

      > 5) There must be a somewhat legitimate reason for the set, eg, there must be

     >

      > enough in the set to warrant it being part of the game and not just 15 images

     >

      > you download off some site.  There should probably be at least 100 images before

     >

      > it should become a set.

     >

     >

      I suppose this again is rather ambiguous. What defines being legitimate, to someone who just wants to update the dragon and use another set for everything else, they may see this as legitimate?

 This comes to the maintainers.  Perhaps it should be reworded to be something
like:

5) Addition of any image sets to the arch directory requires approval of the
maintainer or consensus of the developers.  In general, a set should consist of
100 images before it will be considered for approval.

 Basically, I don't want 40 sets out there, each with just a few special
images.  I don't think that would happen in any case, but once again, its good
to document the procedure on this type of thing.

>

     >

      > 6) In terms of collection, the collect script will only collect the images for

     >

      > that specific set, resulting in a sparse image file.  The server will deal with

     >

      > fallback.  This results in smaller image files in lib, which means faster load

     >

      > time and less memory footprint for the server.

     >

     >

      Hmm also abit slower though? the way CF currently handles the alternate set is, it creates the image list, then runs through it and sees if it can find an image in the alternate set of the same name. If one is found it uses the image from that directory instead of the arch directory. This means anything which is either wrong, or not there is ignored at the old image used.

 The difference in speed at run time should be neglible.  Collection should in
fact be faster (fewer images to collect, thus less work).  Load time is also
faster for the same reason (less data to load).  In terms of server time, the
only extra work is if an iamge is absent to find the real one (eg, this image is
not in set 6, but fallback to 3.  Lets check set 3.  Not there, fallback to 1. 
Ok, its there, send that one).

 At load time, the image_set descriptive file would be loaded, and some sanity
checking done (to make sure that there are no image loops for example so that
set 6 doesn't fall back to 3, which fallbacks to 6), and that all sets
eventually fall back to set 0.

>

      Yeah I suppose this is contentious. If looked at from a list in alphabetical order you have the choice of:

     >

     >

      a) sorted by set, object, specific: set.image.111.png

 Which, if your going to do that, might as well just make 'images1' and
'images2' and the like directories within arch.

>

      b) sorted by object, set, specific: image.set.111.png

     >

      c) sorted by object, specific, set: image.111.set.png

     >

     >

      obviously there are 6 more choices ;), but I think these are the three most important. What do we consider the most important information, the name should be sorted from most important to least important. Originally I would have said a), but now my preference is for b). When editing and finding images, the preference would be for which monster, which set, which image in general. I must say (yes I know more python whinging) that uses an int to represent the set seems alittle counter intuitive. I would ave thought three letters would be far more useful, I would hate to have to find the list of which set is which number. But std, flt, iso, crt, stp, crp etc etc would be far more useful? I realise that c's string handling is alittle braindead... but this seems worth the extra work to me.. ;)

 Unless you allow arbitrary descriptions (which then may result in long file
names), those descriptions might get pretty useless.  Suppose you have an
alternate iso set - do you call that 'is2'?   OTOH, supporting this wouldn't be
a lot harder - I'm not sure if it might by more prone to mistakes or not
(someone calling it ftl instead of flt and wondering why the images are not
there).  Currently, the collect script does warning about files it seems
shouldn't be there - easier to do that with numbers than arbitrary strings of
letters.

 Generally speaking, c is the easiest to collect, as the image names themselves
(in the bmaps file) are in the form image.111, so putting the set name/type
after makes that processing a little easier.

 Note that split images at some point will go away - I'm pretty sure all the
code is there to make this happen, the client just needs a little more work I
think.  So that should reduce the images for each large object by a bit.

>

      I like your idea of storing set information, particular image size and a short description of its purpose. That information could then be sent to the client so users will have less trouble selecting their prefered sets. thoughts?

 Yes, the client would basically get a copy of the image_sets file to know what
it could request.  What the client does to it is up to it.